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

[Loa Andersson <[e-mail]>]

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:
> Hi, Deborah,
>
>> On Aug 19, 2016, at 3:56 PM, BRUNGARD, DEBORAH A <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
>> 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)
>
> 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 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)
>
>> And don’t forget, this solution is not “rubber stamped” until it gets
>> approved by the IESG.
>>
>> Good weekends!
>
> Have a great weekend!
>
> — Carlos.
>
>> Deborah
>>
>>
>> *From:* mpls [mailto:[e-mail]] *On Behalf Of *Eric Gray
>> *Sent:* Friday, August 19, 2016 3:02 PM
>> *To:* [e-mail] <mailto:[e-mail]>; Gregory Mirsky
>> <[e-mail] <mailto:[e-mail]>>;
>> 'Carlos Pignataro (cpignata)' <[e-mail]
>> <mailto:[e-mail]>>
>> *Cc:* 'mpls' <[e-mail]
>> <mailto:[e-mail]>>; [e-mail]
>> <mailto:[e-mail]>; [e-mail]
>> <mailto:[e-mail]>
>> *Subject:* Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-directed
>>
>> 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:[e-mail]] *On Behalf Of *Adrian Farrel
>> *Sent:* Thursday, August 18, 2016 6:10 AM
>> *To:* Gregory Mirsky <[e-mail]
>> <mailto:[e-mail]>>; 'Carlos Pignataro (cpignata)'
>> <[e-mail] <mailto:[e-mail]>>
>> *Cc:* 'mpls' <[e-mail]
>> <mailto:[e-mail]>>; [e-mail]
>> <mailto:[e-mail]>; [e-mail]
>> <mailto:[e-mail]>
>> *Subject:* Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-directed
>>
>> 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:[e-mail]] *On Behalf Of *Gregory Mirsky
>> *Sent:* 17 August 2016 23:19
>> *To:* Carlos Pignataro (cpignata)
>> *Cc:* [e-mail] <mailto:[e-mail]>;
>> mpls; [e-mail] <mailto:[e-mail]>
>> *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:[e-mail]]
>> *Sent:* Tuesday, August 16, 2016 10:02 AM
>> *To:* Gregory Mirsky <[e-mail]
>> <mailto:[e-mail]>>
>> *Cc:* Martin Vigoureux <[e-mail]
>> <mailto:[e-mail]>>; mpls <[e-mail]
>> <mailto:[e-mail]>>; [e-mail]
>> <mailto:[e-mail]>; [e-mail]
>> <mailto:[e-mail]>
>> *Subject:* Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-directed
>>
>> 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
>>     <[e-mail] <mailto:[e-mail]>>
>>     wrote:
>>
>>     Hi Carlos,
>>     thank you for clarification of your concerns. Please find my notes
>>     in-line and tagged GIM3>>.
>>
>>                     Regards,
>>                                     Greg
>>
>>     *From:* Carlos Pignataro (cpignata) [mailto:[e-mail]]
>>     *Sent:* Tuesday, August 16, 2016 6:14 AM
>>     *To:* Gregory Mirsky <[e-mail]
>>     <mailto:[e-mail]>>
>>     *Cc:* Martin Vigoureux <[e-mail]
>>     <mailto:[e-mail]>>; mpls <[e-mail]
>>     <mailto:[e-mail]>>; [e-mail]
>>     <mailto:[e-mail]>; [e-mail]
>>     <mailto:[e-mail]>
>>     *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:
>>
>>    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.
>>
>>
>>
>>
>>     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”.
>>
>>
>> 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.
>>
>>
>>
>>
>>     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.
>>
>>
>>
>>     These two seem to be major technical obstacles to the draft.
>>
>>
>>
>> Please note there were some additional comments inline, but centered
>> around the same set of topics.
>>
>> Thanks,
>>
>> — Carlos.
>>
>>
>>
>>         On Aug 10, 2016, at 3:34 PM, Gregory Mirsky
>>         <[e-mail]
>>         <mailto:[e-mail]>> 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:[e-mail]]
>>         *Sent:* Tuesday, August 09, 2016 9:14 PM
>>         *To:* Gregory Mirsky <[e-mail]
>>         <mailto:[e-mail]>>
>>         *Cc:* Martin Vigoureux <[e-mail]
>>         <mailto:[e-mail]>>; mpls <[e-mail]
>>         <mailto:[e-mail]>>; [e-mail]
>>         <mailto:[e-mail]>; [e-mail]
>>         <mailto:[e-mail]>
>>         *Subject:* Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-directed
>>
>>         Hi Greg,
>>
>>         Thanks for the response — please find some follow-ups inline.
>>
>>
>>             On Jul 25, 2016, at 5:06 PM, Gregory Mirsky
>>             <[e-mail]
>>             <mailto:[e-mail]>> wrote:
>>
>>             Hi Carlos,
>>             thank you for your comments. Please see my responses
>>             in-line and tagged GIM>>.
>>
>>                             Regards,
>>                                             Greg
>>
>>             *From:* mpls [mailto:[e-mail]] *On Behalf
>>             Of *Carlos Pignataro (cpignata)
>>             *Sent:* Saturday, July 16, 2016 8:35 AM
>>             *To:* Martin Vigoureux <[e-mail]
>>             <mailto:[e-mail]>>
>>             *Cc:* mpls <[e-mail]
>>             <mailto:[e-mail]>>; [e-mail]
>>             <mailto:[e-mail]>; [e-mail]
>>             <mailto:[e-mail]>
>>             *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:
>>
>>
>>         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.
>>
>>         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.
>>
>>
>>
>>     Since segment routing uses a loose source-routing paradigm, there
>>     may not be explicitly routed or a reverse direction.
>>
>>
>>
>>                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?
>>
>>
>>         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?
>>
>>         I still believe that the motivation and use case is not well
>>         defined or explained.
>>
>>         GIM2>> I’ll keep trying.
>>
>>
>>             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.
>>
>>
>>
>>         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”
>>
>>
>>     I think the passive voice hides precision needed.
>>
>>
>>
>>             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.
>>
>>
>>
>>         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?
>>
>>     Or are you defining that here?
>>
>>
>>
>>         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/
>>
>>             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 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.
>>
>>         GIM2>> Will remove “… thus fulfilling the implicit BFD
>>         requirement” from the document.
>>
>>
>>
>>             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?
>>
>>
>>     There seems to be a difference between strict explicit routing
>>     (RSVP-TE) and this capability.
>>
>>             *_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.
>>
>>
>>         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.
>>
>>         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.
>>
>>
>>             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.
>>
>>
>>
>>         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)
>>
>>         GIM2>> Return path may be re-signaled in such case.
>>
>>             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.
>>
>>
>>
>>         OK.
>>
>>         The issue about using labels (along with the other ones) still
>>         remain.
>>
>>
>>
>>
>>             *_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
>>                 <[e-mail]
>>                 <mailto:[e-mail]>> 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, 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
>>                 [e-mail] <mailto:[e-mail]>
>>                 https://www.ietf.org/mailman/listinfo/mpls
>>
>
>
>
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>

-- 


Loa Andersson                        email: [e-mail]
Senior MPLS Expert                          [e-mail]
Huawei Technologies (consultant)     phone: [phone]