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

From: Gregory Mirsky <[email-masked]>
Date: Sat, 6 Aug 2016 06:31:59 +0000

Hi Adrian,
my apologies for not responding earlier.
I'm working with Carlos to address the technical comments he provided us with. I've prepared the update and as soon as Carlos confirms that proposed changes address his concerns we'll publish it. I don't recall any technical comments during the first WGLC, sorry if I missed any.

	Regards,
		Greg

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Friday, July 22, 2016 5:30 AM
To: 'Martin Vigoureux' <[email-masked]>; [email-masked]
Subject: Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-directed

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

> -----Original Message-----
> From: mpls [mailto:[email-masked]] On Behalf Of Martin 
> Vigoureux
> Sent: 10 July 2016 19:00
> 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, 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/
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

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

---

From: Gregory Mirsky <[email-masked]>
Date: Sat, 6 Aug 2016 06:31:58 +0000

Hi Carlos,
I hope everything is well and you’ll consider my responses. Hope we’re converging.
Looking forward to hear from you.

                Regards,
                                Greg

From: Gregory Mirsky
Sent: Monday, July 25, 2016 2:07 PM
To: 'Carlos Pignataro (cpignata)' <[email-masked]>; 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 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]<mailto:[email-masked]>>
Cc: mpls <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-directed

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.
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 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?
GIM>> Please see my comment above.

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.
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
   fulfilling the implicit BFD requirement

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 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.
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.

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.
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.

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.
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.

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.
GIM>> Agree, IPv6 case is outside the MPLS WG and I’ll remove it for further study.

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,

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

[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/

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

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 10 Aug 2016 04:14:00 +0000

Hi Greg,

Thanks for the response — please find some follow-ups inline.

On Jul 25, 2016, at 5:06 PM, Gregory Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Hi Carlos,

                Regards,
                                Greg

Hi, Martin,

Major Concerns:

Abstract

Not specifically, not only.

My point is that the very first sentence contradicts standards tracks BFD RFCs. BFD also is expected to monitor unidirectional paths.

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?

But this is irrespective of wether the return path is explicit or not, or even if the return path is via some out of band channel. A different way, this is also the case for BFD multihop over plain IP (on a tunnel one way, hop-by-hop routed on the return).

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 fact that the return path goes over the same links as the forward path does not mean that the return path is misprogrammed but the forward path is correctly programmed.

I still believe that the motivation and use case is not well defined or explained.

I still believe this is a bit of a non sequitur. Why does BFD monitoring an explicit routed path imply a need to direct the egress on a path for the reverse direction? That’s not generally a “need” in all situations.

2.  Problem Statement

First, the same ambiguity exists with bi-directional co-routed paths — because links and nodes are not the only resources that need to be common. FIBs can be programmed well on one direction and wrongly on the reverse.

Second, again, why “best suited”? If the BFD specs say that BFD can monitor unidirectional paths (including MPLS LSPs and unidirectional links), seems BFD is not necessarily “best suited to…"

If the path *is* bi-directional co-routed (by whichever method), you would not need this — the was my point, not that some cases are co-routed and others are not.

Next sentence:

   be co-routed, thus

I disagree. Even RFC 5883 says:

   The Bidirectional Forwarding Detection (BFD) protocol [BFD] defines a
   method for liveness detection of arbitrary paths between systems.

and

   BFD can also be useful on arbitrary paths between systems, which may
   span multiple network hops and follow unpredictable paths.

and

   Furthermore, a pair of systems may have multiple paths between them
   that may overlap.  This document describes methods for using BFD in
   such scenarios.

2. Technical feasibility

I do not think it is about Applicability. Given the existence of Adj-SIDs, the question is about technical feasibility. What do you do in the example I detailed above? Seems like there are potential cases in which it is not possible to specify the actual return path desired.

It is not about verification of the control and data planes in the return path.

The reason why RFC 7110 uses FECs and not Labels is that the invariant is the FEC, while the label numerical value can change. Seems like using labels is less robust and more brittle.

draft-ietf-mpls-spring-lsp-ping-00 seems to be a dependency to advance before this.

I still do not understand the technical reason to use MPLS labels and not FECs. Further, using labels can suffer from misdirection if Label assignment changes (for a stable given FEC)

OK.

The issue about using labels (along with the other ones) still remain.

4. IPR

Thanks!

Carlos.

Thanks,

— Carlos.

WG,

Thank you

Martin

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 10 Aug 2016 04:14:59 +0000

Hi Greg,

Apologies for the delay in responding — back from vacation.

Of course I read and considered your responses — I do not believe they solve the technical issues I raised.

Thanks,

— Carlos.

On Aug 6, 2016, at 2:31 AM, Gregory Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Hi Carlos,

                Regards,
                                Greg

From: Gregory Mirsky
Sent: Monday, July 25, 2016 2:07 PM
To: 'Carlos Pignataro (cpignata)' <[email-masked]<mailto:[email-masked]>>; Martin Vigoureux <[email-masked]<mailto:[email-masked]>>
Cc: mpls <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-directed

Hi Carlos,

                Regards,
                                Greg

Hi, Martin,

Major Concerns:

Abstract

2.  Problem Statement

Next sentence:

   be co-routed, thus

2. Technical feasibility

4. IPR

Thanks,

— Carlos.

WG,

Thank you

Martin

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 10 Aug 2016 19:34:58 +0000

Hi Carlos,
thank you for your comments. I hope I understand your concerns better and am able to address them. Please find my follow up notes in-line tagged GIM2>>.

                Regards,
                                Greg

From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
Sent: Tuesday, August 09, 2016 9:14 PM
To: Gregory Mirsky <[email-masked]>
Cc: Martin Vigoureux <[email-masked]>; mpls <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-directed

Hi Greg,

Hi Carlos,

                Regards,
                                Greg

Hi, Martin,

Major Concerns:

Abstract

GIM2>> Would the following change address your concern:
OLD
Bidirectional Forwarding Detection (BFD) is expected to monitor bi- directional paths. 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.
NEW
Bidirectional Forwarding Detection (BFD) is expected to monitor any kind of paths between systems. When a BFD session monitors an explicitly routed uni-directional path there may be a need to direct egress BFD peer to use specific path for the reverse direction of the BFD session.

GIM2>> True, but we’re not solving these other scenarios, only those where monitored path is explicitly routed. We can add explicit statement listing out of the scope scenarios.

The fact that the return path goes over the same links as the forward path does not mean that the return path is misprogrammed but the forward path is correctly programmed.
GIM2>> The purpose of making BFD session use co-routed path is not to verify how it is instantiated in LFIB on a LSR. That is the task for defect localization, not defect detection OAM. Would you agree?

GIM2>> I’ll keep trying.

I still believe this is a bit of a non sequitur. Why does BFD monitoring an explicit routed path imply a need to direct the egress on a path for the reverse direction? That’s not generally a “need” in all situations.
GIM2>> Please see modified Abstract above. It uses “may be a need”

2.  Problem Statement

First, the same ambiguity exists with bi-directional co-routed paths — because links and nodes are not the only resources that need to be common. FIBs can be programmed well on one direction and wrongly on the reverse.
GIM2>> BFD, as other continuity check protocols, only performs defect detection. Defect localization and characterization usually performed with other tools. But having co-routed path for a test session reduces, not eliminates but reduces, ambiguity of defects of the reverse path.
Second, again, why “best suited”? If the BFD specs say that BFD can monitor unidirectional paths (including MPLS LSPs and unidirectional links), seems BFD is not necessarily “best suited to…"
GIM2>> BFD certainly can and being used to monitor uni-directional paths. And usually we don’t think of how the reverse path may affect defect detection or, in case of PM OAM, measured performance metric. Having test session on bi-directional co-routed path makes the test result interpretation more certain.

If the path *is* bi-directional co-routed (by whichever method), you would not need this — the was my point, not that some cases are co-routed and others are not.
GIM>> Yes, and the scope of this proposal is not on already bi-directional co-routed paths, e.g. MPLS-TP p2p bi-directional co-routed LSP. RSVP-TE LSP may be explicitly routed but are unidirectional. And so SR tunnel.

Next sentence:

   be co-routed, thus

and

and

GIM2>> Will remove “… thus fulfilling the implicit BFD requirement” from the document.

2. Technical feasibility

GIM2>> There are many scenarios where it is possible and useful to specify strict explicit path for SR tunnel. To use strict or loose paths – that we leave to the operator to decide. The proposal addresses real scenario, though not all possible ones.

GIM2>> If label value changes, i.e. label withdrawn, then BFD return path for the BFD session may be re-signaled via LSP Ping with the same BFD discriminator.

I still do not understand the technical reason to use MPLS labels and not FECs. Further, using labels can suffer from misdirection if Label assignment changes (for a stable given FEC)
GIM2>> Return path may be re-signaled in such case.

OK.

4. IPR

Thanks!

Carlos.

Thanks,

— Carlos.

WG,

Thank you

Martin

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 16 Aug 2016 13:13:37 +0000

Hi, Greg,

Thank you for the follow-ups. Let me explain a couple of the key concerns top-posting, with more responses inline.

One of the main technical concerns that I have is that segment routing being a loosely source-routed paradigm, there may not even be a bidirectional co-routed path. Take the extreme case of a stack in the forward direction with a single Node SID, PE to PE, and shortest path in-between. Or the case of Parallel Link SIDs with varied weights in different links. How are you providing a return path?

Can you please point to a definition of a co-routed path for Segment Routing from the segment routing architectural documents?

The second main concerns has to do with the proposed use of Labels (which can change) instead of FECs (like RFC 7110).

These two seem to be major technical obstacles to the draft.

On Aug 10, 2016, at 3:34 PM, Gregory Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Hi Carlos,

                Regards,
                                Greg

From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
Sent: Tuesday, August 09, 2016 9:14 PM
To: Gregory Mirsky <[email-masked]<mailto:[email-masked]>>
Cc: Martin Vigoureux <[email-masked]<mailto:[email-masked]>>; mpls <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-directed

Hi Greg,

Hi Carlos,

                Regards,
                                Greg

Hi, Martin,

Major Concerns:

Abstract

Since segment routing uses a loose source-routing paradigm, there may not be explicitly routed or a reverse direction.

See above.

GIM2>> I’ll keep trying.

I think the passive voice hides precision needed.

2.  Problem Statement

Can you please point to a definition of a co-routed path for Segment Routing from the segment routing architectural documents?

Or are you defining that here?

See above.

Next sentence:

   be co-routed, thus

and

and

2. Technical feasibility

The document does not seem to include this applicability. Still, can you please point to a definition of a co-routed path for Segment Routing from the segment routing architectural documents?

There seems to be a difference between strict explicit routing (RSVP-TE) and this capability.
3. Actual Protocol Mechanics

OK.

4. IPR

Thanks!

Carlos.

Thanks,

— Carlos.

Thanks,

— Carlos.

WG,

Thank you

Martin

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 16 Aug 2016 16:22:12 +0000

Hi Carlos,
thank you for clarification of your concerns. Please find my notes in-line and tagged GIM3>>.

                Regards,
                                Greg

Sent: Tuesday, August 16, 2016 6:14 AM

Hi, Greg,

One of the main technical concerns that I have is that segment routing being a loosely source-routed paradigm, there may not even be a bidirectional co-routed path.
GIM3>> I don’t think that your characterization of the Segment Routing as mandating use only loosely source-routed paths is entirely accurate. As in RSVP-TE, source-routed paths may be loosely or strictly source-routed. Excluding option to construct strictly source-routed paths, in my opinion, would significantly limit scope of the Source Routing technology.

Take the extreme case of a stack in the forward direction with a single Node SID, PE to PE, and shortest path in-between. Or the case of Parallel Link SIDs with varied weights in different links. How are you providing a return path?
GIM3>> Authors do not claim that the proposed solution applies to all scenarios there could be in source routing. I think that has been already clarified in the text and in our discussion.

Can you please point to a definition of a co-routed path for Segment Routing from the segment routing architectural documents?
GIM3>> The proposal does not use bi-directional co-routed Segment Routed tunnels as such construct doesn’t yet exists (though in earlier discussions there was some interest in investigating use case for it). On the other hand, definition of co-routedness can be found in MPLS-TP as “co-routed, meaning both directions follow the same path, i.e. traversing the same set of nodes and links”.

The second main concerns has to do with the proposed use of Labels (which can change) instead of FECs (like RFC 7110).
GIM3>> Authors believe that this is workable solution and the return path for the BFD session identified by BFD Discriminator TLV may be re-signaled without affecting state of the session.

Hi Carlos,

                Regards,
                                Greg

Hi Greg,

Hi Carlos,

                Regards,
                                Greg

Hi, Martin,

Major Concerns:

Abstract

See above.

GIM2>> I’ll keep trying.

2.  Problem Statement

See above.

Next sentence:

   be co-routed, thus

and

and

2. Technical feasibility

OK.

4. IPR

Thanks!

Carlos.

Thanks,

— Carlos.

Thanks,

— Carlos.

WG,

Thank you

Martin

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 16 Aug 2016 17:01:48 +0000

Hi, Greg,

I think we got to the source of the technical disagreement. Please find some closing comments inline.

On Aug 16, 2016, at 12:22 PM, Gregory Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Hi Carlos,

                Regards,
                                Greg

Hi, Greg,

Conversely, this potentially seems to apply to a grossly small and limited set of scenarios, if any, yet those scenarios are not discussed in the document, and are not defined to my knowledge in any SPRING document — other than a mention in RFC 7855 of:

   It is obvious that, in the case of long, strict source-routed paths,
   the deployment is possible if the head-end of the explicit path
   supports the instantiation of long explicit paths.

which seems to refer to Node strictness and not necessarily Link strictness, and there is nothing in draft-ietf-spring-segment-routing-09.

There’s no mention of MPLS-TP or SPRING-TP in SPRING docs either that I could find.

If a SPRING stack includes a long set of Node SIDs, each one for each hop, still multiple-links between nodes are not specified and therefore it is not clear how to provide the exact return path (when the link taken is unknown). If the problem space is limited to the case in which for each hop, both Node SID and Adj SID are included, no Anycast, no Parallel Link SID, etc., then practicality seems to get in the way.

There could perhaps be a use of specifying a return path in this case. However, I believe the use is not the scenario targeted, and it is not specifying data plane labels numerically.

Please note there were some additional comments inline, but centered around the same set of topics.

Thanks,

— Carlos.

Hi Carlos,

                Regards,
                                Greg

Hi Greg,

Hi Carlos,

                Regards,
                                Greg

Hi, Martin,

Major Concerns:

Abstract

See above.

GIM2>> I’ll keep trying.

2.  Problem Statement

See above.

Next sentence:

   be co-routed, thus

and

and

2. Technical feasibility

OK.

4. IPR

Thanks!

Carlos.

Thanks,

— Carlos.

Thanks,

— Carlos.

WG,

Thank you

Martin

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 17 Aug 2016 22:19:04 +0000

Hi Carlos,
I believe that new version of the draft addresses all technical comments and now are discussing what each of us believes and how we interpret this or that IETF document. While this is very enlightening and I enjoy this discussion very much I don’t see that I can change how you see the problem this proposal addresses. The MPLS WG had agreed that the problem is real and the proposed solution, within the scope defined, is technically sound.

Regards,
        Greg

Sent: Tuesday, August 16, 2016 10:02 AM

Hi, Greg,

Hi Carlos,

                Regards,
                                Greg

Hi, Greg,

Thanks,

— Carlos.

Hi Carlos,

                Regards,
                                Greg

Hi Greg,

Hi Carlos,

                Regards,
                                Greg

Hi, Martin,

Major Concerns:

Abstract

See above.

GIM2>> I’ll keep trying.

2.  Problem Statement

See above.

Next sentence:

   be co-routed, thus

and

and

2. Technical feasibility

OK.

4. IPR

Thanks!

Carlos.

Thanks,

— Carlos.

Thanks,

— Carlos.

WG,

Thank you

Martin

Subject: [mpls] I-D Action: draft-ietf-mpls-bfd-directed-03.txt
From: "[email-masked]" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Wed, 17 Aug 2016 22:13:27 +0000
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiprotocol Label Switching of the IETF.

        Title           : Bidirectional Forwarding Detection (BFD) Directed Return Path
        Authors         : Greg Mirsky
                          Jeff  Tantsura
                          Ilya Varlashkin
                          Mach(Guoyi) Chen
	Filename        : draft-ietf-mpls-bfd-directed-03.txt
	Pages           : 10
	Date            : 2016-08-17

Abstract:
   Bidirectional Forwarding Detection (BFD) is expected to monitor any
   kind of paths between systems.  When a BFD session monitors an
   explicitly routed uni-directional path there may be a need to direct
   egress BFD peer to use specific path for the reverse direction of the
   BFD session.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mpls-bfd-directed/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-mpls-bfd-directed-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-bfd-directed-03

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 18 Aug 2016 11:09:34 +0100

Greg,
 
I'm disappointed by the last sentence of your email. This a WG last call: its purpose is to determine whether the WG supports the proposed solution. IIRC the reason for this second WG last call is that the WG chairs were unable to determine consensus from the first call.
 
I'm sure it isn't your intention, but your email appears to read, "Let's not debate the problem and direction of the solution because they are not up for discussion." 
 
Obviously you and Carlos have a disagreement about the need for this work and the way the requirements are expressed. Personally, I've got lost in the details of your discussion (not helped by the way the HTML mail presents, below). I suspect that a lot of the problem is around scoping of the problem because RFC 7710 was generally welcomed by the WG, and the fundamentals are surely not so different (although maybe I'm wrong since the IPR disclosures are different).
 
I also suspect that there are some linguistic confusions between the two of you. Sometimes this can be mitigated by rephrasing and using more words. As a case in point, Carlos originally objected to "Bidirectional Forwarding Detection (BFD) is expected to monitor bi-directional paths," noting that, "BFD also is expected to monitor unidirectional paths." The two statements are not actually contradictory and one could say (without damaging the value of the document), "BFD is designed to monitor unidirectional and bidirectional paths."
 
In fact, as we discovered while working on RFC 7710, the false negative may result precisely from using the reverse (co-routed or not) path. So the value of controlling the return path is to help diagnose whether the fault is on the outbound path or the return path, and this applies equally to unidirectional paths and bidirectional paths.
 
Adrian
 
From: mpls [mailto:[email-masked]] On Behalf Of Gregory Mirsky
Sent: 17 August 2016 23:19
To: Carlos Pignataro (cpignata)
Cc: [email-masked]; mpls; [email-masked]
Subject: Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-directed
 
Hi Carlos,
 
Regards,
        Greg

 
Hi, Greg, 

On Aug 16, 2016, at 12:22 PM, Gregory Mirsky <[email-masked]> wrote:
 
Hi Carlos,
 
                Regards,
                                Greg
 
From: Carlos Pignataro (cpignata) [ <mailto:[email-masked]> mailto:[email-masked]] 
Sent: Tuesday, August 16, 2016 6:14 AM
To: Gregory Mirsky < <mailto:[email-masked]> [email-masked]>
Cc: Martin Vigoureux < <mailto:[email-masked]> [email-masked]>; mpls < <mailto:[email-masked]> [email-masked]>;  <mailto:[email-masked]> [email-masked];  <mailto:[email-masked]> [email-masked]
Subject: Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-directed
 
Hi, Greg, 

 

 

 

 

Thanks,
 
— Carlos.
 
On Aug 10, 2016, at 3:34 PM, Gregory Mirsky < <mailto:[email-masked]> [email-masked]> wrote:
 
Hi Carlos,
 
                Regards,
                                Greg
 
From: Carlos Pignataro (cpignata) [ <mailto:[email-masked]> mailto:[email-masked]] 
Sent: Tuesday, August 09, 2016 9:14 PM
To: Gregory Mirsky < <mailto:[email-masked]> [email-masked]>
Cc: Martin Vigoureux < <mailto:[email-masked]> [email-masked]>; mpls < <mailto:[email-masked]> [email-masked]>;  <mailto:[email-masked]> [email-masked];  <mailto:[email-masked]> [email-masked]
Subject: Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-directed
 
Hi Greg, 

On Jul 25, 2016, at 5:06 PM, Gregory Mirsky < <mailto:[email-masked]> [email-masked]> wrote:
 
Hi Carlos,
 
                Regards,
                                Greg
 
From: mpls [ <mailto:[email-masked]> mailto:[email-masked]] On Behalf Of Carlos Pignataro (cpignata)
Sent: Saturday, July 16, 2016 8:35 AM
To: Martin Vigoureux < <mailto:[email-masked]> [email-masked]>
Cc: mpls < <mailto:[email-masked]> [email-masked]>;  <mailto:[email-masked]> [email-masked];  <mailto:[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> 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:

 

See above.

 

GIM2>> I’ll keep trying.

 

 
2.  Problem Statement

 

See above.

 
Next sentence:
 
   be co-routed, thus

 
 
and

and

2. Technical feasibility

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> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-07#section-3.5

 

 

 

 

 
 
The Target FEC Stack for SR is defined at  <https://tools.ietf.org/html/draft-ietf-mpls-spring-lsp-ping-00> 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.

 

OK.

4. IPR

Thanks!
 
Carlos.
 
Thanks,
 
— Carlos.

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

Thank you

Martin

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

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

---

From: Martin Vigoureux <[email-masked]>
Date: Thu, 18 Aug 2016 17:56:56 +0200

Hello Greg,

I have to admit that I am also a bit surprised.

I'd like the technical discussion to continue.

Thank you
martin

Le 18/08/2016 12:09, Adrian Farrel a écrit :
> Greg,
>
> I'm disappointed by the last sentence of your email. This a WG last
> call: its purpose is to determine whether the WG supports the proposed
> solution. IIRC the reason for this second WG last call is that the WG
> chairs were unable to determine consensus from the first call.
>
> I'm sure it isn't your intention, but your email appears to read, "Let's
> not debate the problem and direction of the solution because they are
> not up for discussion."
>
> Obviously you and Carlos have a disagreement about the need for this
> work and the way the requirements are expressed. Personally, I've got
> lost in the details of your discussion (not helped by the way the HTML
> mail presents, below). I suspect that a lot of the problem is around
> scoping of the problem because RFC 7710 was generally welcomed by the
> WG, and the fundamentals are surely not so different (although maybe I'm
> wrong since the IPR disclosures are different).
>
> I also suspect that there are some linguistic confusions between the two
> of you. Sometimes this can be mitigated by rephrasing and using more
> words. As a case in point, Carlos originally objected to "Bidirectional
> Forwarding Detection (BFD) is expected to monitor bi-directional paths,"
> noting that, "BFD also is expected to monitor unidirectional paths." The
> two statements are not actually contradictory and one could say (without
> damaging the value of the document), "BFD is designed to monitor
> unidirectional and bidirectional paths."
>
> In fact, as we discovered while working on RFC 7710, the false negative
> may result precisely from using the reverse (co-routed or not) path. So
> the value of controlling the return path is to help diagnose whether the
> fault is on the outbound path or the return path, and this applies
> equally to unidirectional paths and bidirectional paths.
>
> Adrian
>
> *From:*mpls [mailto:[email-masked]] *On Behalf Of *Gregory Mirsky
> *Sent:* 17 August 2016 23:19
> *To:* Carlos Pignataro (cpignata)
> *Cc:* [email-masked]; mpls; [email-masked]
> *Subject:* Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-directed
>
> Hi Carlos,
>
> I believe that new version of the draft addresses all technical comments
> and now are discussing what each of us believes and how we interpret
> this or that IETF document. While this is very enlightening and I enjoy
> this discussion very much I don’t see that I can change how you see the
> problem this proposal addresses. The MPLS WG had agreed that the problem
> is real and the proposed solution, within the scope defined, is
> technically sound.
>
> Regards,
>
>          Greg
>
> *From:*Carlos Pignataro (cpignata) [mailto:[email-masked]]
> *Sent:* Tuesday, August 16, 2016 10:02 AM
> *To:* Gregory Mirsky <[email-masked]>
> *Cc:* Martin Vigoureux <[email-masked]>; mpls
> <[email-masked]>; [email-masked]; [email-masked]
> *Subject:* Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-directed
>
> Hi, Greg,
>
>     On Aug 16, 2016, at 12:22 PM, Gregory Mirsky
>     <[email-masked] <mailto:[email-masked]>>
>     wrote:
>
>     Hi Carlos,
>
>     *From:*Carlos Pignataro (cpignata) [mailto:[email-masked]]
>     *Sent:*Tuesday, August 16, 2016 6:14 AM
>     *To:*Gregory Mirsky <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc:*Martin Vigoureux <[email-masked]
>     <mailto:[email-masked]>>; mpls <[email-masked]
>     <mailto:[email-masked]>>;[email-masked]
>     <mailto:[email-masked]>;[email-masked]
>     <mailto:[email-masked]>
>     *Subject:*Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-directed
>
>     Hi, Greg,
>
>     Thank you for the follow-ups. Let me explain a couple of the key
>     concerns top-posting, with more responses inline.
>
>     One of the main technical concerns that I have is that segment
>     routing being a loosely source-routed paradigm, there may not even
>     be a bidirectional co-routed path.
>
>     GIM3>> I don’t think that your characterization of the Segment
>     Routing as mandating use only loosely source-routed paths is
>     entirely accurate. As in RSVP-TE, source-routed paths may be loosely
>     or strictly source-routed. Excluding option to construct strictly
>     source-routed paths, in my opinion, would significantly limit scope
>     of the Source Routing technology.
>
>     Take the extreme case of a stack in the forward direction with a
>     single Node SID, PE to PE, and shortest path in-between. Or the case
>     of Parallel Link SIDs with varied weights in different links. How
>     are you providing a return path?
>
>     GIM3>> Authors do not claim that the proposed solution applies to
>     all scenarios there could be in source routing. I think that has
>     been already clarified in the text and in our discussion.
>
> Conversely, this potentially seems to apply to a grossly small and
> limited set of scenarios, if any, yet those scenarios are not discussed
> in the document, and are not defined to my knowledge in any SPRING
> document — other than a mention in RFC 7855 of:
>
> which seems to refer to Node strictness and not necessarily Link
> strictness, and there is nothing in draft-ietf-spring-segment-routing-09.
>
>     Can you please point to a definition of a co-routed path for Segment
>     Routing from the segment routing architectural documents?
>
>     GIM3>> The proposal does not use bi-directional co-routed Segment
>     Routed tunnels as such construct doesn’t yet exists (though in
>     earlier discussions there was some interest in investigating use
>     case for it). On the other hand, definition of co-routedness can be
>     found in MPLS-TP as “co-routed, meaning both directions follow the
>     same path, i.e. traversing the same set of nodes and links”.
>
> If a SPRING stack includes a long set of Node SIDs, each one for each
> hop, still multiple-links between nodes are not specified and therefore
> it is not clear how to provide the exact return path (when the link
> taken is unknown). If the problem space is limited to the case in which
> for each hop, both Node SID and Adj SID are included, no Anycast, no
> Parallel Link SID, etc., then practicality seems to get in the way.
>
>     The second main concerns has to do with the proposed use of Labels
>     (which can change) instead of FECs (like RFC 7110).
>
>     GIM3>> Authors believe that this is workable solution and the return
>     path for the BFD session identified by BFD Discriminator TLV may be
>     re-signaled without affecting state of the session.
>
> There could perhaps be a use of specifying a return path in this case.
> However, I believe the use is not the scenario targeted, and it is not
> specifying data plane labels numerically.
>
>         On Aug 10, 2016, at 3:34 PM, Gregory Mirsky
>         <[email-masked]
>         <mailto:[email-masked]>> wrote:
>
>         Hi Carlos,
>
>         thank you for your comments. I hope I understand your concerns
>         better and am able to address them. Please find my follow up
>         notes in-line tagged GIM2>>.
>
>                          Regards,
>
>                                          Greg
>
>         *From:*Carlos Pignataro (cpignata) [mailto:[email-masked]]
>         *Sent:*Tuesday, August 09, 2016 9:14 PM
>         *To:*Gregory Mirsky <[email-masked]
>         <mailto:[email-masked]>>
>         *Cc:*Martin Vigoureux <[email-masked]
>         <mailto:[email-masked]>>; mpls <[email-masked]
>         <mailto:[email-masked]>>;[email-masked]
>         <mailto:[email-masked]>;[email-masked]
>         <mailto:[email-masked]>
>         *Subject:*Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-directed
>
>         Hi Greg,
>
>             On Jul 25, 2016, at 5:06 PM, Gregory Mirsky
>             <[email-masked]
>             <mailto:[email-masked]>> wrote:
>
>             Hi Carlos,
>
>             *From:*mpls [mailto:[email-masked]]*On Behalf
>             Of*Carlos Pignataro (cpignata)
>             *Sent:*Saturday, July 16, 2016 8:35 AM
>             *To:*Martin Vigoureux <[email-masked]
>             <mailto:[email-masked]>>
>             *Cc:*mpls <[email-masked]
>             <mailto:[email-masked]>>;[email-masked]
>             <mailto:[email-masked]>;[email-masked]
>             <mailto:[email-masked]>
>             *Subject:*Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-directed
>
>             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.
>
>             *_Major Concerns:_*
>             *_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.
>
>         My point is that the very first sentence contradicts standards
>         tracks BFD RFCs. BFD also is expected to monitor unidirectional
>         paths.
>
>
>         Bidirectional Forwarding Detection (BFD) is expected to monitor
>         bi- directional paths. 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.
>
>         NEW
>
>             Bidirectional Forwarding Detection (BFD) is expected to
>             monitor any kind of paths between systems. When a BFD
>             session monitors an explicitly routed uni-directional path
>             there may be a need to direct egress BFD peer to use
>     Since segment routing uses a loose source-routing paradigm, there
>     may not be explicitly routed or a reverse direction.
>
>
>
>             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?
>
>         But this is irrespective of wether the return path is explicit
>         or not, or even if the return path is via some out of band
>         channel. A different way, this is also the case for BFD multihop
>         over plain IP (on a tunnel one way, hop-by-hop routed on the
>         return).
>
>         GIM2>> True, but we’re not solving these other scenarios, only
>         those where monitored path is explicitly routed. We can add
>         explicit statement listing out of the scope scenarios.
>
>     See above.
>
>
>
>
>
>             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 fact that the return path goes over the same links as the
>         forward path does not mean that the return path is misprogrammed
>         but the forward path is correctly programmed.
>
>         GIM2>> The purpose of making BFD session use co-routed path is
>         not to verify how it is instantiated in LFIB on a LSR. That is
>         the task for defect localization, not defect detection OAM.
>         Would you agree?
>
>             /   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./
>
>         I still believe this is a bit of a non sequitur. Why does BFD
>         monitoring an explicit routed path imply a need to direct the
>         egress on a path for the reverse direction? That’s not generally
>         a “need” in all situations.
>
>             /2.  Problem Statement/
>             /   BFD is best suited to monitor bi-directional co-routed
>             paths./
>
>             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.
>
>         First, the same ambiguity exists with bi-directional co-routed
>         paths — because links and nodes are not the only resources that
>         need to be common. FIBs can be programmed well on one direction
>         and wrongly on the reverse.
>
>         GIM2>> BFD, as other continuity check protocols, only performs
>         defect detection. Defect localization and characterization
>         usually performed with other tools. But having co-routed path
>         for a test session reduces, not eliminates but reduces,
>         ambiguity of defects of the reverse path.
>
>     Can you please point to a definition of a co-routed path for Segment
>     Routing from the segment routing architectural documents?
>
>         Second, again, why “best suited”? If the BFD specs say that BFD
>         can monitor unidirectional paths (including MPLS LSPs and
>         unidirectional links), seems BFD is not necessarily “best suited
>         to…"
>
>         GIM2>> BFD certainly can and being used to monitor
>         uni-directional paths. And usually we don’t think of how the
>         reverse path may affect defect detection or, in case of PM OAM,
>         measured performance metric. Having test session on
>         bi-directional co-routed path makes the test result
>         interpretation more certain.
>
>     See above.
>
>
>
>
>
>             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.
>
>         If the path *is* bi-directional co-routed (by whichever method),
>         you would not need this — the was my point, not that some cases
>         are co-routed and others are not.
>
>         GIM>> Yes, and the scope of this proposal is not on already
>         bi-directional co-routed paths, e.g. MPLS-TP p2p bi-directional
>         co-routed LSP. RSVP-TE LSP may be explicitly routed but are
>         unidirectional. And so SR tunnel.
>
>
>             Next sentence:
>
>             /   be co-routed, thus/
>
>             /   fulfilling the implicit BFD requirement/
>
>             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 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.
>
>             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 do not think it is about Applicability. Given the existence of
>         Adj-SIDs, the question is about technical feasibility. What do
>         you do in the example I detailed above? Seems like there are
>         potential cases in which it is not possible to specify the
>         actual return path desired.
>
>
>         GIM2>> There are many scenarios where it is possible and useful
>         to specify strict explicit path for SR tunnel. To use strict or
>         loose paths – that we leave to the operator to decide. The
>         proposal addresses real scenario, though not all possible ones.
>
>     The document does not seem to include this applicability. Still, can
>     you please point to a definition of a co-routed path for Segment
>     Routing from the segment routing architectural documents?
>
>             *_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.
>
>             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.
>
>             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 reason why RFC 7110 uses FECs and not Labels is that the
>         invariant is the FEC, while the label numerical value can
>         change. Seems like using labels is less robust and more brittle.
>
>
>         GIM2>> If label value changes, i.e. label withdrawn, then BFD
>         return path for the BFD session may be re-signaled via LSP Ping
>         with the same BFD discriminator.
>
>             /    | X (TBD2) | Segment Routing MPLS Tunnel sub-TLV | This
>             document |/
>
>             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.
>
>             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.
>
>         I still do not understand the technical reason to use MPLS
>         labels and not FECs. Further, using labels can suffer from
>         misdirection if Label assignment changes (for a stable given FEC)
>
>             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.
>
>     Thanks,
>
>     — Carlos.
>
>
>
>             Thanks,
>
>             — Carlos.
>
>                 On Jul 10, 2016, at 1:59 PM, Martin Vigoureux
>                 <[email-masked]
>                 <mailto:[email-masked]>> wrote:
>
>                 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.
>
>                 [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/
>
>                 [email-masked] <mailto:[email-masked]>

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 18 Aug 2016 16:18:46 +0000

Hi Adrian, et. al,
I sincerely regret if the closing of my previous mail came across in such manner.

Adrian, thank you for pointing to RFC 7710 that addresses very similar problem for LSP Ping. In cases when an ingress node monitors uni-directional path, LSP in case of MPLS, it may not be able to differentiate between defect affecting forward direction and defect affecting reverse direction. Making test packets traverse the same nodes and links, i.e. use co-routed bi-directional path,  improves certainty in defect localization (not to particular link but whether it affects path being monitored or not). Indeed, in case of BFD being used to monitor MPLS network, packets in forward and reverse direction processed using different elements of the fast path. In case explicitly routed RSVP-TE LSP being monitored the proposal refers to the sub-TLV defined in RFC 7710. And for case when BFD monitors explicitly routed Segment Routing tunnel, the proposal introduces new sub-TLV. And this sub-TLV may be used to control return path for LSP Ping as described in RFC 7710.

                Regards,
                                Greg

From: Adrian Farrel [mailto:[email-masked]]
Sent: Thursday, August 18, 2016 3:10 AM
To: Gregory Mirsky <[email-masked]>; 'Carlos Pignataro (cpignata)' <[email-masked]>
Cc: [email-masked]; 'mpls' <[email-masked]>; [email-masked]
Subject: RE: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-directed

Greg,

Adrian

Cc: [email-masked]<mailto:[email-masked]>; mpls; [email-masked]<mailto:[email-masked]>

Hi Carlos,

Regards,
        Greg

Hi, Greg,

Hi Carlos,

                Regards,
                                Greg

Hi, Greg,

Thanks,

— Carlos.

Hi Carlos,

                Regards,
                                Greg

Hi Greg,

Hi Carlos,

                Regards,
                                Greg

Hi, Martin,

Major Concerns:

Abstract

See above.

GIM2>> I’ll keep trying.

2.  Problem Statement

See above.

Next sentence:

   be co-routed, thus

and

and

2. Technical feasibility

OK.

4. IPR

Thanks!

Carlos.

Thanks,

— Carlos.

Thanks,

— Carlos.

WG,

Thank you

Martin

---

From: Eric Gray <[email-masked]>
Date: Fri, 19 Aug 2016 19:02:20 +0000

Hi Adrian,

                Correct me if I am wrong, but aren’t you fudging the distinction between WG Adoption and WG Last Call just a bit?

                My understanding is that WG adoption is intended to determine if the WG supports developing a specific proposed solution, and WG Last Call is more about whether or not the WG  believes the solution is complete and not in conflict with other work in the WG.

                Usually, we should expect that the direction a draft is supposed to be headed is determined well before last call, hence it is reasonable to suppose that a minority arguing to take a different approach are somewhat out of line.

                Agreed, if the WG has – for whatever reason – substantially changed its collective opinion since adoption and feels the solution is no longer supportable, then WG Last Call is pretty much the last available time to establish this.  But I suspect the bar for establishing that this is the current WG rough consensus needs to be pretty high (more than a relatively small number of dissenters) or we will be setting ourselves up for doing even more work that somehow never leads to any sort of satisfactory conclusion.

                Do you think this is the point we are at?

                On the quasi-technical issue you’re making (or supporting), I think there is some confusion.  RFC 7710 is probably not the RFC you meant to refer to; RFC 7710 is “Captive-Portal Identification Using DHCP or Router Advertisements (RAs)” and does not mention BFD at all.

                Possibly you meant to refer instead to RFC 7110, as this draft does?

                In any case, there are a few language issues in this discussion.  There is a difference between “BFD is also expected to monitor unidirectional paths” (which MAY be true) and “BFD MAY also be used to monitor unidirectional paths” (which IS mostly true).  And I think people should take some minor exception to your wording that “BFD is designed to monitor unidirectional and bidirectional paths” since the “B” has a pretty much unambiguous meaning.  It is clear that BFD may be capable of monitoring a unidirectional path – assuming that some sort of reverse path exist and may practically be used for this purpose (which – in spite of the fact that this is the most common case – is not necessarily true).

                Specifically, though I would not expect a revision just to address this, I find the current wording (based on your comments below) a little misleading, because now it says “Bidirectional Forwarding Detection (BFD) is expected to monitor any kind of paths between systems.”  This is pretty much what your comment implies, but is clearly not true (from an English language perspective) because any such expectation clearly will not scale (there are a great many systems with a great many more paths between them, hence expecting BFD to monitor any kind of path between systems is setting our expectations a little high).  This is the difference between expecting <protocol X> to do <Y> and expecting <protocol X> to be able to do <Y>.

                In addition to not scaling, because there are scenarios in which a practical usable reverse path may not exist, this statement is not actually true even if re-phrased as “BFD may be used to monitor any kind of path between systems.”  As an example of a case where this is clearly not true in any practical sense, it would – from a practical and feasibility perspective – probably be a poor idea to monitor Satellite Television reception (for the path from satellite to however many Television receivers) using BFD.

--
Eric

From: mpls [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Thursday, August 18, 2016 6:10 AM
To: Gregory Mirsky <[email-masked]>; 'Carlos Pignataro (cpignata)' <[email-masked]>
Cc: 'mpls' <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-directed

Greg,

Adrian

Hi Carlos,

Regards,
        Greg

Hi, Greg,

Hi Carlos,

                Regards,
                                Greg

Hi, Greg,

Thanks,

— Carlos.

Hi Carlos,

                Regards,
                                Greg

Hi Greg,

Hi Carlos,

                Regards,
                                Greg

Hi, Martin,

Major Concerns:

Abstract

See above.

GIM2>> I’ll keep trying.

2.  Problem Statement

See above.

Next sentence:

   be co-routed, thus

and

and

2. Technical feasibility

OK.

4. IPR

Thanks!

Carlos.

Thanks,

— Carlos.

Thanks,

— Carlos.

WG,

Thank you

Martin

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Fri, 19 Aug 2016 19:56:56 +0000

Hi All,

Before having a lengthy discussion on WG Adoption vs. WG Last Call, the definition of WG Last Call is simply “WG decides that a document is ready for publication”. On this thread, I think what is being debated is “what is consensus”? Suggest reading RFC7282, especially section 6.

Two inputs: (1) we need more technical debate to understand the issues being raised (refer to RFC7282/section 6 and Martin has already said this on the list) (2) we need more supporters, yes, we have the co-authors, but we need more folks to speak up. Maybe not 100 as in section 6☺, but we need more input from the WG.

And don’t forget, this solution is not “rubber stamped” until it gets approved by the IESG.

Good weekends!
Deborah

From: mpls [mailto:[email-masked]] On Behalf Of Eric Gray
Sent: Friday, August 19, 2016 3:02 PM
To: [email-masked]; Gregory Mirsky <[email-masked]>; 'Carlos Pignataro (cpignata)' <[email-masked]>
Cc: 'mpls' <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-directed

Hi Adrian,

--
Eric

From: mpls [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Thursday, August 18, 2016 6:10 AM
To: Gregory Mirsky <[email-masked]<mailto:[email-masked]>>; 'Carlos Pignataro (cpignata)' <[email-masked]<mailto:[email-masked]>>
Cc: 'mpls' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-directed

Greg,

Adrian

Hi Carlos,

Regards,
        Greg

Hi, Greg,

Hi Carlos,

                Regards,
                                Greg

Hi, Greg,

Thanks,

— Carlos.

Hi Carlos,

                Regards,
                                Greg

Hi Greg,

Hi Carlos,

                Regards,
                                Greg

Hi, Martin,

Major Concerns:

Abstract

See above.

GIM2>> I’ll keep trying.

2.  Problem Statement

See above.

Next sentence:

   be co-routed, thus

and

and

2. Technical feasibility

OK.

4. IPR

Thanks!

Carlos.

Thanks,

— Carlos.

Thanks,

— Carlos.

WG,

Thank you

Martin

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 19 Aug 2016 16:13:56 -0400

Adrian,

I believe you meant RFC 7110, not 7710, which is a very different beast
indeed. :-)

Cheers,
Andy

On Thu, Aug 18, 2016 at 6:09 AM, Adrian Farrel <[email-masked]> wrote:

> Greg,
>
>
>
> I'm disappointed by the last sentence of your email. This a WG last call:
> its purpose is to determine whether the WG supports the proposed solution.
> IIRC the reason for this second WG last call is that the WG chairs were
> unable to determine consensus from the first call.
>
>
>
> not debate the problem and direction of the solution because they are not
> up for discussion."
>
>
>
> Obviously you and Carlos have a disagreement about the need for this work
> and the way the requirements are expressed. Personally, I've got lost in
> the details of your discussion (not helped by the way the HTML mail
> presents, below). I suspect that a lot of the problem is around scoping of
> the problem because RFC 7710 was generally welcomed by the WG, and the
> fundamentals are surely not so different (although maybe I'm wrong since
> the IPR disclosures are different).
>
>
>
> of you. Sometimes this can be mitigated by rephrasing and using more words.
> As a case in point, Carlos originally objected to "Bidirectional Forwarding
> Detection (BFD) is expected to monitor bi-directional paths," noting that,
> "BFD also is expected to monitor unidirectional paths." The two statements
> are not actually contradictory and one could say (without damaging the
> value of the document), "BFD is designed to monitor unidirectional and
> bidirectional paths."
>
>
>
> may result precisely from using the reverse (co-routed or not) path. So the
> value of controlling the return path is to help diagnose whether the fault
> is on the outbound path or the return path, and this applies equally to
> unidirectional paths and bidirectional paths.
>
>
>
> Adrian
>
>
>
> *From:* mpls [mailto:[email-masked]] *On Behalf Of *Gregory Mirsky
> and now are discussing what each of us believes and how we interpret this
> or that IETF document. While this is very enlightening and I enjoy this
> discussion very much I don’t see that I can change how you see the problem
> this proposal addresses. The MPLS WG had agreed that the problem is real
> and the proposed solution, within the scope defined, is technically sound.
>
>
>
> Regards,
>
>         Greg
>
>
>
>
>
>
>
> *From:* Carlos Pignataro (cpignata) [mailto:[email-masked]]
> *Cc:* Martin Vigoureux <[email-masked]>; mpls <[email-masked]>;
> [email-masked]; [email-masked]
> *From:* Carlos Pignataro (cpignata) [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Tuesday, August 16, 2016 6:14 AM
> *Cc:* Martin Vigoureux <[email-masked]>; mpls <[email-masked]>;
>  [email-masked]; [email-masked]
> One of the main technical concerns that I have is that segment routing
> being a loosely source-routed paradigm, there may not even be a
> bidirectional co-routed path.
>
> GIM3>> I don’t think that your characterization of the Segment Routing as
> mandating use only loosely source-routed paths is entirely accurate. As in
> RSVP-TE, source-routed paths may be loosely or strictly source-routed.
> Excluding option to construct strictly source-routed paths, in my opinion,
> would significantly limit scope of the Source Routing technology.
>
>
>
> Take the extreme case of a stack in the forward direction with a single
> Node SID, PE to PE, and shortest path in-between. Or the case of Parallel
> Link SIDs with varied weights in different links. How are you providing a
> return path?
>
> GIM3>> Authors do not claim that the proposed solution applies to all
> scenarios there could be in source routing. I think that has been already
> clarified in the text and in our discussion.
>
>
>
> Conversely, this potentially seems to apply to a grossly small and limited
> set of scenarios, if any, yet those scenarios are not discussed in the
> document, and are not defined to my knowledge in any SPRING document —
> other than a mention in RFC 7855 of:
>
>
>
> GIM3>> The proposal does not use bi-directional co-routed Segment Routed
> tunnels as such construct doesn’t yet exists (though in earlier discussions
> there was some interest in investigating use case for it). On the other
> hand, definition of co-routedness can be found in MPLS-TP as “co-routed,
> meaning both directions follow the same path, i.e. traversing the same set
> of nodes and links”.
>
>
>
> If a SPRING stack includes a long set of Node SIDs, each one for each hop,
> still multiple-links between nodes are not specified and therefore it is
> not clear how to provide the exact return path (when the link taken is
> unknown). If the problem space is limited to the case in which for each
> hop, both Node SID and Adj SID are included, no Anycast, no Parallel Link
> SID, etc., then practicality seems to get in the way.
>
>
>
>
>
> The second main concerns has to do with the proposed use of Labels (which
> can change) instead of FECs (like RFC 7110).
>
> GIM3>> Authors believe that this is workable solution and the return path
> for the BFD session identified by BFD Discriminator TLV may be re-signaled
> without affecting state of the session.
>
>
>
>
>
> On Aug 10, 2016, at 3:34 PM, Gregory Mirsky <[email-masked]>
> wrote:
>
>
>
> Hi Carlos,
>
> thank you for your comments. I hope I understand your concerns better and
> am able to address them. Please find my follow up notes in-line tagged
> GIM2>>.
>
>
>
>                 Regards,
>
>                                 Greg
>
>
>
> *From:* Carlos Pignataro (cpignata) [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Tuesday, August 09, 2016 9:14 PM
> *Cc:* Martin Vigoureux <[email-masked]>; mpls <[email-masked]>;
>  [email-masked]; [email-masked]
> On Jul 25, 2016, at 5:06 PM, Gregory Mirsky <[email-masked]>
> wrote:
>
>
>
> Hi Carlos,
>
> *From:* mpls [mailto:[email-masked] <[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]
> 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.
>
>
>
> *Major Concerns:*
> *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.
>
> My point is that the very first sentence contradicts standards tracks BFD
> RFCs. BFD also is expected to monitor unidirectional paths.
>
>
> directional paths. 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.
>
> NEW
>
> Bidirectional Forwarding Detection (BFD) is expected to monitor any kind
> of paths between systems. When a BFD session monitors an explicitly routed
> uni-directional path there may be a need to direct egress BFD peer to use
> Since segment routing uses a loose source-routing paradigm, there may not
> be explicitly routed or a reverse direction.
>
>
>
> 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?
>
>
>
> But this is irrespective of wether the return path is explicit or not, or
> even if the return path is via some out of band channel. A different way,
> this is also the case for BFD multihop over plain IP (on a tunnel one way,
> hop-by-hop routed on the return).
>
>
>
> GIM2>> True, but we’re not solving these other scenarios, only those where
> monitored path is explicitly routed. We can add explicit statement listing
> out of the scope scenarios.
>
>
>
>
>
> See above.
>
>
>
>
>
> 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 fact that the return path goes over the same links as the forward path
> does not mean that the return path is misprogrammed but the forward path is
> correctly programmed.
>
> GIM2>> The purpose of making BFD session use co-routed path is not to
> verify how it is instantiated in LFIB on a LSR. That is the task for defect
> localization, not defect detection OAM. Would you agree?
>
>
>
> *   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.*
>
>
>
> I still believe this is a bit of a non sequitur. Why does BFD monitoring
> an explicit routed path imply a need to direct the egress on a path for the
> reverse direction? That’s not generally a “need” in all situations.
>
> *2.  Problem Statement*
> *   BFD is best suited to monitor bi-directional co-routed paths.*
>
>
>
> 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.
>
>
>
>
>
> First, the same ambiguity exists with bi-directional co-routed paths —
> because links and nodes are not the only resources that need to be common.
> FIBs can be programmed well on one direction and wrongly on the reverse.
>
> GIM2>> BFD, as other continuity check protocols, only performs defect
> detection. Defect localization and characterization usually performed with
> other tools. But having co-routed path for a test session reduces, not
> eliminates but reduces, ambiguity of defects of the reverse path.
>
>
>
> Second, again, why “best suited”? If the BFD specs say that BFD can
> monitor unidirectional paths (including MPLS LSPs and unidirectional
> links), seems BFD is not necessarily “best suited to…"
>
> GIM2>> BFD certainly can and being used to monitor uni-directional paths.
> And usually we don’t think of how the reverse path may affect defect
> detection or, in case of PM OAM, measured performance metric. Having test
> session on bi-directional co-routed path makes the test result
> 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.
>
>
>
> If the path *is* bi-directional co-routed (by whichever method), you would
> not need this — the was my point, not that some cases are co-routed and
> others are not.
>
> GIM>> Yes, and the scope of this proposal is not on already bi-directional
> co-routed paths, e.g. MPLS-TP p2p bi-directional co-routed LSP. RSVP-TE LSP
> may be explicitly routed but are unidirectional. And so SR tunnel.
>
>
>
>
> Next sentence:
>
>
>
> *   be co-routed, thus*
>
> *   fulfilling the implicit BFD requirement*
>
>
>
> 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 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.
>
> 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 do not think it is about Applicability. Given the existence of Adj-SIDs,
> the question is about technical feasibility. What do you do in the example
> I detailed above? Seems like there are potential cases in which it is not
> possible to specify the actual return path desired.
>
>
> GIM2>> There are many scenarios where it is possible and useful to specify
> strict explicit path for SR tunnel. To use strict or loose paths – that we
> leave to the operator to decide. The proposal addresses real scenario,
> though not all possible ones.
>
>
>
>
>
> The document does not seem to include this applicability. Still, can you
> please point to a definition of a co-routed path for Segment Routing from
> the segment routing architectural documents?
>
>
>
> *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.
>
>
>
> 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.
>
> 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 reason why RFC 7110 uses FECs and not Labels is that the invariant is
> the FEC, while the label numerical value can change. Seems like using
> labels is less robust and more brittle.
>
>
> GIM2>> If label value changes, i.e. label withdrawn, then BFD return path
> for the BFD session may be re-signaled via LSP Ping with the same BFD
> discriminator.
>
>
>
> *    | X (TBD2) | Segment Routing MPLS Tunnel sub-TLV | This document |*
>
>
>
> 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.
>
> 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.
>
>
>
> 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.
>
>
>
>
>
> I still do not understand the technical reason to use MPLS labels and not
> FECs. Further, using labels can suffer from misdirection if Label
> assignment changes (for a stable given FEC)
>
> 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.
>
>
>
> Thanks,
>
>
>
> — Carlos.
>
>
>
>
>
> Thanks,
>
>
>
> — Carlos.
>
>
>
> On Jul 10, 2016, at 1:59 PM, Martin Vigoureux <[email-masked]>
> wrote:
>
>
>
> WG,
>
> 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.
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sat, 20 Aug 2016 05:10:51 +0000

Shepherd, Chairs,

I do not support this document advancing based on this new revision. I believe there are significant unaddressed major technical concerns. I list again some of these below.

Dear Greg,

I support the specification of the control/direction of the return path of a BFD session in an MPLS environment. However, this document is neither well scoped nor technically sound. The new revision does not address the concerns I previously shared either.  The new revision does remove the “Segment Routing: IPv6 Data Plane Case”. It is was not clear how the return path of a bidirectional LSP is IPv6 and not MPLS. This was an indication that the document had not received adequate review (to catch that so late)

Seemingly, I was likely not clear enough before with my descriptions, apologies; I will try again.

[Reading your last sentence, I’ll point out though that a WG consensus call is with the shepherd and chairs. There is an inherent contradiction between being enlightened by the discussion and not wanting to listen.]

Major Issues:

1. Document scope and problem being solved.

https://tools.ietf.org/html/draft-ietf-mpls-bfd-directed-03#section-2 describes the problem solved. It says:

   BFD is best suited to monitor bi-directional co-routed paths.  In
   most cases, given stable environments, the forward and reverse
   directions between two nodes are likely to be co-routed.

That statement is unsubstantiated, and arguably conjecture. I do not believe that “in most cases the forward and reverse directions between two nodes are likely to be co-routed.”
If the document makes that claim, based on which the problem statement is supported, please provide an adequate citation.

IGP Metrics are not symmetric, very many times!

It then goes to describe the problem as:

   o  a failure detection by ingress node on the reverse path cannot be
      interpreted as bi-directional failure with all the certainty and
      thus trigger, for example, protection switchover of the forward
      direction without possibility of being a false positive defect
      notification.

But this mis-describes the problem statement. It really has not to do with co-routedness. In fact, the problem statement is applicable to uni and bidirectional (co-routed or associated).

For bidirectional, test both directions, for unidirectional, minimize false negatives.

Even before the document says:

  The fact that BFD control
   packets are not guaranteed to cross the same links and nodes in both
   forward and reverse directions is a significant factor in producing
   false positive defect notifications, i.e. false alarms, if used by
   the ingress BFD peer to deduce the state of the forward direction.

This is a mischaracterization. A return path going over the same nodes and links as the forward path does not guarantee or maximize the chances of the return path being the best path. A misprograming of LFIB in one direction does not affect the other one, the receive and transmit optics are different, etc.

Net-net, sections 1 and 2 require a major rewriting. RFC 7110 is so very much more deliberately scoped.

2. Lack of feasibility of use cases.

SR does not work as described in this document, and SR co-routed is most times NOT possible. Most use cases of segment routing do not allow for building a co-routed return path.

Take Figure 3 from this document for example:

           C---------D
           |         |
   A-------B         G-----H
           |         |
           E---------F

If a forward direction between “A” and “H” has the following Node SIDs: {G; H}, then it is not possible to know if it’s going ABCDGH or ABEFGH. How is then the return path to be constructed to be co-routed?

Now, assume that the link between B and C is actually 3 parallel links, and there’s a Parallel Adj-SID (https://tools.ietf.org/html/draft-ietf-spring-segment-routing-09#section-3.5.1) with 8% weight on a link and 92% on a second (0% on a third). How is the return path constructed?

I believe this is the major issue with this document.

As I mentioned already, the sub-TLVs for TFS defined in draft-ietf-mpls-spring-lsp-ping should be used — and not define a sub-TLV that actually does NOT work with LSP Ping.

3. Lack of practicality also (or at least missing explanation in the document of when things might not work in practice)

Further, most cases will NOT specify every node (and every link) as this document seems to expect (otherwise, it’s a very loose source routed return path.

RFC 7855 says:

Which grossly limits the real and practical feasibility.

4. Protocol Constructs.

Section 3.1.1 of this document utilizes the same approach as in RFC 7110, which is to include a Target FEC Stack (TFS) from LSP Ping that identifies the return LSP to be used. So does Section 3.1.2, also directly modeling after RFC 7110.

However, Section 3.1.3. uses "Label Entry n” (assuming this means “Label Stack Entry”).

This is a major and significant departure. Instead of specifying the FEC, it specifies the Label numerically. I believe that the FEC should be used (as defined in the appropriate MPLS LSP Ping for SR document), and NOT the numerical value of a label. Why this departure?

Having a Segment Routing section not talk about SIDs, not differentiating Node SIDs vs. Adj-SIDs, and not talking about FECs, is clearly missing something fundamental…

5. Reply-mode-simple?

By the way, the approach of RFC 7737 which updates RFC 7110, should be considered. That is, if there;s a “specified return path” element without an actual return path, then the return node injects responses into the return path of a bidirectional LSP. This approach greatly simplifies operations in presence of bidir LSPs.

5. Major Conflict created with LSP Ping

As just mentioned, somehow, this document defines an “Segment Routing MPLS Tunnel sub-TLV” using Labels.

This is defined within an LSP Ping Registry: "Sub-TLVs for TLV Types 1, 16, and 21"

However, how this sub-TLV works for LSP Ping with a TLV Type 1 of Target FEC Stack is a mystery. It does NOT.

This major conflict is created by specifying an LSP Ping protocol construct outside LSP Ping, and worst yet with an LSE. Instead, I recommend this document for BFD actually uses the MPLS LSP Ping for SR sub-TLVs defined (for TFS for Node-SID, Adj-SID, etc), draft-ietf-mpls-spring-lsp-ping.

6. Race Conditions unidentified.

This document does not explain what happens if both ends of a bidirectional LSP start the same procedure, and how this disambiguation is done. This is a big gap and source of operational issues.

7. BFD Session maintenance unspecified.

RFC 7110 does not deal with the maintenance of a long-lived session. However, a BFD session is expected to remain with state maintained for some time (as oppose to an asynchronous LSP Ping). What happens if the return FEC requested suddenly goes down?

This problem gets compounded for the SR case as presented, since its not using a FEC...

I’ll stop here because I am running out of ink.

Best,

— Carlos.

On Aug 17, 2016, at 6:19 PM, Gregory Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Hi Carlos,

Regards,
        Greg

Hi, Greg,

Hi Carlos,

                Regards,
                                Greg

Hi, Greg,

Thanks,

— Carlos.

Hi Carlos,

                Regards,
                                Greg

Hi Greg,

Hi Carlos,

                Regards,
                                Greg

Hi, Martin,

Major Concerns:

Abstract

See above.

GIM2>> I’ll keep trying.

2.  Problem Statement

See above.

Next sentence:

   be co-routed, thus

and

and

2. Technical feasibility

OK.

4. IPR

Thanks!

Carlos.

Thanks,

— Carlos.

Thanks,

— Carlos.

WG,

Thank you

Martin

<Mail Attachment.eml>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sat, 20 Aug 2016 05:15:31 +0000

Greg,

There’s much more details in the previous response, but please find one very specific question inline.

On Aug 18, 2016, at 12:18 PM, Gregory Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Hi Adrian, et. al,

Adrian, thank you for pointing to RFC 7710 that addresses very similar problem for LSP Ping. In cases when an ingress node monitors uni-directional path, LSP in case of MPLS, it may not be able to differentiate between defect affecting forward direction and defect affecting reverse direction. Making test packets traverse the same nodes and links, i.e. use co-routed bi-directional path,  improves certainty in defect localization (not to particular link but whether it affects path being monitored or not). Indeed, in case of BFD being used to monitor MPLS network, packets in forward and reverse direction processed using different elements of the fast path. In case explicitly routed RSVP-TE LSP being monitored the proposal refers to the sub-TLV defined in RFC 7710. And for case when BFD monitors explicitly routed Segment Routing tunnel, the proposal introduces new sub-TLV.

This proposal is defining a sub-TLV for the MPLS LSP Ping Target FEC Stack (TFS) — in fact, "Sub-TLVs for TLV Types 1, 16, and 21”. However, this proposed sub-TLV includes a bunch of Labels and not a FEC.

How does this proposed newly defined “Segment Routing MPLS Tunnel sub-TLV" for TFS work with LSP Ping (where this registry resides, and the basis for RFC 7110 to work)?

— Carlos.

And this sub-TLV may be used to control return path for LSP Ping as described in RFC 7710.

                Regards,
                                Greg

Cc: [email-masked]<mailto:[email-masked]>; 'mpls' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Greg,

Adrian

Hi Carlos,

Regards,
        Greg

Hi, Greg,

Hi Carlos,

                Regards,
                                Greg

Hi, Greg,

Thanks,

— Carlos.

Hi Carlos,

                Regards,
                                Greg

Hi Greg,

Hi Carlos,

                Regards,
                                Greg

Hi, Martin,

Major Concerns:

Abstract

See above.

GIM2>> I’ll keep trying.

2.  Problem Statement

See above.

Next sentence:

   be co-routed, thus

and

and

2. Technical feasibility

OK.

4. IPR

Thanks!

Carlos.

Thanks,

— Carlos.

Thanks,

— Carlos.

WG,

Thank you

Martin

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sat, 20 Aug 2016 05:21:55 +0000

Eric,

On Aug 19, 2016, at 3:02 PM, Eric Gray <[email-masked]<mailto:[email-masked]>> wrote:

Hi Adrian,

                In any case, there are a few language issues in this discussion.  There is a difference between “BFD is also expected to monitor unidirectional paths” (which MAY be true) and “BFD MAY also be used to monitor unidirectional paths” (which ISmostly true).  And I think people should take some minor exception to your wording that “BFD is designed to monitor unidirectional and bidirectional paths” since the “B” has a pretty much unambiguous meaning.  It is clear that BFD may be capable of monitoring a unidirectional path – assuming that some sort of reverse path exist and may practically be used for this purpose (which – in spite of the fact that this is the most common case – is not necessarily true).

You seem to take exception with the language “any kind of paths between systems” (based on the added emphasis).

When a document is talking about a previously specified protocol, I always find the safest path to go and look up and read the actual specification of said protocol. In this case we are talking about BFD.

https://tools.ietf.org/html/rfc5880
“   BFD can provide failure detection on any kind of path between
   systems”

https://tools.ietf.org/html/rfc5883
“   The Bidirectional Forwarding Detection (BFD) protocol [BFD] defines a
   method for liveness detection of arbitrary paths between systems."

A citation is worth many paragraphs :-)

Thanks,

— Carlos.

--
Eric

Greg,

Adrian

Hi Carlos,

Regards,
        Greg

Hi, Greg,

Hi Carlos,

                Regards,
                                Greg

Hi, Greg,

Thanks,

— Carlos.

Hi Carlos,

                Regards,
                                Greg

Hi Greg,

Hi Carlos,

                Regards,
                                Greg

Hi, Martin,

Major Concerns:

Abstract

See above.

GIM2>> I’ll keep trying.

2.  Problem Statement

See above.

Next sentence:

   be co-routed, thus

and

and

2. Technical feasibility

OK.

4. IPR

Thanks!

Carlos.

Thanks,

— Carlos.

Thanks,

— Carlos.

WG,

Thank you

Martin

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sat, 20 Aug 2016 05:28:25 +0000

Hi, Deborah,

On Aug 19, 2016, at 3:56 PM, BRUNGARD, DEBORAH A <[email-masked]<mailto:[email-masked]>> wrote:

Hi All,

Two inputs: (1) we need more technical debate to understand the issues being raised (refer to RFC7282/section 6 and Martin has already said this on the list)

Some Technical concerns at:
https://www.ietf.org/mail-archive/web/mpls/current/msg15860.html
https://www.ietf.org/mail-archive/web/mpls/current/msg16004.html

In particular I would love to hear why the proposed structure and definition of the SR Tunnel sub-TLV is a good idea (and why the concerns I raised are not valid)

(2) we need more supporters, yes, we have the co-authors, but we need more folks to speak up. Maybe not 100 as in section 6☺, but we need more input from the WG.

+1!

“The proposed definition breaks LSP Ping if the SR Sub-TLV is used in the TLV 1 (TFS) of LSP Ping (among other things)

Good weekends!

Have a great weekend!

— Carlos.

Deborah

To: [email-masked]<mailto:[email-masked]>; Gregory Mirsky <[email-masked]<mailto:[email-masked]>>; 'Carlos Pignataro (cpignata)' <[email-masked]<mailto:[email-masked]>>

Hi Adrian,

--
Eric

Greg,

Adrian

Hi Carlos,

Regards,
        Greg

Hi, Greg,

Hi Carlos,

                Regards,
                                Greg

Hi, Greg,

Thanks,

— Carlos.

Hi Carlos,

                Regards,
                                Greg

Hi Greg,

Hi Carlos,

                Regards,
                                Greg

Hi, Martin,

Major Concerns:

Abstract

See above.

GIM2>> I’ll keep trying.

2.  Problem Statement

See above.

Next sentence:

   be co-routed, thus

and

and

2. Technical feasibility

OK.

4. IPR

Thanks!

Carlos.

Thanks,

— Carlos.

Thanks,

— Carlos.

WG,

Thank you

Martin

---

From: Loa Andersson <[email-masked]>
Date: Tue, 23 Aug 2016 11:00:02 +0200

Folks,
I'm not the Shepherd of this document, but some comment (that might
look like procedural)!

I believe that Martin is right holding off the closure of the wglc,
until the technical and IPR issues are resolved.

- I see no convergence on the issues raised by Carlos
- the IPR issues where the working failed to reach consensus on
   the first wglc are still open

/Loa

On 2016-08-20 07:28, Carlos Pignataro (cpignata) wrote:
>> Before having a lengthy discussion on WG Adoption vs. WG Last Call,
>> the definition of WG Last Call is simply “WG decides that a document
>> is ready for publication”. On this thread, I think what is being
>> debated is “what is consensus”? Suggest reading RFC7282, especially
>> section 6.
>>
>> Two inputs: (1) we need more technical debate to understand the issues
>> being raised (refer to RFC7282/section 6 and Martin has already said
>> this on the list)
>
> In particular I would love to hear why the proposed structure and
> definition of the SR Tunnel sub-TLV is a good idea (and why the concerns
> I raised are not valid)
>
>> (2) we need more supporters, yes, we have the co-authors, but we need
>> more folks to speak up. Maybe not 100 as in section 6J, but we need
>> more input from the WG.
>>
>
> +1!
>
> “The proposed definition breaks LSP Ping if the SR Sub-TLV is used in
> the TLV 1 (TFS) of LSP Ping (among other things)
>
>> *From:* mpls [mailto:[email-masked]] *On Behalf Of *Eric Gray
>> *Sent:* Friday, August 19, 2016 3:02 PM
>> *To:* [email-masked] <mailto:[email-masked]>; Gregory Mirsky
>> <[email-masked] <mailto:[email-masked]>>;
>> 'Carlos Pignataro (cpignata)' <[email-masked]
>> <mailto:[email-masked]>>
>> *Cc:* 'mpls' <[email-masked]
>> <mailto:[email-masked]>>; [email-masked]
>> <mailto:[email-masked]>; [email-masked]
>>                 Correct me if I am wrong, but aren’t you fudging the
>> distinction between WG Adoption and WG Last Call just a bit?
>>
>>                 My understanding is that WG adoption is intended to
>> determine if the WG supports developing a specific proposed solution,
>> and WG Last Call is more about whether or not the WG  believes the
>> solution is complete and not in conflict with other work in the WG.
>>
>>                 Usually, we should expect that the direction a draft
>> is supposed to be headed is determined well before last call, hence it
>> is reasonable to suppose that a minority arguing to take a different
>> approach are somewhat out of line.
>>
>>                 Agreed, if the WG has – for whatever reason –
>> substantially changed its collective opinion since adoption and feels
>> the solution is no longer supportable, then WG Last Call is pretty
>> much the last available time to establish this.  But I suspect the bar
>> for establishing that this is the current WG rough consensus needs to
>> be pretty high (more than a relatively small number of dissenters) or
>> we will be setting ourselves up for doing even more work that somehow
>> never leads to any sort of satisfactory conclusion.
>>
>>                 On the quasi-technical issue you’re making (or
>> supporting), I think there is some confusion.  RFC 7710 is probably
>> not the RFC you meant to refer to; RFC 7710 is “*/Captive-Portal
>> Identification Using DHCP or Router Advertisements (RAs)/*” and does
>> not mention BFD at all.
>>
>>                 In any case, there are a few language issues in this
>> discussion.  There is a difference between “BFD is also expected to
>> monitor unidirectional paths” (which MAY be true) and “BFD MAY also be
>> used to monitor unidirectional paths” (which */IS/* mostly true).  And
>> I think people should take some minor exception to your wording that
>> “BFD is designed to monitor unidirectional and bidirectional paths”
>> since the “B” has a pretty much unambiguous meaning.  It is clear that
>> BFD */may be capable/* of monitoring a unidirectional path – assuming
>> that some sort of reverse path exist and may practically be used for
>> this purpose (which – in spite of the fact that this is the most
>> common case – is not necessarily true).
>>
>>                 Specifically, though I would not expect a revision
>> just to address this, I find the current wording (based on your
>> comments below) a little misleading, because now it says
>> “Bidirectional Forwarding Detection (BFD) is expected to monitor any
>> kind of paths between systems.”  This is pretty much what your comment
>> implies, but is clearly not true (from an English language
>> perspective) because any such */expectation/* clearly will not scale
>> (there are a great many systems with a great many more paths between
>> them, hence */expecting /*BFD to monitor */any kind of path between
>> systems/* */_is_ /*setting our expectations a little high).  This is
>> the difference between expecting <protocol X> to do <Y> and expecting
>> <protocol X> to be able to do <Y>.
>>
>>                 In addition to not scaling, because there are
>> scenarios in which a practical usable reverse path may not exist, this
>> statement is not actually true even if re-phrased as “BFD may be used
>> to monitor any kind of path between systems.”  As an example of a case
>> where this is clearly not true in any practical sense, it would – from
>> a practical and feasibility perspective – probably be a poor idea to
>> monitor Satellite Television reception (for the path from satellite to
>> however many Television receivers) using BFD.
>>
>> --
>> Eric
>>
>> *From:* mpls [mailto:[email-masked]] *On Behalf Of *Adrian Farrel
>> *Sent:* Thursday, August 18, 2016 6:10 AM
>> *To:* Gregory Mirsky <[email-masked]
>> <mailto:[email-masked]>>; 'Carlos Pignataro (cpignata)'
>> <[email-masked] <mailto:[email-masked]>>
>> *Cc:* 'mpls' <[email-masked]
>> <mailto:[email-masked]>>; [email-masked]
>> <mailto:[email-masked]>; [email-masked]
>> I'm sure it isn't your intention, but your email appears to read,
>> "Let's not debate the problem and direction of the solution because
>> they are not up for discussion."
>>
>> WG, and the fundamentals are surely not so different (although maybe
>> I'm wrong since the IPR disclosures are different).
>>
>> I also suspect that there are some linguistic confusions between the
>> two of you. Sometimes this can be mitigated by rephrasing and using
>> more words. As a case in point, Carlos originally objected to
>> "Bidirectional Forwarding Detection (BFD) is expected to monitor
>> bi-directional paths," noting that, "BFD also is expected to monitor
>> unidirectional paths." The two statements are not actually
>> contradictory and one could say (without damaging the value of the
>> document), "BFD is designed to monitor unidirectional and
>> bidirectional paths."
>>
>> In fact, as we discovered while working on RFC 7710, the false
>> negative may result precisely from using the reverse (co-routed or
>> not) path. So the value of controlling the return path is to help
>> diagnose whether the fault is on the outbound path or the return path,
>> and this applies equally to unidirectional paths and bidirectional paths.
>>
>> Adrian
>>
>> *Cc:* [email-masked] <mailto:[email-masked]>;
>> mpls; [email-masked] <mailto:[email-masked]>
>> I believe that new version of the draft addresses all technical
>> comments and now are discussing what each of us believes and how we
>> interpret this or that IETF document. While this is very enlightening
>> and I enjoy this discussion very much I don’t see that I can change
>> how you see the problem this proposal addresses. The MPLS WG had
>> agreed that the problem is real and the proposed solution, within the
>> scope defined, is technically sound.
>>
>> Regards,
>>         Greg
>>
>>
>>
>> *To:* Gregory Mirsky <[email-masked]
>> *Cc:* Martin Vigoureux <[email-masked]
>> <mailto:[email-masked]>>; [email-masked]
>> <mailto:[email-masked]>; [email-masked]
>>     *To:* Gregory Mirsky <[email-masked]
>>     *Cc:* Martin Vigoureux <[email-masked]
>>     <mailto:[email-masked]>>; [email-masked]
>>     <mailto:[email-masked]>; [email-masked]
>>     entirely accurate. As in RSVP-TE, source-routed paths may be
>>     loosely or strictly source-routed. Excluding option to construct
>>     strictly source-routed paths, in my opinion, would significantly
>>     limit scope of the Source Routing technology.
>>
>>     single Node SID, PE to PE, and shortest path in-between. Or the
>>     case of Parallel Link SIDs with varied weights in different links.
>>     How are you providing a return path?
>> limited set of scenarios, if any, yet those scenarios are not
>> discussed in the document, and are not defined to my knowledge in any
>> SPRING document — other than a mention in RFC 7855 of:
>>
>>     Can you please point to a definition of a co-routed path for
>>     Segment Routing from the segment routing architectural documents?
>>     case for it). On the other hand, definition of co-routedness can
>>     be found in MPLS-TP as “co-routed, meaning both directions follow
>>     the same path, i.e. traversing the same set of nodes and links”.
>>
>>
>> hop, still multiple-links between nodes are not specified and
>> therefore it is not clear how to provide the exact return path (when
>> the link taken is unknown). If the problem space is limited to the
>> case in which for each hop, both Node SID and Adj SID are included, no
>> Anycast, no Parallel Link SID, etc., then practicality seems to get in
>> the way.
>>
>>
>>
>>
>>     GIM3>> Authors believe that this is workable solution and the
>>     return path for the BFD session identified by BFD Discriminator
>>     TLV may be re-signaled without affecting state of the session.
>>
>>
>>
>>         *To:* Gregory Mirsky <[email-masked]
>>         *Cc:* Martin Vigoureux <[email-masked]
>>         <mailto:[email-masked]>>; [email-masked]
>>         <mailto:[email-masked]>; [email-masked]
>>             *From:* mpls [mailto:[email-masked]] *On Behalf
>>             Of *Carlos Pignataro (cpignata)
>>             *To:* Martin Vigoureux <[email-masked]
>>             *Cc:* mpls <[email-masked]
>>             <mailto:[email-masked]>>; [email-masked]
>>             <mailto:[email-masked]>; [email-masked]
>>             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.
>>
>>             /   Bidirectional Forwarding Detection (BFD) is expected
>>             to monitor bi-/
>>             /   directional paths./
>>
>>             (https://tools.ietf.org/html/rfc5883#section-4.3), and
>>             many other places.
>>         tracks BFD RFCs. BFD also is expected to monitor
>>         unidirectional paths.
>>
>>         monitor bi- directional paths. 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.
>>         NEW
>>
>>             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?
>>
>>
>>         channel. A different way, this is also the case for BFD
>>         multihop over plain IP (on a tunnel one way, hop-by-hop routed
>>         on the return).
>>
>>         forward path does not mean that the return path is
>>         misprogrammed but the forward path is correctly programmed.
>>         egress on a path for the reverse direction? That’s not
>>         generally a “need” in all situations.
>>
>>             GIM>> If the paths used by forward and return paths are
>>             not co-routed that may create ambiguous situation when
>>         paths — because links and nodes are not the only resources
>>         that need to be common. FIBs can be programmed well on one
>>         direction and wrongly on the reverse.
>>     Can you please point to a definition of a co-routed path for
>>     Segment Routing from the segment routing architectural documents?
>>
>>         Second, again, why “best suited”? If the BFD specs say that
>>         BFD can monitor unidirectional paths (including MPLS LSPs and
>>         unidirectional links), seems BFD is not necessarily “best
>>         suited to…"
>>         reverse path may affect defect detection or, in case of PM
>>         OAM, measured performance metric. Having test session on
>>             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
>>             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.
>>
>>
>>         If the path *is* bi-directional co-routed (by whichever
>>         method), you would not need this — the was my point, not that
>>         some cases are co-routed and others are not.
>>
>>         bi-directional co-routed paths, e.g. MPLS-TP p2p
>>         bi-directional co-routed LSP. RSVP-TE LSP may be explicitly
>>         routed but are unidirectional. And so SR tunnel.
>>
>>
>>             Next sentence:
>>
>>             /   be co-routed, thus/
>>             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.
>>
>>
>>             feasibility. A main motivation seems to be “3.1.3.
>>              Segment Routing: MPLS Data Plane Case”.
>>
>>             Node-SIDs and Adj-SIDs. Please refer
>>             to: https://tools.ietf.org/html/draft-ietf-spring-segment-routing-07#section-3.5
>>
>>             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.
>>
>>             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.
>>             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 do not think it is about Applicability. Given the existence
>>         of Adj-SIDs, the question is about technical feasibility. What
>>         do you do in the example I detailed above? Seems like there
>>         are potential cases in which it is not possible to specify the
>>         GIM2>> There are many scenarios where it is possible and
>>         useful to specify strict explicit path for SR tunnel. To use
>>         strict or loose paths – that we leave to the operator to
>>         decide. The proposal addresses real scenario, though not all
>>         possible ones.
>>
>>
>>
>>
>>     The document does not seem to include this applicability. Still,
>>     can you please point to a definition of a co-routed path for
>>     Segment Routing from the segment routing architectural documents?
>>
>>
>>             sub-TLV” to define the reverse path. This is consistent
>>             with the approach in RFC 7110.
>>
>>             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.
>>         return path for the BFD session may be re-signaled via LSP
>>         Ping with the same BFD discriminator.
>>
>>
>>             /    | X (TBD2) | Segment Routing MPLS Tunnel sub-TLV |
>>             This document |/
>>
>>             The Target FEC Stack for SR is defined
>>             at https://tools.ietf.org/html/draft-ietf-mpls-spring-lsp-ping-00,
>>             of that draft, before WG adoption, and is somehow trying
>>             to Update it. Instead of updating it from here, it should
>>             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.
>>
>>             As an aside, it’s not clear to me why WGLCing this
>>             document (twice) before moving forward
>>             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.
>>             This document has IPR with specific licensing terms. I
>>             would like to understand what parts of the document are
>>             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.
>>
>>
>>     Thanks,
>>
>>     — Carlos.
>>
>>
>>
>>
>>
>>             Thanks,
>>
>>             — Carlos.
>>
>>
>>                 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.
>>

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64