Subject: BFD Directed Path discussion

From: Gregory Mirsky <[email-masked]>
Date: Tue, 22 Jul 2014 18:57:06 +0000

Dear All,
on behalf of the authors of this work I thank you all who participated in the discussions Monday (BFD WG) and today (MPLS WG). Great comments and suggestions - very excited by your interest in this work.
I've tried to capture summary of the comments and sketch possible ways to address these:

*         BFD Return Path TLV suitable for RFC 5880, what about S-BFD?
In order to maintain stateless character of S-BFDReflector, S-BFD control packet may need to carry return path information. Need to discuss with authors of S-BFD Base and start work on S-BFD over MPLS LSP with IP and ACH encapsulations;

*         What would happen if Return Path conveyed to the far-end BFD peer is not available? Ingress may send another BFD Return Path in its TLV along with the same BFD Discriminator;

*         Can BFD Echo of RFC 5880 be used in conjunction with the BFD Return Path TLV over MPLS LSP? It may be interesting as BFD Echo already allows for a payload but work on proper handling and encapsulations of BFD Echo is needed. Besides, use of BFD Echo over MPLS LSP may be limited to single segment LSPs thus S-BFD may be more generic mechanism to have stateless far-end BFD peer;

*         how this work is related to Extended BFD Discriminator TLV work? Both may be complementary, especially as parts of controlling BFD session. Would welcome authors of Extended BFD Discriminator TLV to discussion and review draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext and draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf drafts (authors are planning to bring them over the finish line)

Please excuse me if I've missed your question and please add it to this discussion.

                Regards,
                                Greg

---

From: "Vengada Prasad Govindan (venggovi)" <[email-masked]>
Date: Thu, 24 Jul 2014 10:35:05 +0000

Hello Greg,

Thanks for your note, a couple of clarifications here:
>how this work is related to Extended BFD Discriminator TLV work? Both may be complementary, especially as parts of controlling BFD >session. Would welcome authors of Extended BFD Discriminator TLV to discussion and review draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext >and draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf drafts (authors are planning to bring them over the finish line)
a. Are you suggesting that we add sub-TLVs to convey the instance identifier [1] inside the BFD configuration sub-TLV of both MPLS LSP ping [2] and the RSVP TE OAM [3] messages?
b. Are you considering the addition of BFD reverse-path TLV [4] as well to the LSP ping and RSVP-TE OAM messages? 

Thanks
Prasad
[1] draft-vgovindan-mpls-extended-bfd-disc-tlv
[2] draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-06
[3] draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-12
[4] draft-mirsky-mpls-bfd-directed-00

From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Gregory Mirsky
Sent: Wednesday, July 23, 2014 12:27 AM
To: [email-masked]
Cc: [email-masked]
Subject: BFD Directed Path discussion

Dear All,
on behalf of the authors of this work I thank you all who participated in the discussions Monday (BFD WG) and today (MPLS WG). Great comments and suggestions - very excited by your interest in this work.
I've tried to capture summary of the comments and sketch possible ways to address these:
. BFD Return Path TLV suitable for RFC 5880, what about S-BFD?
In order to maintain stateless character of S-BFDReflector, S-BFD control packet may need to carry return path information. Need to discuss with authors of S-BFD Base and start work on S-BFD over MPLS LSP with IP and ACH encapsulations;
. What would happen if Return Path conveyed to the far-end BFD peer is not available? Ingress may send another BFD Return Path in its TLV along with the same BFD Discriminator;
. Can BFD Echo of RFC 5880 be used in conjunction with the BFD Return Path TLV over MPLS LSP? It may be interesting as BFD Echo already allows for a payload but work on proper handling and encapsulations of BFD Echo is needed. Besides, use of BFD Echo over MPLS LSP may be limited to single segment LSPs thus S-BFD may be more generic mechanism to have stateless far-end BFD peer;
. how this work is related to Extended BFD Discriminator TLV work? Both may be complementary, especially as parts of controlling BFD session. Would welcome authors of Extended BFD Discriminator TLV to discussion and review draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext and draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf drafts (authors are planning to bring them over the finish line)

                Regards,
                                Greg

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Thu, 24 Jul 2014 14:26:55 +0000

Hi Greg, Prasad, et al,

Great to see this being discussed. Adding CCAMP and authors of both documents.

Speaking as a BFD WG co-chair ...

> [4] draft-mirsky-mpls-bfd-directed-00

Regarding above 2 documents, details should be discussed further but the needs of both look valid. However, we should not lead down the path of having more and more BFD bootstrapping TLVs, but have/aim-for one TLV that allows Sub-TLVs for extensions.

> [2] draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-06

Above document is dead.
IETF State: Dead WG Document

> [3] draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-12

Above document is already LC'ed (long ago).
IETF State:  Submitted to IESG for Publication 

My best guess is that we do not want to disrupt/block [3] at this point.

Question to authors of [1] and [4].

Are you interested to change LSP Ping bootstrapping only? If so, then it seems the authors of [1] and [4] need to get together and come up with a single BFD bootstrapping TLV (given that [2] is dead).

Thanks!

-Nobo

> -----Original Message-----
> From: Vengada Prasad Govindan (venggovi)
> Sent: Thursday, July 24, 2014 6:35 AM
> To: Gregory Mirsky; [email-masked]
> Cc: [email-masked]; Nobo Akiya (nobo)
> Subject: RE: BFD Directed Path discussion
> 
> Hello Greg,
> 
> >how this work is related to Extended BFD Discriminator TLV work? Both
> >may be complementary, especially as parts of controlling BFD >session.
> >Would welcome authors of Extended BFD Discriminator TLV to discussion
> >and review draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext >and
> >draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf drafts (authors are planning
> >to bring them over the finish line)
> a. Are you suggesting that we add sub-TLVs to convey the instance identifier
> [1] inside the BFD configuration sub-TLV of both MPLS LSP ping [2] and the
> RSVP TE OAM [3] messages?
> on behalf of the authors of this work I thank you all who participated in the
> discussions Monday (BFD WG) and today (MPLS WG). Great comments and
> suggestions - very excited by your interest in this work.
> In order to maintain stateless character of S-BFDReflector, S-BFD control
> packet may need to carry return path information. Need to discuss with
> authors of S-BFD Base and start work on S-BFD over MPLS LSP with IP and
> ACH encapsulations; . What would happen if Return Path conveyed to the
> far-end BFD peer is not available? Ingress may send another BFD Return
> Path in its TLV along with the same BFD Discriminator; . Can BFD Echo of RFC
> 5880 be used in conjunction with the BFD Return Path TLV over MPLS LSP? It
> may be interesting as BFD Echo already allows for a payload but work on
> proper handling and encapsulations of BFD Echo is needed. Besides, use of
> BFD Echo over MPLS LSP may be limited to single segment LSPs thus S-BFD
> may be more generic mechanism to have stateless far-end BFD peer; . how
> this work is related to Extended BFD Discriminator TLV work? Both may be
> complementary, especially as parts of controlling BFD session. Would
> welcome authors of Extended BFD Discriminator TLV to discussion and
> review draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext and draft-ietf-mpls-lsp-
> ping-mpls-tp-oam-conf drafts (authors are planning to bring them over the
> finish line)
>