Subject: RE: Possible addition to S-BFD use-case draft?

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Fri, 14 Mar 2014 01:30:27 +0000

Hi Sam,

> >>> While path trace is still required, S-BFD eliminates the need for
> >>> bootstrapping Discrim negotiation.
> >> I understand the elimination of discrimination negotiation with
> >> S-BFD, I personally still need to understand the value of running per
> ECMP path.
> >
> > Right, it's a use-case draft, so that aspect is critical. Sorry for not bringing
> that up earlier.
> > Detection of traffic black hole on MPLS network is what I had in mind, with
> LDP being the primary motivation for now.
> Makes sense. I think it is important for non LDP cases as well, like FAT PW.

True it could apply there as well ... although I have my opinion on which *layer* to do ECMP in-band monitor :)

> With type-9 multi path type of LSP ping, one could determine the label stack
> of Packet for each of the ECMP paths.
> Which makes a case for http://datatracker.ietf.org/doc/draft-akiya-mpls-
> entropy-lsp-ping/?include_text=1 :D

:)

> One solution question (not applicable for use case draft) I have is, with the
> presence of EL, will intermediate nodes still use fields beyond label stack
> for load balance? Like IP/UDP header?
> As that varies between MPLS and BFD, mapping of 1:1 may not yield right
> results, right?

MPLS trace and S-BFD can use same IP src/dst, but UDP ports will vary. Thus in a non-EL environment, all LSRs will need to use 3-tuple hashing that excludes UDP ports. This is not limitation with just MPLS trace and S-BFD (or BFD). This is applicable to all other OAM techniques which employ MPLS traceroute to discover hash keys and use *something else* to traverse specific ECMP path using the hash keys. For example: http://datatracker.ietf.org/doc/draft-geib-spring-oam-usecase/

With EL though, RFC6790 defines transit LSR behavior this way.

[snip]
   Some transit LSRs look beyond the label stack for better load-
   balancing information.  This is a simple, backward-compatible
   approach in networks where some ingress LSRs impose ELs and others
   don't.  However, this is of limited incremental value if an EL is
   indeed present and requires more packet processing from the LSR.  A
   transit LSR MAY choose to parse the label stack for the presence of
   the ELI and look beyond the label stack only if it does not find it,
   thus retaining the old behavior when needed, yet avoiding unnecessary
   work if not needed.
[snip]

Which means, if ELI/EL is present, then stuff beyond label stack will not be used for load balance purpose. This is one of the major strength of EL from OAM perspective.

So can we get that one added into S-BFD use-case draft? :)

-Nobo

> 
> -sam
> >
> > -Nobo
> >
> >> -----Original Message-----
> >> From: Sam Aldrin [mailto:[email-masked]]
> >> Sent: Thursday, March 13, 2014 5:21 PM
> >> To: Nagendra Kumar Nainar (naikumar)
> >> Cc: Nobo Akiya (nobo); Jeffrey Haas; Bhatia, Manav (Manav)
> >> ([email-masked]); Gregory Mirsky
> >> ([email-masked]); [email-masked];
> >> rtg- [email-masked]
> >> Subject: Re: Possible addition to S-BFD use-case draft?
> >>
> >>
> >>
> >> Sent from my iPad
> >>
> >>> On Mar 13, 2014, at 1:58 PM, "Nagendra Kumar Nainar (naikumar)"
> >> <[email-masked]> wrote:
> >>>
> >>> Hi
> >>>
> >>> Agree. I think Jeff meant (label stack with unique EL).
> >>>
> >>> Yes BFD over MPLS mandates usage of locahost (or v4 localhost mapped
> >>> v6), see RFC5884.
> >> Ah! Forgot about that.
> >>>
> >>> Whether MPLS traceroute discovered entropy can be used by BFD to
> >>> traverse expected path is a separate question. But assuming that it
> >>> _is_ possible (whether EL or non-EL w/ 3-tuple hashing), then how do
> >>> we do BFD over MPLS per ECMP paths of LSP was my question, and
> >>> implying that S-BFD is much better fit for this job :)
> >>>
> >>>
> >>>
> >>> <Nagendra> I think yes. While trace route will help with identifying
> >>> the ECMP paths and the possible entropy (EL, address range or both),
> >>> traditional BFD still need additional step to bootstrap the Discrim
> >>> for each session (over each path).
> >> Sorry for diverging here, are you saying EL is used for path tracing?
> >> Has anyone implemented that? Would definitely love to talk to them
> offline.
> >>>
> >>> While path trace is still required, S-BFD eliminates the need for
> >>> bootstrapping Discrim negotiation.
> >> I understand the elimination of discrimination negotiation with
> >> S-BFD, I personally still need to understand the value of running per
> ECMP path.
> >>
> >> Sam
> >>>
> >>> Thanks,
> >>> Nagendra
> >>>
> >>>> On 3/13/14 4:53 PM, "Nobo Akiya (nobo)" <[email-masked]> wrote:
> >>>>
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Sam Aldrin [mailto:[email-masked]]
> >>>>> Sent: Thursday, March 13, 2014 4:47 PM
> >>>>> To: Nobo Akiya (nobo)
> >>>>> Cc: Jeffrey Haas; Bhatia, Manav (Manav) (manav.bhatia@alcatel-
> >>>>> lucent.com); Gregory Mirsky ([email-masked]);
> >>>>> Nagendra Kumar Nainar (naikumar);
> >>>>> [email-masked]; rtg- [email-masked]
> >>>>> Subject: Re: Possible addition to S-BFD use-case draft?
> >>>>>
> >>>>>
> >>>>>
> >>>>> Sent from my iPad
> >>>>>
> >>>>>>> On Mar 13, 2014, at 1:12 PM, "Nobo Akiya (nobo)"
> >>>>>>> <[email-masked]>
> >>>>>> wrote:
> >>>>>>
> >>>>>> Hi Jeff,
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: Jeffrey Haas [mailto:[email-masked]]
> >>>>>>> Sent: Thursday, March 13, 2014 2:27 PM
> >>>>>>> To: Nobo Akiya (nobo)
> >>>>>>> Cc: Sam Aldrin ([email-masked]); Bhatia, Manav (Manav)
> >>>>>>> ([email-masked]); Gregory Mirsky
> >>>>>>> ([email-masked]); Nagendra Kumar Nainar
> (naikumar);
> >>>>>>> [email-masked]; [email-masked]
> >>>>>>> Subject: Re: Possible addition to S-BFD use-case draft?
> >>>>>>>
> >>>>>>> Nobo,
> >>>>>>>
> >>>>>>>> On Wed, Mar 05, 2014 at 04:06:07PM +0000, Nobo Akiya (nobo)
> wrote:
> >>>>>>>> I'd like to propose a possible addition to the S-BFD use-case draft.
> >>>>>>>>
> >>>>>>>> BFD MPLS (RFC5884) states:
> >>>>>>>>
> >>>>>>>> [snip]
> >>>>>>>> If there are multiple alternate paths from an ingress LSR to an
> >>>>>>>> egress LSR for an LDP IP FEC, LSP Ping traceroute MAY be used
> >>>>>>>> to determine each of these alternate paths.  A BFD session
> >>>>>>>> SHOULD be established for each alternate path that is discovered.
> >>>>>>>> [snip]
> >>>>>>>>
> >>>>>>>> Above implies that a BFD session should be bootstrapped per
> >>>>>>>> alternate
> >>>>>>> (i.e. ECMP) path, but RFC does not have further details no how
> >>>>>>> to create/maintain multiple BFD MPLS sessions per FEC. Questions
> >>>>>>> I have
> >>>>> are:
> >>>>>>>> * How should egress de-multiplex the bootstrap request per
> >>>>>>>> alternate
> >>>>>>> path?
> >>>>>>>> * If/when number of alternate paths changes or hash key changes:
> >>>>>>>>  - how should ingress delete BFD sessions on egress?
> >>>>>>>>  - re-bootstrapping set of sessions can be [relatively]
> >>>>>>>> inefficient as that
> >>>>>>> can consume time/resources.
> >>>>>>>>
> >>>>>>>> Alternative is to use S-BFD for multiple alternate paths for a
> >>>>>>>> FEC, which
> >>>>>>> eliminates the concerns raised from above questions ... and much
> >>>>>>> simpler to implement and operate.
> >>>>>>>
> >>>>>>> My impression is that the alternate paths are known via MPLS
> >>>>>>> traceroute and thus the BFD packet can have the appropriate
> >>>>>>> label
> >>>>> stack
> >>>>> added.
> >>>>>>
> >>>>>> Yes, known via MPLS traceroute. Say this produces 8 ECMP paths.
> >>>>>> How do
> >>>>> you bootstrap (and maintain) 8 BFD over MPLS sessions on this LSP?
> >>>>> Paths identified by MPLS trace route are not unique with label
> >>>>> stack because Dst local host address also uniquely identifies the
> >>>>> path. If the same is used for BFD, do you plan to use local host
> >>>>> as Dst address as well?
> >>>>
> >>>> Agree. I think Jeff meant (label stack with unique EL).
> >>>>
> >>>> Yes BFD over MPLS mandates usage of locahost (or v4 localhost
> >>>> mapped v6), see RFC5884.
> >>>>
> >>>> Whether MPLS traceroute discovered entropy can be used by BFD to
> >>>> traverse expected path is a separate question. But assuming that it
> >>>> _is_ possible (whether EL or non-EL w/ 3-tuple hashing), then how
> >>>> do we do BFD over MPLS per ECMP paths of LSP was my question, and
> >>>> implying that S-BFD is much better fit for this job :)
> >>>>
> >>>> -Nobo
> >>>>
> >>>>>
> >>>>> Sam
> >>>>>>
> >>>>>> -Nobo
> >>>>>>
> >>>>>>>
> >>>>>>> -- Jeff (not terribly clueful here)
> >>>

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Sat, 15 Mar 2014 01:51:14 +0000

Hi Sam,

> Which means, if ELI/EL is present, then stuff beyond label stack will not be
> used for load balance purpose. This is one of the major strength of EL from
> OAM perspective.
> Do you think this will be true for legacy hardware as well? How will they
> know they need to special process EL and not to look at IP header for hash
> computation?
> 
> I believe the assumption by RFC6790 is, if a product has implemented
> support for ELI/EL, it has been updated to not look at stuff beyond label
> stack when ELI/EL is present. And that should be possible because ELI is a
> special label.
> Sure. But that is for implementations which understand RFC6790. What
> about the existing h/w which are already deployed?

I just went to back emails threads with Curtis Villamizar in MPLS list. RFC6790 describes that there's no point in looking for other entropies beyond first EL found, but there is nothing in RFC6790 that prevents implementations from looking further beyond EL. RFC4389 on the other hand was originally designed to handle implementations that load balances on label OR IP. With so many flavors of load balancing implementations, it's very difficult for any OAM to cover all. A reasonable approach may be to go with coverage over common implementations, like approach taken by RFC4379.

> Please get me the text and will add, not a problem :D
> 
> Excellent!
> 
> How about something like this:
> 
> 3.9.  MPLS BFD Session Per ECMP Path
> 
>   BFD for MPLS, defined in [RFC5884], describes procedures to run BFD
>   as LSP in-band continuity check mechanism, through usage of MPLS echo
>   request [RFC4379] to bootstrap the BFD session on the egress node.
>   Section 4 of [RFC5884] also describes a possibility of running
>   multiple BFD sessions per alternative paths of LSP.  However, details
>   on how to bootstrap and maintain correct set of BFD sessions on the
>   egress node is absent.
> 
>   When a LSP has ECMP, it is desirable to run in-band monitoring that
>   exercises every path of ECMP.  Otherwise there will be scenarios
>   where in-band BFD session remains up through one path but traffic is
>   black-holing over another path.  One way to achieve BFD session per
>   ECMP path of LSP is to define procedures that updates [RFC5884] in
>   terms of how to bootstrap and maintain correct set of BFD sessions on
>   the egress node.  However, that may require constant use of MPLS echo
>   request messages to create and delete BFD sessions on the egress
>   node, when ECMP paths and/or corresponding load balance hash keys
>   change.  If a BFD session over any paths of LSP can be instantiated,
>   stopped and resumed without requiring additional procedures of
>   bootstrapping via MPLS echo request, it would simplify
>   implementations and operations, and benefits network devices as less
>   processing are required by them.
> 
> Sure will add.

Thanks!

> Did I miss any other additions apart from this? Will spin a new version in 10
> days.
> Will add any, if sent to me by then.

This is the only one that was brought up to the list so far. If others have anything, now would be a good time to chime in.

-Nobo