Dear Greg, Since there had been no responses to the few emails you had sent to the three lists (MPLS, SPRING, RTG-BFD) about various versions of this draft, here’s some high-level thoughts. I hope these are clear and useful.
In this email you mention BFD as the Target WG, the document file name implies Spring, and before I understood you said MPLS. First, running BFD and S-BFD on Spring Tunnels is an important operational feature, where different implementations ought to inter-operate. It is not clear to me, however, which areas need further specification for this to work. From the document: Section 2 should basically be “use RFC 5884 for BFD on MPLS tunnels”. I do not believe there’s confusion about the tail end using the FEC it itself advertised and not a previous one in the stack. Section 3+4 (previous Section 3 only) -> for SDN-provisioned tunnels, why would the headend signal something in band when the controller is already talking to both ends? I do not believe this is needed. Section 4 -> A. It is not clear what a non-FEC TLV is, or how it would be used in LSP ping. The document says it is used to specify the reverse path of a BFD session. But there are already reverse path TLVs. If someone is interested in the BFD reverse path specified, should that be defined in the other document bfd-directed? B. I believe including Label values in this signaling element without context is dangerous (as the mapping to FECs can change and you end up leaking packets to the wrong place). Instead, Section 5 explains how to do this. It seems that this non FEC creation is to work around using this sub TLV in the Reply Path TLV from RFC 7110 C. Also, the paragraph just prior to Figure 2 says that the document specified “Static Routing MPLS Tunnel sub-TLV” but before it said “Segment Routing Static MPLS Tunnel TLV”. D. Finally, is this TLV defined to nest just one type of sub-TLV. Seems over engineered. Section 5 -> this says what bfd-directed already says (or should say) Net net, I do not see this as useful. Thanks! Sent from my iPad On Dec 4, 2017, at 3:09 PM, Greg Mirsky <[email protected]<mailto:[email protected]>> wrote: Dear All, the major part of the update is around new Non-FEC Path TLV registry to host Segment Routing MPLS Tunnel sub-TLV proposed in this document. We appreciate your questions, comments and consideration by BFD WG to adopt the draft. Regards, Greg ---------- Forwarded message ---------- From: <[email protected]<mailto:[email protected]>> Date: Mon, Dec 4, 2017 at 2:02 PM Subject: New Version Notification for draft-mirsky-spring-bfd-03.txt To: Ilya Varlashkin <[email protected]<mailto:[email protected]>>, Gregory Mirsky <[email protected]<mailto:[email protected]>>, Ilya Varlashkin <[email protected]<mailto:[email protected]>>, Jeff Tantsura <[email protected]<mailto:[email protected]>>, "Mach Chen (Guoyi)" <[email protected]<mailto:[email protected]>> A new version of I-D, draft-mirsky-spring-bfd-03.txt has been successfully submitted by Greg Mirsky and posted to the IETF repository. Name: draft-mirsky-spring-bfd Revision: 03 Title: Bidirectional Forwarding Detection (BFD) in Segment Routing Networks Using MPLS Dataplane Document date: 2017-12-04 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/internet-drafts/draft-mirsky-spring-bfd-03.txt Status: https://datatracker.ietf.org/doc/draft-mirsky-spring-bfd/ Htmlized: https://tools.ietf.org/html/draft-mirsky-spring-bfd-03 Htmlized: https://datatracker.ietf.org/doc/html/draft-mirsky-spring-bfd-03 Diff: https://www.ietf.org/rfcdiff?url2=draft-mirsky-spring-bfd-03 Abstract: Segment Routing architecture leverages the paradigm of source routing. It can be realized in the Multiprotocol Label Switching (MPLS) network without any change to the data plane. A segment is encoded as an MPLS label and an ordered list of segments is encoded as a stack of labels. Bidirectional Forwarding Detection (BFD) is expected to monitor any kind of paths between systems. This document defines how to use Label Switched Path Ping to bootstrap and control path in reverse direction of a BFD session on the Segment Routing static MPLS tunnel. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>. The IETF Secretariat _______________________________________________ mpls mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/mpls
