Subject: Re: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02

From: <[email-masked]>
Date: Mon, 1 Sep 2014 09:40:46 +0000

I strongly support this draft which brings simplification in understanding/managing reply paths.

Stephane

From: mpls [mailto:[email-masked]] On Behalf Of Ross Callon
Sent: Wednesday, August 20, 2014 17:21
To: [email-masked]
Cc: [email-masked]'
Subject: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02

This is to start a two week poll on adopting draft-akiya-mpls-lsp-ping-reply-mode-simple-02
as an MPLS working group document.

Please send your comments (support/not support) to the mpls working group
mailing list ([email-masked]<mailto:[email-masked]>).

This poll will end Thursday September 4, 2014.

Thanks, Ross

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Tarek Saad (tsaad)" <[email-masked]>
Date: Thu, 4 Sep 2014 00:00:41 +0000

I support this draft.

The proposed new LSP ping/trace reply mode is useful for the initiator to indicate the response to come back on the reverse LSP path (without additional path TLV).
The ordered list of reply modes is also useful as a flexible (per request) list of reply modes to be visited when otherwise the response may fail if the only requested reply mode becomes invalid— hence this extension decreases chance of false failures.

Minor comment in section 1:
to minimizes -> to minimize

Regards,
Tarek

From: Ross Callon <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, August 20, 2014 at 11:20 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>'" <[email-masked]<mailto:[email-masked]>>
Subject: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02

Thanks, Ross

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 4 Sep 2014 00:18:30 +0000

Dear All,
I support WG adoption of this work.
In my view it proposes useful tool for an operator to expedite meaningful monitoring and/or troubleshooting by reducing probability of possible false negative result.

                Regards,
                                Greg

Thanks, Ross

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 4 Sep 2014 09:54:24 +0000

Hi,

I've read this draft and think it provides a useful tool for better monitoring and troubleshooting in MPLS networks.

Best regards,
Jie

From: mpls [mailto:[email-masked]] On Behalf Of Ross Callon
Sent: Wednesday, August 20, 2014 11:21 PM
To: [email-masked]
Cc: [email-masked]'
Subject: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02

Thanks, Ross

---

From: John E Drake <[email-masked]>
Date: Thu, 4 Sep 2014 13:06:50 +0000

I support the adoption of the 03 version of the subject draft.  It provides useful operational flexibility.

Yours Irrespectively,

John

From: mpls [mailto:[email-masked]] On Behalf Of Ross Callon
Sent: Wednesday, August 20, 2014 8:21 AM
To: [email-masked]
Cc: [email-masked]'
Subject: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02

Thanks, Ross

---

From: <[email-masked]>
Date: Thu, 4 Sep 2014 15:08:11 +0000

Dear all,

I support this draft.
It's benefit increase as the number of reply mode increase (which is a typical trend).

Thanks,
Regards,
Bruno

From: mpls [mailto:[email-masked]] On Behalf Of Gregory Mirsky
Sent: Thursday, September 04, 2014 2:19 AM
To: Ross Callon; [email-masked]
Cc: [email-masked]'
Subject: Re: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02

Dear All,

                Regards,
                                Greg

Thanks, Ross

---

From: Ross Callon <[email-masked]>
Date: Fri, 5 Sep 2014 16:14:17 +0000

Working Group,

This poll for adoption has been closed - and we have a new working group
document.

Can the author please re-post the document (the most recent -03 version) as

     draft-ietf-mpls-lsp-ping-reply-mode-simple-00

without any other changes than file name, version and dates.

After this is posted, the authors should deal with the various comments received following normal WG processes. The authors might also want to note (for example, in deciding when to post an update) that we have requested a routing area QA team review of the document, and we are expecting a review to appear relatively shortly. However, posting the -00 version of the working group document can be done immediately and should not wait for the QA review.

Thanks, Ross
(as mpls wg co-chair)

From: mpls [mailto:[email-masked]] On Behalf Of Ross Callon
Sent: Wednesday, August 20, 2014 11:21 AM
To: [email-masked]
Cc: [email-masked]'
Subject: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02

Thanks, Ross

---

From: Lou Berger <[email-masked]>
Date: Fri, 05 Sep 2014 16:21:28 -0400

Hello,
    I've been asked to do a QA review of this draft. Overall it looks
like a solid,  well written document,  and more than reasonable -00 WG
document.

I have some technical nits/comments/questions that I think can be
addressed as part of normal WG process:

Section 3.1
- "Reverse LSP is in relation to the last FEC  specified in the Target
FEC Stack TLV."
I think I understand this statement for the egress, but what about at
transit nodes?  Perhaps just drop the sentence?

- Missing "in the range of" in the last sentence of the section.

Section 3.2
- The phrasing of 4 is a bit stricter than I think you mean with respect
to use of Reply Mode field.  One could read it as saying that a value
carried in the field can't be used even when it is in the Order TLV, as
well as precluding its use described in the subsequent requirement (5). 
Perhaps just rephrase to say that it is only used after any mode
included in the ordered TLV is excluded/invalid/unavailable.

-I think the document should be explicit about ordering relationship of
the reply modes listed in the Order TLV and to the order of paths
included in other TLVs, e.g., sub-TLVs/FECs in the Reply Path TLV.  (Yes
it should obvious, but it is a potential interop issue)

- Section 4.1.1
 o The Reply Path TLV carrying {FEC X, FEC Y}
Wouldn't it be cleaner, particularly when considering non-draft
supporting implementations, to use multiple Reply Path TLVs (one per
possible reply path)?

That's it,
Lou

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Sat, 6 Sep 2014 18:41:11 +0000

Hi Lou,

Many thanks for your time for reviewing and providing constructive and positive comments.

Please see in-line with [NOBO].

> -----Original Message-----
> From: Lou Berger [mailto:[email-masked]]
> Sent: Friday, September 05, 2014 4:21 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: QA Review draft-akiya-mpls-lsp-ping-reply-mode-simple-03
> 
> 
> Hello,
>     I've been asked to do a QA review of this draft. Overall it looks like a solid,
> well written document,  and more than reasonable -00 WG document.

[NOBO] :)

> - "Reverse LSP is in relation to the last FEC  specified in the Target FEC Stack
> TLV."
> I think I understand this statement for the egress, but what about at transit
> nodes?  Perhaps just drop the sentence?

[NOBO] The text pointed out was added as result of comments received on the list, so I believe it is worth keeping some form of this text in the document. Although this is something I've been meaning to revisit, so thanks for highlighting it! I believe the text is mostly correct, even for transit LSRs. When FOO is going over a bi-directional LSP, then the transit LSR within the bi-directional LSR:

(1) has a reverse LSP in relation to the first FEC (top label).
(2) does not have a reverse LSP in relation to the second (last) FEC (bottom label).

In this case, the transit LSR shouldn't be using the reverse LSP for (1) since that may not reach the ingress of the LSP being tested.

What is missing from this particular text is that the reverse LSP is not always in relation to the last FEC described. A label stack having special purpose label as bottom of the stack (ex: Explicit NULL) will result in the Target FEC Stack to have a Nil FEC as the last FEC. So what the text should say is that reverse LSP is in relation to the last "transport" FEC specified in the Target FEC Stack TLV.

If you are ok with this, I'd like the change the text to:

[OLD]
   Reverse LSP is in relation to the last FEC
   specified in the Target FEC Stack TLV.

[NEW]
   Reverse LSP is in relation to the last "transport"
   FEC specified in the Target FEC Stack TLV.  A FEC such as Nil FEC
   (Target FEC Stack TLV Sub-Type 16) is not considered a "transport"
   FEC.

What do you think?

> - Missing "in the range of" in the last sentence of the section.

[NOBO] Yes, thanks for catching this.

> 
> Section 3.2
> - The phrasing of 4 is a bit stricter than I think you mean with respect to use
> of Reply Mode field.  One could read it as saying that a value carried in the
> field can't be used even when it is in the Order TLV, as well as precluding its
> use described in the subsequent requirement (5).
> Perhaps just rephrase to say that it is only used after any mode included in
> the ordered TLV is excluded/invalid/unavailable.

[NOBO] Good point. Let me change (4):

[OLD]
   4.  If a responder node understands the Reply Mode Order TLV and the
       TLV is valid, then the responder MUST consider Reply Mode values
       described in the TLV and MUST NOT use the value described in the
       Reply Mode field of received MPLS echo request.

[NEW]
   4.  If a responder node understands the Reply Mode Order TLV and the
       TLV is valid, then the responder MUST consider Reply Mode values
       described in the TLV.

> 
> -I think the document should be explicit about ordering relationship of the
> reply modes listed in the Order TLV and to the order of paths included in
> other TLVs, e.g., sub-TLVs/FECs in the Reply Path TLV.  (Yes it should obvious,
> but it is a potential interop issue)

[NOBO] Reply Path TLV is the only one that lists paths for the purpose of replies. Section 4.1.1 intends to clarify this. Can you take a look and let me know if this is sufficient, or you think more texts will be helpful.

> 
> - Section 4.1.1
>  o The Reply Path TLV carrying {FEC X, FEC Y} Wouldn't it be cleaner,
> particularly when considering non-draft supporting implementations, to use
> multiple Reply Path TLVs (one per possible reply path)?

[NOBO] I believe authors of RFC7110 (which defines the Reply Path TLV) can clarify its usage, but here's the way I understand that document.

- Number of Reply Path TLVs that can appear in the MPLS Echo Request/Reply messages is not strictly enforced in the document.
- The document defines and describes scenarios where one Reply Path TLV is in the MPLS Echo Request/Reply (that can carry multiple return FECs).
- The document does not spell out what happens when there are more than one Reply Path TLVs in the MPLS Echo Request/Reply messages (i.e. which takes precedence).

Hence I assumed that author intended that MPLS Echo Request/Reply can carry only one Reply Path TLV. And hence, I descried the 4.1.1 example as one Reply Path TLV carrying {FEC X, FEC Y} instead of having multiple Reply Path TLVs. After scanning through RFC7110, I still think my understanding of the document is probably what the author intended.

I suppose the last two comments are sort of related. Do let me know your thoughts after reading my repose to you.

> Lou

Again, many thanks for thorough review!

Thanks!

-Nobo

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Sun, 7 Sep 2014 00:27:00 +0000

Hi Tarek,

Thanks for catching the error. We will correct it in the next revision.

Thanks!

-Nobo

From: mpls [mailto:[email-masked]] On Behalf Of Tarek Saad (tsaad)
Sent: Wednesday, September 03, 2014 8:01 PM
To: Ross Callon; [email-masked]
Cc: [email-masked]'
Subject: Re: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02

I support this draft.

The proposed new LSP ping/trace reply mode is useful for the initiator to indicate the response to come back on the reverse LSP path (without additional path TLV).
The ordered list of reply modes is also useful as a flexible (per request) list of reply modes to be visited when otherwise the response may fail if the only requested reply mode becomes invalid- hence this extension decreases chance of false failures.

Regards,
Tarek

Thanks, Ross

---

From: Lou Berger <[email-masked]>
Date: Mon, 08 Sep 2014 09:21:40 -0400

> Please see in-line with [NOBO].

Nobo,
	responses in-line.

> [NOBO] The text pointed out was added as result of comments received
> on the list, so I believe it is worth keeping some form of this text
> in the document. Although this is something I've been meaning to
> revisit, so thanks for highlighting it! I believe the text is mostly
> correct, even for transit LSRs. When FOO is going over a
> bi-directional LSP, then the transit LSR within the bi-directional
> LSR:
> 
> In this case, the transit LSR shouldn't be using the reverse LSP for
> (1) since that may not reach the ingress of the LSP being tested.
> 
> What is missing from this particular text is that the reverse LSP is
> not always in relation to the last FEC described. A label stack
> having special purpose label as bottom of the stack (ex: Explicit
> NULL) will result in the Target FEC Stack to have a Nil FEC as the
> last FEC. So what the text should say is that reverse LSP is in
> relation to the last "transport" FEC specified in the Target FEC
> Stack TLV.
> 

>    (Target FEC Stack TLV Sub-Type 16) is not considered a "transport"

Isn't the reverse LSP based on the received LSP? If not, a ping can be
(perhaps miss) delivered on one LSP and have a response on a different
reverse LSP.  What am I missing?

>        TLV is valid, then the responder MUST consider Reply Mode values

sure, although "consider" is a bit ambiguous.   Perhaps ... "MUST
select the first available return path as identified by the ordered list
of Reply Mode values contained in the TLV."

also change the start of 5 to be "If no valid return path can be
identified based on the TLV or if the responder..."

> [NOBO] Reply Path TLV is the only one that lists paths for the
> purpose of replies. Section 4.1.1 intends to clarify this. Can you
> take a look and let me know if this is sufficient, or you think more
> texts will be helpful.
> 

How about something along the lines of (if you can make this simpler,
please do so!):
(section 3.2) 9. When the same Reply Mode value appears more than once
in a Reply Mode Order TLV and the indicated reply mode uses information
contained in the MPLS echo request, the ordering of Reply Mode values
will correspond to the order the information appears in the MPLS echo
request.

> [NOBO] I believe authors of RFC7110 (which defines the Reply Path
> TLV) can clarify its usage, but here's the way I understand that
> document.

At this point, it's the document that matters most ;-)

> 
> - Number of Reply Path TLVs that can appear in the MPLS Echo
>   Request/Reply messages is not strictly enforced in the document.
> 
If this means that it is under defined/open to interpretation, I agree.

> - The document defines and describes scenarios where one Reply Path
> TLV is in the MPLS Echo Request/Reply (that can carry multiple return
> FECs).
> 
Yeah, but it also mentioned encoding multiple return path(s).

> - The document does not spell out what happens when there are more
> than one Reply Path TLVs in the MPLS Echo Request/Reply messages
> (i.e. which takes precedence).
> 
Fair point. That said, rfc7110 doesn't also doesn't spell out when there
are more than one fecs/paths in the Reply Path TLVs.

> Hence I assumed that author intended that MPLS Echo Request/Reply can
> carry only one Reply Path TLV. And hence, I descried the 4.1.1
> example as one Reply Path TLV carrying {FEC X, FEC Y} instead of
> having multiple Reply Path TLVs. After scanning through RFC7110, I
> still think my understanding of the document is probably what the
> author intended.
> 

Again, once it's what is actually said in the RFC(s) that matter most at
this point.

To me your last point is fairly convincing, although as said above,
there's still ambiguity. Either way, it probably means that (a) the
expected Reply Path TLV processing needs to be spelled out and (b) this
document will be an update to rfc7110.  This is something that can be
worked out by the WG as the document progresses.

> I suppose the last two comments are sort of related. Do let me know
> your thoughts after reading my repose to you.
> 

Yup.

Thanks,
Lou

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Tue, 9 Sep 2014 00:10:07 +0000

Hi Lou,

Thanks for providing follow up comments and suggested texts!

Please see in-line with [NOBO2].

> Sent: Monday, September 08, 2014 9:22 AM
> To: Nobo Akiya (nobo); draft-akiya-mpls-lsp-ping-reply-mode-
> [email-masked]
> Cc: [email-masked]
> Subject: Re: QA Review draft-akiya-mpls-lsp-ping-reply-mode-simple-03
> 
> >> - "Reverse LSP is in relation to the last FEC  specified in the
> >> Target FEC Stack TLV."
> > not always in relation to the last FEC described. A label stack having
> > special purpose label as bottom of the stack (ex: Explicit
> > relation to the last "transport" FEC specified in the Target FEC Stack
> > TLV.
> >
> 

[NOBO2] If one is testing a flat LSP (i.e. non-hierarchical), then yes the reverse LSP is in relation to the received LSP. However, we probably shouldn't exclude some hierarchical LSP cases. Say, one is testing an LSP which happens to go over another LSP, where the outer LSP is starting from a transit LSR of the inner LSP. In such case, if one is performing a traceroute with Reply Mode "reverse LSP", then what the user really mean is that the "reverse LSP" is in relation to the inner LSP.  It would be wrong for a transit LSR of the outer LSP to use its own reverse LSP to send the MPLS Echo Reply back, as that may not reach the initiating node. To accommodate this hierarchical case, I believe text above is required.

> >> - The phrasing of 4 is a bit stricter than I think you mean with
> >> respect to use of Reply Mode field.  One could read it as saying that
> >> a value carried in the field can't be used even when it is in the
> >> Order TLV, as well as precluding its use described in the subsequent
> requirement (5).
> select the first available return path as identified by the ordered list of
> Reply Mode values contained in the TLV."

[NOBO2] Nice text, I'll take it!

> 
> also change the start of 5 to be "If no valid return path can be identified
> based on the TLV or if the responder..."

[NOBO2] Good point, and thanks for providing this text as well!

> 
> >
> >>
> >> -I think the document should be explicit about ordering relationship
> >> of the reply modes listed in the Order TLV and to the order of paths
> >> included in other TLVs, e.g., sub-TLVs/FECs in the Reply Path TLV.
> >> (Yes it should obvious, but it is a potential interop issue)
> >
> > [NOBO] Reply Path TLV is the only one that lists paths for the purpose
> > of replies. Section 4.1.1 intends to clarify this. Can you take a look
> > and let me know if this is sufficient, or you think more texts will be
> > helpful.
> >
> 
> contained in the MPLS echo request, the ordering of Reply Mode values will
> correspond to the order the information appears in the MPLS echo request.

[NOBO2] Right, the suggested text does allow the multiple Reply Path TLV case w/o ambiguity (or any other future extension cases). I like it. Let me drop down the MUST to SHOULD in (7), and add your suggested as (9).

> >> particularly when considering non-draft supporting implementations,
> >> to use multiple Reply Path TLVs (one per possible reply path)?
> >
> > than one Reply Path TLVs in the MPLS Echo Request/Reply messages (i.e.
> > which takes precedence).
> >
> Fair point. That said, rfc7110 doesn't also doesn't spell out when there are
> more than one fecs/paths in the Reply Path TLVs.
> 
> > carry only one Reply Path TLV. And hence, I descried the 4.1.1 example
> > as one Reply Path TLV carrying {FEC X, FEC Y} instead of having
> > multiple Reply Path TLVs. After scanning through RFC7110, I still
> > think my understanding of the document is probably what the author
> > intended.
> >
> 
> Again, once it's what is actually said in the RFC(s) that matter most at this
> point.
> 
> To me your last point is fairly convincing, although as said above, there's still
> ambiguity. Either way, it probably means that (a) the expected Reply Path
> TLV processing needs to be spelled out and (b) this document will be an
> update to rfc7110.  This is something that can be worked out by the WG as
> the document progresses.

[NOBO2] That sounds reasonable and beneficial thing to do. Let me reach out to Mach Chen who may already be monitoring this thread (he's the primary authors of RFC7110 and co-author of draft-akiya-mpls-lsp-ping-reply-mode-simple, and get his thoughts on this).

We have couple of other topics to close off on the list. Once those are closed off, we will roll out a revision which will have your comments/texts incorporated.

Thanks again Lou!

-Nobo

---

From: Mach Chen <[email-masked]>
Date: Tue, 9 Sep 2014 07:35:57 +0000

Hi Nobo and Lou,

To chime in regarding the Reply Path TLV, please see inline...

Snipped.
 
> > particularly when considering non-draft supporting implementations, to
> > use multiple Reply Path TLVs (one per possible reply path)?
> 
> [NOBO] I believe authors of RFC7110 (which defines the Reply Path TLV) can
> clarify its usage, but here's the way I understand that document.
> 
> - Number of Reply Path TLVs that can appear in the MPLS Echo Request/Reply
> messages is not strictly enforced in the document.
> - The document defines and describes scenarios where one Reply Path TLV is in
> the MPLS Echo Request/Reply (that can carry multiple return FECs).
> - The document does not spell out what happens when there are more than one
> Reply Path TLVs in the MPLS Echo Request/Reply messages (i.e. which takes
> precedence).
> 
> Hence I assumed that author intended that MPLS Echo Request/Reply can carry
> only one Reply Path TLV. And hence, I descried the 4.1.1 example as one Reply
> Path TLV carrying {FEC X, FEC Y} instead of having multiple Reply Path TLVs. After
> scanning through RFC7110, I still think my understanding of the document is
> probably what the author intended.

Yes, your understanding is align with the original intention of RFC7110, there is an implicit assumption that there will be only one Reply TLV that can appear in the MPLS Echo Request/Reply. But the assumption was based on that there will be only one return path specified or chosen. 

For multiple return paths case, IMHO, either single Reply Path TLV with multiple sub-TLVs or multiple Reply Path TLVs is technically workable.

Best regards,
Mach

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