Re: IP Address Schemes for BFD on LAG interfaces
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IP Address Schemes for BFD on LAG interfaces



Hello Alexander and Greg,

The highlighted text suggests to me that RFC 5884 mandates usage of LSP Ping for bootstrapping of BFD sessions. Taking into account that it supports BFD session per FEC for a given LSP, I do not see any alternative to this method.

I agree. The first sentence in section 6 was already enough for me. It seems obvious to me that RFC5884 is tightly coupling BFD and LSP ping, nothing optional.

Now Greg's email had 2 statements:

"AFAIK, use of LSP Ping to bootstrap a BFD session over MPLS LSP is optional. Thus use of Router Alert is not mandated by RFC 5884."


The first sentence you have answered. For the second sentence I assume this is related to BFD packets (?). And indeed RFC5884 is not mentioning router alert a single time, neither as option nor as label. My understanding is the BFD packet has no router alert option in it's IP header.

I have sent an email to George, one of the authors of RFC5884 and RFC4379, why LSP ping echo requests - with an IP header very similar to BFD in RFC5884 - need to carry RA option but BFD does not.


Did I miss something substantial?

If so then you are not alone ;-)


Regards, Marc



On 2012-02-11, at 11:24 , Alexander Vainshtein wrote:

Dear Greg,
Regarding your claim that ""use of LSP Ping to bootstrap a BFD session over MPLS LSP is optional" - quoting from RFC 5884:
In Section 4 "Theory of operation"

 

   To enable fault detection procedures specified in this document, for
   a particular MPLS LSP, this document requires the ingress and egress
   LSRs to be configured.  This includes configuration for supporting
   BFD and LSP Ping as specified in this document.  It also includes
   configuration that enables the ingress LSR to determine the method
   used by the egress LSR to identify Operations, Administration, and
   Maintenance (OAM) packets, e.g., whether the Time to Live (TTL) of
   the innermost MPLS label needs to be set to 1 to enable the egress
   LSR to identify the OAM packet.  For fault detection for MPLS PWs,
   this document assumes that the PW control channel type [RFC5085] is
   configured and the support of LSP Ping is also configured.
 
In Section 6 "Session Establishment":
 
A BFD session is bootstrapped using LSP Ping. 
...
   To establish a BFD session, an LSP Ping
   Echo request message MUST carry the local discriminator assigned by
   the ingress LSR for the BFD session.  This MUST subsequently be used
   as the My Discriminator field in the BFD session packets sent by the
   ingress LSR.

And from Section 6.1. "BFD Discriminator TLV in LSP Ping":

 

   LSP Ping Echo request and Echo reply messages carry a BFD
   discriminator TLV for the purpose of session establishment as
   described above.  IANA has assigned a type value of 15 to this TLV.
   This TLV has a length of 4.  The value contains the 4-byte local
   discriminator that the LSR, sending the LSP Ping message, associates
   with the BFD session.

   If the BFD session is not in UP state, the periodic LSP Ping Echo
   request messages MUST include the BFD Discriminator TLV.

 


The highlighted text suggests to me that RFC 5884 mandates usage of LSP Ping for bootstrapping of BFD sessions. Taking into account that it supports BFD session per FEC for a given LSP, I do not see any alternative to this method.

 

 

Did I miss something substantial?

 

Regards,
     Sasha

 

 



________________________________________
From: Gregory Mirsky [gregory.mirsky at ericsson.com]
Sent: Friday, February 10, 2012 10:18 PM
To: Alexander Vainshtein; Bhatia, Manav (Manav); Mach Chen; Tom Sanders; Nitin Bahadur
Cc: rtg-bfd at ietf.org
Subject: RE: IP Address Schemes for BFD on LAG interfaces

Dear Sasha,
AFAIK, use of LSP Ping to bootstrap a BFD session over MPLS LSP is optional. Thus use of Router Alert is not mandated by RFC 5884.

What do you think?

        Regards,
                Greg


--
Marc Binderberger           <marc at sniff.de>


Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.