Re: LSP ping as bootstrap for G-ACh encapsulated BFD
Carlos Pignataro (cpignata <cpignata <at> cisco.com>
2012-09-04 04:08:06 GMT
What you describe seems to be the single-hop BFD initialization procedures, which are also used in RFC 5885 
It is not totally clear to me how tightly tied the procedures from RFC 6428 are to the bootstrapping from RFC 5884 using LSP Ping, versus a single-hop initialization without discriminators exchanged. The document seems to be slightly vague there, though I do not know how it would affect.
o The BFD Control packets are sent on the VCCV control channel. The
use of the VCCV control channel provides the context required to
bind and bootstrap the BFD session, since discriminator values are
not exchanged; the pseudowire demultiplexer field (e.g., MPLS PW
Label or L2TPv3 Session ID) provides the context to demultiplex
the first BFD Control packet, and thus single-hop BFD
initialization procedures are followed (see Section 3 of [RFC5881]
and Section 6 of [RFC5882]
o A single BFD session exists per pseudowire. Both PW endpoints take the Active role sending initial BFD Control packets with a
Your Discriminator field of zero, and BFD Control packets received
with a Your Discriminator field of zero are associated to the BFD
session bound to the PW.
On Jun 17, 2012, at 12:14 PM, Muly Ilan wrote:
We plan to implement the CC-CV-RDI functionality per RFC6428.
Is it mandatory to support LSP ping as a bootstrap for the BFD i.e. using LSP ping with TLV type 15 in the echo request/reply to exchange discriminator values?
RFC6428 is quite vague on this issue. It only states “Overall operation is as specified in RFC 5880  and augmented for MPLS in RFC 5884 .
IMHO, the initial value of the remote discriminator can be zero and replaced with the correct value when the 1stcontrol packet is received from the peer.
This behavior complies with another statement of the RFC “The transmitted Your Discriminator value MUST reflect back the received value of the My Discriminator field or be set to zero if that value is not known”
mpls mailing listmpls <at> ietf.orghttps://www.ietf.org/mailman/listinfo/mpls
mpls mailing list
mpls <at> ietf.org