RE: BFD Echo format

["Nobo Akiya" <[e-mail]>]

Hi Greg,

 

I absolutely agree on the S-BFD reverse path needing to take the
corresponding PW. I peeked into draft-gp-pals-seamless-vccv, and I did find
a text for this.

 

2.2.2.  S-BFD Reflector Operation

 

      All point to point pseudowires are bidirectional, the S-BFD

      Reflector therefore reflects the S-BFD packet back to the

      Initiator using the VCCV channel of the reverse direction of the

      PW on which it was received.

 

So, even though this key aspect was not described in the presentation, it
looks like the authors did consider this.

 

Thanks!

 

-Nobo

 

From: Gregory Mirsky [mailto:[e-mail]] 
Sent: March-23-15 8:21 PM
To: Nobo Akiya; [e-mail]
Subject: RE: BFD Echo format

 

Hi Nobo,

thank you for your thoughtful and interesting, as always, comments.

 

I've realized, after the session, that encapsulation of BFD Echo over LSP or
PW MUST be different from what defined in RFC 5880. I think it must follow
the same principle as set in RFC 5884 for Async BFD mode.

 

And I agree that PW, unlike LSP (at least most LSP constructs), is a
bi-directional construct. Thus, as I think of it, operators more interested
in verifying data plane availability in both directions. If we propose
two-way single-ended mechanism to check data path of the particular PW,
then, I imagine, the return path MUST be in-band, not over IP path. I think
that we need to note that in our discussion of S-BFD or BFD Echo over VCCV
as a requirement. Then we can see whether extending BFD Echo to MPLS LSP and
PW or using S-BFD bring better solution, particularly since we already have
ICMP and LSP Ping over VCCV defined.

 

                Regards,

                                Greg

 

From: Nobo Akiya [mailto:[e-mail]] 
Sent: Monday, March 23, 2015 6:19 PM
To: Gregory Mirsky; [e-mail] <mailto:[e-mail]> 
Subject: RE: BFD Echo format

 

Hi Greg,

 

I believe this comment was in context of S-BFD for VCCV.

 

>From what I understand, the scenario which S-BFD for VCCV is looked into is
the case where one end of the PW has very constrained resources. Using the
classical BFD will require such devices to maintain a session object per PW,
as opposed to S-BFD which only requires one reflector session.

 

Your comment about why not send BFD echo packets over the PW? Sending a
probe (BFD echo) with IP destination having the sender address, across
multiple physical hops, always has the danger of the probe packet still
coming back to the sender despite issues. Yes this is more likely on LSPs
like LDP, RSVP (and less likely on PW) but it is possible that PW label gets
exposed "somewhere" and that label value happens to match a different LSP,
picking up traversal to a different node.

 

Then there's the desire for return packets to come back on the reverse
direction of the forward PW. Whether we go with S-BFD for VCCV or BFD echo,
this (i.e., reflector bouncing back packets on the reverse PW) is a change
that needs to be made/standardized.

 

So to me, S-BFD for VCCV makes sense.

                                                                 

Thanks!

 

-Nobo

 

From: Rtg-bfd [mailto:[e-mail]]
<mailto:[mailto:[e-mail]]>  On Behalf Of Gregory Mirsky
Sent: March-23-15 1:54 PM
To: [e-mail] <mailto:[e-mail]> 
Subject: BFD Echo format

 

Dear All,

I stand corrected, BFD Echo format is not defined in the RFC 5880 but there
requirement suggesting that BFD Discriminator MAY be used to demux Echo
replies:

   The payload of a BFD Echo packet is a local matter, since only the

   sending system ever processes the content.  The only requirement is

   that sufficient information is included to demultiplex the received

   packet to the correct BFD session after it is looped back to the

   sender.  The contents are otherwise outside the scope of this

   specification.

 

                Regards,

                                Greg