Subject: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-directed

From: Martin Vigoureux <[email-masked]>
Date: Sun, 10 Jul 2016 19:59:40 +0200

WG,

as said by Ross [1], I have been appointed Document Shepherd for 
draft-ietf-mpls-bfd-directed [2]. As such I am also running the second 
WG LC.

So, this e-mail starts a WG LC which will end on the 31st of July.

I'd like to remind that an IPR disclosure [3] exists against this document.

So it is time to state whether or not you are in favour of progressing 
the document. Please also take the time to review the document and post 
comments on its content.

Please respond to this call.

Thank you

Martin

[1]: https://mailarchive.ietf.org/arch/msg/mpls/rxnEv4LnUiwhTiZOhowOC6AcHYU
[2]: https://datatracker.ietf.org/doc/draft-ietf-mpls-bfd-directed/
[2]: https://datatracker.ietf.org/ipr/2769/

---

From: Gregory Mirsky <[email-masked]>
Date: Sun, 10 Jul 2016 18:06:12 +0000

yes/support progressing this work as co-author.

	Regards,
		Greg

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Martin Vigoureux
Sent: Sunday, July 10, 2016 11:00 AM
To: [email-masked]
Subject: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-directed

WG,

as said by Ross [1], I have been appointed Document Shepherd for draft-ietf-mpls-bfd-directed [2]. As such I am also running the second WG LC.

So it is time to state whether or not you are in favour of progressing the document. Please also take the time to review the document and post comments on its content.

Thank you

Martin

_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: "Andrew G. Malis" <[email-masked]>
Date: Sun, 10 Jul 2016 15:16:34 -0400

Martin,

I supported this draft going forward on its first go-around, and I still
support it! It’s needed functionality.

Cheers,
Andy

On Sun, Jul 10, 2016 at 1:59 PM, Martin Vigoureux <
[email-masked]> wrote:

> draft-ietf-mpls-bfd-directed [2]. As such I am also running the second WG
> LC.
>
> So it is time to state whether or not you are in favour of progressing the
> document. Please also take the time to review the document and post
> comments on its content.
>
> [1]:
> https://mailarchive.ietf.org/arch/msg/mpls/rxnEv4LnUiwhTiZOhowOC6AcHYU

---

From: Jeff Tantsura <[email-masked]>
Date: Sun, 10 Jul 2016 12:28:51 -0700

Support as co-author.

Regards,
Jeff

> On Jul 10, 2016, at 10:59 AM, Martin Vigoureux <[email-masked]> wrote:
> 
> WG,
>

---

From: David Allan I <[email-masked]>
Date: Mon, 11 Jul 2016 18:19:58 +0000

Hi

I've read the draft, it solves a useful problem and AFAIK is technically complete. I'm in favor of progressing the document.

Cheers
Dave

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Martin Vigoureux
Sent: Sunday, July 10, 2016 11:00 AM
To: [email-masked]
Subject: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-directed

WG,

Thank you

Martin

---

From: Mach Chen <[email-masked]>
Date: Tue, 12 Jul 2016 14:15:17 +0000

Support as co-author!

Best regards,
Mach

________________________________________
From: mpls [[email-masked]] on behalf of Martin Vigoureux [[email-masked]]
Sent: Monday, July 11, 2016 1:59
To: [email-masked]
Subject: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-directed

WG,

Thank you

Martin

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 12 Jul 2016 17:10:28 +0000

Support for progressing the document.

--
Uma C.

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Martin Vigoureux
Sent: Sunday, July 10, 2016 11:00 AM
To: [email-masked]
Subject: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-directed

WG,

Thank you

Martin

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sat, 16 Jul 2016 15:35:23 +0000

Hi, Martin,

Admittedly, I had not read or followed this document before. However, I just scanned through it, and I Have at best some fundamental questions and likely some major issues and concerns. I wonder also if you need to Cc the BFD WG, copying the chairs on this response. Copying also SPRING chairs for awareness.

I hope these are useful to this WGLC.

Major Concerns:

As I said, I just glanced through the document, and found these issues, questions, or problems.

1. Motivation for the work.

Uni or bi-directional? The document starts with a fallacy, setting the tone for the document, on the very first sentence:

Abstract

   Bidirectional Forwarding Detection (BFD) is expected to monitor bi-
   directional paths.

This is absolutely not the case, as explained in RFC 5880 Section 2, RFC 5883 Section 4.3 (https://tools.ietf.org/html/rfc5883#section-4.3), and many other places.

The sentence that follows says:

   When a BFD session monitors an explicit routed
   path there is a need to be able to direct egress BFD peer to use
   specific path for the reverse direction of the BFD session.

The question is — why is there that need?

The document then goes on to say:

2.  Problem Statement

   BFD is best suited to monitor bi-directional co-routed paths.

But: First, why is this the case? the BFD specifications do not say so.

And: Second, if there is a co-routed bidirectional path, then there is no need to specify the return path! The return path is basically “back on the other way on this co-routed bidirectional path”, so there is no need for what this document specifies.

Next sentence:

   be co-routed, thus
   fulfilling the implicit BFD requirement

But BFD never has this requirement, implicit or explicit.

I am not going to further dissect each sentence, but the point is that if there’s something co-routed, there’s no need to explicitly point to the return path. If there is not, then why?

2. Technical feasibility

The second major problem area is the actual technical feasibility. A main motivation seems to be “3.1.3.  Segment Routing: MPLS Data Plane Case”.

However, looking at an SR path, it can be constructed by Node-SIDs and Adj-SIDs. Please refer to: https://tools.ietf.org/html/draft-ietf-spring-segment-routing-07#section-3.5

First, Adj-SIDs SHOULD (not MUST) be assigned. This means there is the potential of an Adj-SID not assigned to a local Adj. There’s of course also the cases in which Adj-SIDs can be assigned to bundles, to ECMP/UCMP groups, etc.

The implication here is that there is a possibility that there is no way to exactly explicitly construct a co-routed return path. For example, if the forward path is Node A -> Link X -> Node Z, then the return path needs to go to the node Z. Then it is a loose path (i.e., NOT co-routed) to the adjacent node to A through link X, and then that node needs to have an Adj-SID on the same link, which might not.

3. Actual Protocol Mechanics

Section 3.1.1.  BFD Reverse Path TLV, uses “Target FEC sub-TLV” to define the reverse path. This is consistent with the approach in RFC 7110.

In fact, Section 3.1.2 uses the RFC 7110 sub-TLVs for “Static and RSVP-TE sub-TLVs”.

However, Section 3.1.3, which seems to be a key motivation (“3.1.3.  Segment Routing: MPLS Data Plane Case”), uses “Label Entries” to specify the Path!

I believe this is a serious technical issue. Instead of using Label values, it should use Target FEC Stacks (as with the few other cases above). Labels can change. With labels there is no validation possible that what distributed by a given label distribution protocol is what is meant in the data plane.

In fact, Section 5.2 is trying to assign this for the Target FEC Stack:

    | X (TBD2) | Segment Routing MPLS Tunnel sub-TLV | This document |

But that’s not a Target FEC! It’s a label value!

This should be done by also using the Target FEC Stack.

The Target FEC Stack for SR is defined at https://tools.ietf.org/html/draft-ietf-mpls-spring-lsp-ping-00, but surprisingly, draft-ietf-mpls-spring-lsp-ping (and the SR TFC thereby defined) are not even references in this document.

Section 3.3 of this document does include an older version of that draft, before WG adoption, and is somehow trying to Update it. Instead of updating it from here, it should discuss how to updated it on itself.

As an aside, it’s not clear to me why WGLCing this document (twice) before moving forward with I-D.kumarkini-mpls-spring-lsp-ping.

The Section that follows is: “3.2.  Segment Routing: IPv6 Data Plane Case”, but in this case, I am mostly confused and baffled on how a set of IPv6 addresses can be an MPLS Target FEC Stack.

4. IPR

This document has IPR with specific licensing terms. I would like to understand what parts of the document are potentially covered and understand if there’s ways to work around that.

In summary, browsing through the document, I see high-level problem area issues, feasibility issues, technology issues, and others. Happy to be shown incorrect if I missed or confused anything.

Thanks,

— Carlos.

On Jul 10, 2016, at 1:59 PM, Martin Vigoureux <[email-masked]<mailto:[email-masked]>> wrote:

WG,

Thank you

Martin

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 22 Jul 2016 13:29:38 +0100

It's not your fault, Martin, but I don't understand this second WG last call.

There was no revision to the document, and no discussion on the list that I can
see.
Will we adopt "This WG last call will be repeated until we get the answer we
want" as our normal mode of operation?

I wonder whether, in view of the absence of any changes or discussions, my
opinion from the previous last call still carries over.

For the record, my opinion as stated for the first last call has not changed,
although thanks to the IPR holder for the update that links directly to this
document.

Thanks,
Adrian

> Sent: 10 July 2016 19:00

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 25 Jul 2016 21:06:38 +0000

Hi Carlos,
thank you for your comments. Please see my responses in-line and tagged GIM>>.

                Regards,
                                Greg

From: mpls [mailto:[email-masked]] On Behalf Of Carlos Pignataro (cpignata)
Sent: Saturday, July 16, 2016 8:35 AM
To: Martin Vigoureux <[email-masked]>
Cc: mpls <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-directed

Hi, Martin,

Major Concerns:

Abstract

This is absolutely not the case, as explained in RFC 5880 Section 2, RFC 5883 Section 4.3 (https://tools.ietf.org/html/rfc5883#section-4.3), and many other places.
GIM>> I think that you refer to the following text in RFC 5880:
   BFD can provide failure detection on any kind of path between
   systems, including direct physical links, virtual circuits, tunnels,
   MPLS Label Switched Paths (LSPs), multihop routed paths, and
   unidirectional links (so long as there is some return path, of
   course).
And this is exactly what motivated the work we’re discussing. Consider the situation when the return path, though temporarily, is not available. Consider scenario when node A sends BFD control packets over an LSP to node B and the node B sends its BFD packets over out of band return path, e.g. IP network.  If the loss of continuity between B and A lasts long enough to will detect failure. Should such failure be interpreted as indication of the failure on the monitored LSP or not? The second paragraph in the Introduction section explains the scenario when an explicitly routed LSP being monitored while the return path is over IP network that is based the shortest path paradigm.

The question is — why is there that need?
GIM>> Please see my comment above.

2.  Problem Statement

But: First, why is this the case? the BFD specifications do not say so.
GIM>> If the paths used by forward and return paths are not co-routed that may create ambiguous situation when interpreting failure detection on the node that sends BFD control packets onto the monitored path, e.g. LSP.

And: Second, if there is a co-routed bidirectional path, then there is no need to specify the return path! The return path is basically “back on the other way on this co-routed bidirectional path”, so there is no need for what this document specifies.
GIM>> AFAIK, only MPLS-TP defined p2p bi-directional co-routed LSP. True, co-routed bi-directional tunnel may be constructed by using combination of RSVP’s RRO and ERO as well. But other than that, AFAIK, all objects monitored by multi-hop BFD are not guaranteed to be co-routed.

Next sentence:

   be co-routed, thus

But BFD never has this requirement, implicit or explicit.
GIM>> If the goal of BFD to ensure reliable detection of failures, then co-routed multi-hop path is implied.

I am not going to further dissect each sentence, but the point is that if there’s something co-routed, there’s no need to explicitly point to the return path. If there is not, then why?
GIM>> If there’s no co-routedness between a monitored path and the return path, then this draft provides mechanism that may be used to remove possible ambiguity in interpretation of failure of the return path.

2. Technical feasibility

The implication here is that there is a possibility that there is no way to exactly explicitly construct a co-routed return path. For example, if the forward path is Node A -> Link X -> Node Z, then the return path needs to go to the node Z. Then it is a loose path (i.e., NOT co-routed) to the adjacent node to A through link X, and then that node needs to have an Adj-SID on the same link, which might not.
GIM>> Appreciate your detailed analysis of the Segment Routing use case. We didn’t spell it out in such details but will be glad to add applicability clarification based on your comment.

I believe this is a serious technical issue. Instead of using Label values, it should use Target FEC Stacks (as with the few other cases above). Labels can change. With labels there is no validation possible that what distributed by a given label distribution protocol is what is meant in the data plane.
GIM>> I don’t see need to use Target FEC Stacks as the purpose of the BFD Reverse Path TLV not to verify mapping between the control and the data planes but to provide the remote BFD peer with pre-computed for the reverse path.

The Target FEC Stack for SR is defined at https://tools.ietf.org/html/draft-ietf-mpls-spring-lsp-ping-00, but surprisingly, draft-ietf-mpls-spring-lsp-ping (and the SR TFC thereby defined) are not even references in this document.
GIM>> We haven’t updated the draft just because I-D.kumarkini-mpls-spring-lsp-ping got adopted by the WG. Will certainly update the reference in the next version.

Section 3.3 of this document does include an older version of that draft, before WG adoption, and is somehow trying to Update it. Instead of updating it from here, it should discuss how to updated it on itself.
GIM>> This document enhances LSP Ping for Segment Routing environment and we’ve proposed clarification to use of LSP Ping in Segment Routing when bootstrapping BFD session that, hopefully, will be discussed by MPLS WG in course of this WGLC and used in draft-ietf-mpls-spring-lsp.

The Section that follows is: “3.2.  Segment Routing: IPv6 Data Plane Case”, but in this case, I am mostly confused and baffled on how a set of IPv6 addresses can be an MPLS Target FEC Stack.
GIM>> Agree, IPv6 case is outside the MPLS WG and I’ll remove it for further study.

4. IPR

Thanks,

— Carlos.

WG,

Thank you

Martin