Subject: [spring] Fwd: New Version Notification for draft-mirsky-spring-bfd-03.txt

From: Greg Mirsky <[email-masked]>
Date: Mon, 4 Dec 2017 14:09:34 -0600

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-masked]>
Date: Mon, Dec 4, 2017 at 2:02 PM
Subject: New Version Notification for draft-mirsky-spring-bfd-03.txt
To: Ilya Varlashkin <[email-masked]>, Gregory Mirsky <
[email-masked]>, Ilya Varlashkin <[email-masked]>, Jeff Tantsura <
[email-masked]>, "Mach Chen (Guoyi)" <[email-masked]>

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.

The IETF Secretariat

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 5 Dec 2017 11:53:26 +0000

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-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]>>
Date: Mon, Dec 4, 2017 at 2:02 PM
Subject: New Version Notification for draft-mirsky-spring-bfd-03.txt
To: Ilya Varlashkin <[email-masked]<mailto:[email-masked]>>, Gregory Mirsky <[email-masked]<mailto:[email-masked]>>, Ilya Varlashkin <[email-masked]<mailto:[email-masked]>>, Jeff Tantsura <[email-masked]<mailto:[email-masked]>>, "Mach Chen (Guoyi)" <[email-masked]<mailto:[email-masked]>>

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:

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-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls