Subject: Re: [mpls] working group adoption poll on draft-ninan-mpls-spring-inter-domain-oam

From: Dhruv Dhody <[email-masked]>
Date: Wed, 1 Dec 2021 22:23:30 +0530

Hi Loa, WG,

I support the adoption.

I have some comments that can be handled now or post-adoption.

   - I find the use of term domain to mean just the IGP area (see abstract
   and section 1.1) to be an issue. The title of the document says
   inter-domain BTW. My suggestion would be to keep the term "domain" as a
   generic term and have a sub-section for inter-AS and inter-area.
   - Section 3
      - This text
         - *While using the procedures described in this document, the
         reply mode MUST be set to 5 and Return Path TLV MUST be
included in the
         echo request message.*
         - This is coming from 7110, thus it is better to refer to it and
         not state it as a new text with normative MUST in this I-D. This needs
         fixing at multiple places.
         - Also, add “Reply via Specified Path” as the meaning for reply
         mode 5.
      - Section 4
      - Type 1,3,4 and the Type in the sub-TLV which when assigned by IANA
      (will be of different values) is bound to be a source of confusion.
      - I was not able to locate the registry “Sub-TLV Target FEC stack
      TLV”, should this be “Sub-TLVs for TLV Types 1, 16, and 21” instead?
      - This text for RESERVED
         - *SHOULD be unset on transmission and MUST be ignored on receipt.*
         - This is quite unusual. Why SHOULD? Why "unset"? I suggest
         changing it to “Reserved (MBZ)” with “MUST be set to zero
when sending;
         MUST be ignored on receipt.”
      - Add references for the meaning of the fields Label, TC, S, TTL.
      - This text for SR Algorithm
         - *When A-Flag is not encoded, this field SHOULD be unset on
         transmission and MUST be ignored on receipt.*
         - It could be better worded as when A-flag is unset, this field
         has no meaning and thus MUST be set to zero on transmission
and ignored on
         receipt.
      - This text for Segment Flags
         - *The Segment Types described above MAY contain following flags
         in the “Flags” field…*
         - MAY is incorrect! It is not an optional field. Do you mean to
         suggest that someone may not understand the meaning of the
flag instead?
      - Section 8
         - Avoid assigning a value (6,7) for the new reply path return
         code, leave that for IANA. This is also missing in the IANA section.
      - Suggestion: Consider moving examples to the appendix to simplify
      the core of the I-D.

<https://notes.ietf.org/#Nits>Nits

   -

   Fix Nits -
   https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ninan-mpls-spring-inter-domain-oam-04.txt
   -

   Expand on first use
   - PMS
      - LSP
      - BGP-LU
      - OAM
      - SRGB
      - LFIB
      - BGP-LS
   -

   Use updated Requirement Language as per RFC 8174
   -

   s/ip/IP/g
   -

   Suggestion: Consider using SR-MPLS instead of SR for clarity throughout
   the document!
   -

   s/mpls/MPLS/
   -

   s/Pure/pure/
   -

   s/Section Section 4.4/Section 4.4/g
   -

   s/Return path TLV/Reply Path (RP) TLV/g
   -

   s/RFC 4379/[RFC4379]/

Thanks!
Dhruv

On Tue, Nov 16, 2021 at 2:29 PM Loa Andersson <[email-masked]> wrote:

> Working Group,
>
> This is to start a two week poll on adopting
>
> draft-ninan-mpls-spring-inter-domain-oam
>
> as a MPLS working group document.
>
> Please send your comments (support/not support) to the mpls working
> group mailing list ([email-masked]). Please give a technical
> motivation for your support/not support, especially if you think that
> the document should not be adopted as a working group document.
>
> There is one IPR disclosure against this document. The data tracker says
> that there are 2 disclosure, but that depends on that the IPR holder
> updated the disclosure when the filename of the was changed.
>
> All the authors and contributors have stated on the MPLS wg mailing list
> that they are unaware of any other IPRs that relates to this document.
>
> The working group adoption poll ends November 30, 2021.
>
> /Loa
> --
> Loa Andersson                        email: [email-masked]
> Senior MPLS Expert                          [email-masked]
> Bronze Dragon Consulting             phone: +46 739 81 21 64
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: Loa Andersson <[email-masked]>
Date: Thu, 2 Dec 2021 17:13:23 +0100

Working Group,

This wgap is closed. We have a new working group document.

Can the authors please post:

draft-ietf-mpls-spring-inter-domain-oam-00

with only administrative changes (e.g. filename and version number).

/Loa

---

From: Shraddha Hegde <[email-masked]>
Date: Fri, 10 Dec 2021 09:46:39 +0000

Bruno,

Thanks for the detailed review and support.

Pls find responses below.

§4.1 "The S bit SHOULD be zero upon transmission, and MUST be ignored upon reception."

So essentially the flag has no meaning? If so, what about making it as reserved?
<SH> This is definition has been directly derived from draft-ietf-idr-segment-routing-te-policy.
I think its defined this way so as to keep the definition same as MPLS label in the packet.
Since this extension is used in control plane, it does not need to imply any meaning.
I will remove the bottom of stack meaning associated eith the flag and make it reserved.

----
§4
"   [I-D.ietf-spring-segment-routing-policy] defines various types of
   segments.  The segments applicable to this document have been re-
   defined here."

I'm not found of "re-defined". Surely this document is not meant to update SR-policy and redefine those types. Could you propose a different wording?
<SH> Agree. Modified text below. Let me know if this sounds better.
"The types of segments applicable to this document have been defined in this section  for the use of
MPLS OAM.
The motivation has been to keep the definitions same as in <xref target="I-D.ietf-spring-segment-routing-policy"/>
with minimal modifications if it is absolutely needed."
---

§4
"   Below types of segment sub-TLVs are applicable for the Reverse Path
   Segment List TLV.

   Type 1: SID only, in the form of MPLS Label

   Type 3: IPv4 Node Address with optional SID

   Type 4: IPv6 Node Address with optional SID for SR MPLS"

SR-policy renamed those to Type A, C, D. Is there a reason to change the name or could the same name be used?
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-14*section-4__;Iw!!NEt6yMaO-gk!TrHENaXz96xEeCgDM_ixH95FaX0F3YZ1mIo6gpWBt5zDOLAI2r4WGdqqC6TrhGjX$

<SH> No good reason to change. I'll update to use type A, C, D
---

§4.2 "  SID: 4 octet MPLS label."

MPLS label is not encoded using 4 octet. Please clarify how the label is encoded. (e.g. "as per Type 1 encoding" would work for me).
<SH> sure. will update
---
§4.2
"   If length is 12, then the IPv4 Node Address and the MPLS SID are present."

Please specify the behavior when the label is not consistent with the IP+SR fields. (e.g. which info is preferred)
<SH> sure. 
---
§ 13
   [I-D.ietf-spring-segment-routing-central-epe] Is now RC9087.
   <SH> will update.

---
§3 "For traceroute purposes, the headend/PMS need to acquire the
   entire database or use dynamically computed return path as described
   in Section 8"

"entire database" may be an overstatement. Maybe only the knowledge of the ABRS could be enough?
<SH> During traceroute, ever node is visited on the path and return path would have to be built from every node.
If the entire database is not known at the headend, I am not sure if the headend can figureout which ABR SID to be
used for return path.In any case this part is implementation dependent and doesn't have to be standardized.
The text was added as there were comments in the RT review that some suggestion of how the headend calculates the
return path should be explained.
Will change the text as below.

"One of the ways this can be
implemented on headend is to acquire the entire database (of all domains) and build return path
for every node along the SR path based on the knowledge of the database. 
Another mechansim is to  use dynamically
computed return path as described in <xref target="Dynamic_TLV_building"/>"

Rgds
Shraddha

Juniper Business Use Only

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Monday, November 29, 2021 6:51 PM
To: Loa Andersson <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls] working group adoption poll on draft-ninan-mpls-spring-inter-domain-oam

[External Email. Be cautious of content]

Hi Loa, WG.

Support.

Please find below some proposed comments.

§4.1 "The S bit SHOULD be zero upon transmission, and MUST be ignored upon reception."

So essentially the flag has no meaning? If so, what about making it as reserved?

----
§4
"   [I-D.ietf-spring-segment-routing-policy] defines various types of
   segments.  The segments applicable to this document have been re-
   defined here."

I'm not found of "re-defined". Surely this document is not meant to update SR-policy and redefine those types. Could you propose a different wording?

---

§4
"   Below types of segment sub-TLVs are applicable for the Reverse Path
   Segment List TLV.

   Type 1: SID only, in the form of MPLS Label

   Type 3: IPv4 Node Address with optional SID

   Type 4: IPv6 Node Address with optional SID for SR MPLS"

SR-policy renamed those to Type A, C, D. Is there a reason to change the name or could the same name be used?
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-14*section-4__;Iw!!NEt6yMaO-gk!TrHENaXz96xEeCgDM_ixH95FaX0F3YZ1mIo6gpWBt5zDOLAI2r4WGdqqC6TrhGjX$
---
§4.2 "  SID: 4 octet MPLS label."

MPLS label is not encoded using 4 octet. Please clarify how the label is encoded. (e.g. "as per Type 1 encoding" would work for me).
---
§4.2
"   If length is 12, then the IPv4 Node Address and the MPLS SID are present."

Please specify the behavior when the label is not consistent with the IP+SR fields. (e.g. which info is preferred)
---
§ 13
   [I-D.ietf-spring-segment-routing-central-epe] Is now RC9087.

---
§3 "For traceroute purposes, the headend/PMS need to acquire the
   entire database or use dynamically computed return path as described
   in Section 8"

"entire database" may be an overstatement. Maybe only the knowledge of the ABRS could be enough?

Thanks,
Regards,
--Bruno

Orange Restricted

> -----Original Message-----
> From: mpls <[email-masked]> On Behalf Of Loa Andersson
> Sent: Tuesday, November 16, 2021 9:59 AM
> To: [email-masked]
> Cc: [email-masked]; 
> [email-masked]
> Subject: [mpls] working group adoption poll on 
> draft-ninan-mpls-spring-inter- domain-oam
>
> Working Group,
>
> group mailing list ([email-masked]). Please give a technical motivation 
> for your support/not support, especially if you think that the 
> document should not be adopted as a working group document.
>
> There is one IPR disclosure against this document. The data tracker 
> says that there are 2 disclosure, but that depends on that the IPR 
> holder updated the disclosure when the filename of the was changed.
>
> All the authors and contributors have stated on the MPLS wg mailing 
> list that they are unaware of any other IPRs that relates to this document.
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mpls
> __;!!NEt6yMaO-gk!TrHENaXz96xEeCgDM_ixH95FaX0F3YZ1mIo6gpWBt5zDOLAI2r4WG
> dqqC1MGald-$

_________________________________________________________________________________________________________________________

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: <[email-masked]>
Date: Fri, 10 Dec 2021 13:28:41 +0000

Shraddha,

Thanks for the reply.
Looks all good to me.
1 follow up inline [Bruno]

Orange Restricted

> From: Shraddha Hegde <[email-masked]>
> 
> Bruno,
> 
> I'm not found of "re-defined". Surely this document is not meant to update SR-
> policy and redefine those types. Could you propose a different wording?

[Bruno] Motivation looks good.
For my understanding, could you clarify why modification would be needed?
 (a priori the ping/traceroute follows an SR-Policy hence the return path would probably also be a (different) SR-Policy hence be described with segments as per draft-ietf-spring-segment-routing-policy)

Thanks,
Regards,
--Bruno

> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-spring-
> segment-routing-policy-14*section-4__;Iw!!NEt6yMaO-
> gk!TrHENaXz96xEeCgDM_ixH95FaX0F3YZ1mIo6gpWBt5zDOLAI2r4WGdqqC6Trh
> GjX$
> 
> MPLS label is not encoded using 4 octet. Please clarify how the label is encoded.
> (e.g. "as per Type 1 encoding" would work for me).
> <SH> sure. will update
> ---
> §4.2
> The text was added as there were comments in the RT review that some
> suggestion of how the headend calculates the
> I'm not found of "re-defined". Surely this document is not meant to update SR-
> policy and redefine those types. Could you propose a different wording?
> 
> ---
> 
> §4
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-spring-
> segment-routing-policy-14*section-4__;Iw!!NEt6yMaO-
> gk!TrHENaXz96xEeCgDM_ixH95FaX0F3YZ1mIo6gpWBt5zDOLAI2r4WGdqqC6Trh
> GjX$
> ---
> MPLS label is not encoded using 4 octet. Please clarify how the label is encoded.
> (e.g. "as per Type 1 encoding" would work for me).
> ---
> §4.2
> > __;!!NEt6yMaO-
> gk!TrHENaXz96xEeCgDM_ixH95FaX0F3YZ1mIo6gpWBt5zDOLAI2r4WG
> > dqqC1MGald-$
> 
> ______________________________________________________________________
> ___________________________________________________
> 
> 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.

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: Shraddha Hegde <[email-masked]>
Date: Mon, 13 Dec 2021 04:13:42 +0000

Dhruv,

Many thanks for the support and the detailed review.
I’ll post the latest update with fixed comments.

See responses below.

Section 3
o            This text
            While using the procedures described in this document, the reply mode MUST be set to 5 and Return Path TLV MUST be included in the echo request message.

            This is coming from 7110, thus it is better to refer to it and not state it as a new text with normative MUST in this I-D. This needs fixing at multiple places.
<SH> That is correct but the Reply Path TLV is optional. This document suggests that while using procedures in this document its a MUST.
     Other MUSTs in the document appear specific to this document and not specified in RFC 7110. Let me know if I missed any.

            Also, add “Reply via Specified Path” as the meaning for reply mode 5.
<SH> sure
•            Section 4
o            Type 1,3,4 and the Type in the sub-TLV which when assigned by IANA (will be of different values) is bound to be a source of confusion.
<SH> changed to TYPE A, C , D to match with BGP draft.

o            I was not able to locate the registry “Sub-TLV Target FEC stack TLV”, should this be “Sub-TLVs for TLV Types 1, 16, and 21” instead?
<SH> yes. Thanks for pointing out.
o            This text for RESERVED
            SHOULD be unset on transmission and MUST be ignored on receipt.
            This is quite unusual. Why SHOULD? Why "unset"? I suggest changing it to “Reserved (MBZ)” with “MUST be set to zero when sending; MUST be ignored on receipt.”
<SH> yes. will update.
o
Add references for the meaning of the fields Label, TC, S, TTL.
<SH> yes. will update
o            This text for SR Algorithm
            When A-Flag is not encoded, this field SHOULD be unset on transmission and MUST be ignored on receipt.
            It could be better worded as when A-flag is unset, this field has no meaning and thus MUST be set to zero on transmission and ignored on receipt.
<SH> yes. will update
o            This text for Segment Flags
            The Segment Types described above MAY contain following flags in the “Flags” field…
            MAY is incorrect! It is not an optional field. Do you mean to suggest that someone may not understand the meaning of the flag instead?
<SH> No its not an optional field.I'll update this.
o            Section 8
            Avoid assigning a value (6,7) for the new reply path return code, leave that for IANA. This is also missing in the IANA section.
<SH> yes. will fix it.
o            Suggestion: Consider moving examples to the appendix to simplify the core of the I-D.
<SH> Its helping understand the procedures I believe. will consider moving it to appendix once the doc is ready to move to WGLC.
Nits
<SH> Thanks will fix them all.
•            Fix Nits - https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ninan-mpls-spring-inter-domain-oam-04.txt
•            Expand on first use
o            PMS
o            LSP
o            BGP-LU
o            OAM
o            SRGB
o            LFIB
o            BGP-LS
•            Use updated Requirement Language as per RFC 8174
•            s/ip/IP/g
•            Suggestion: Consider using SR-MPLS instead of SR for clarity throughout the document!
•            s/mpls/MPLS/
•            s/Pure/pure/
•            s/Section Section 4.4/Section 4.4/g
•            s/Return path TLV/Reply Path (RP) TLV/g

Rgds
Shraddha

Juniper Business Use Only
From: Dhruv Dhody <[email-masked]>
Sent: Wednesday, December 1, 2021 10:24 PM
To: Loa Andersson <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] working group adoption poll on draft-ninan-mpls-spring-inter-domain-oam

Hi Loa, WG,

I support the adoption.

  *   I find the use of term domain to mean just the IGP area (see abstract and section 1.1) to be an issue. The title of the document says inter-domain BTW. My suggestion would be to keep the term "domain" as a generic term and have a sub-section for inter-AS and inter-area.
  *   Section 3

     *   This text

        *   While using the procedures described in this document, the reply mode MUST be set to 5 and Return Path TLV MUST be included in the echo request message.
        *   This is coming from 7110, thus it is better to refer to it and not state it as a new text with normative MUST in this I-D. This needs fixing at multiple places.
        *   Also, add “Reply via Specified Path” as the meaning for reply mode 5.

  *   Section 4

     *   Type 1,3,4 and the Type in the sub-TLV which when assigned by IANA (will be of different values) is bound to be a source of confusion.
     *   I was not able to locate the registry “Sub-TLV Target FEC stack TLV”, should this be “Sub-TLVs for TLV Types 1, 16, and 21” instead?
     *   This text for RESERVED

        *   SHOULD be unset on transmission and MUST be ignored on receipt.
        *   This is quite unusual. Why SHOULD? Why "unset"? I suggest changing it to “Reserved (MBZ)” with “MUST be set to zero when sending; MUST be ignored on receipt.”

     *   Add references for the meaning of the fields Label, TC, S, TTL.
     *   This text for SR Algorithm

        *   When A-Flag is not encoded, this field SHOULD be unset on transmission and MUST be ignored on receipt.
        *   It could be better worded as when A-flag is unset, this field has no meaning and thus MUST be set to zero on transmission and ignored on receipt.

     *   This text for Segment Flags

        *   The Segment Types described above MAY contain following flags in the “Flags” field…
        *   MAY is incorrect! It is not an optional field. Do you mean to suggest that someone may not understand the meaning of the flag instead?

     *   Section 8

        *   Avoid assigning a value (6,7) for the new reply path return code, leave that for IANA. This is also missing in the IANA section.

     *   Suggestion: Consider moving examples to the appendix to simplify the core of the I-D.

Nits

  *   Fix Nits - https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ninan-mpls-spring-inter-domain-oam-04.txt<https://urldefense.com/v3/__https:/www.ietf.org/tools/idnits?url=https:**Awww.ietf.org*archive*id*draft-ninan-mpls-spring-inter-domain-oam-04.txt__;Ly8vLy8!!NEt6yMaO-gk!Rv2gb2m4mE5CZFSipcU1qBgXQqxAZMjvaaM1LBwq6R-6iX_gzTw8AN9rTYds7LWf$>
  *   Expand on first use

     *   PMS
     *   LSP
     *   BGP-LU
     *   OAM
     *   SRGB
     *   LFIB
     *   BGP-LS

  *   Use updated Requirement Language as per RFC 8174
  *   s/ip/IP/g
  *   Suggestion: Consider using SR-MPLS instead of SR for clarity throughout the document!
  *   s/mpls/MPLS/
  *   s/Pure/pure/
  *   s/Section Section 4.4/Section 4.4/g
  *   s/Return path TLV/Reply Path (RP) TLV/g
  *   s/RFC 4379/[RFC4379]/

Thanks!
Dhruv

On Tue, Nov 16, 2021 at 2:29 PM Loa Andersson <[email-masked]<mailto:[email-masked]>> wrote:
Working Group,

Please send your comments (support/not support) to the mpls working
group mailing list ([email-masked]<mailto:[email-masked]>). Please give a technical
motivation for your support/not support, especially if you think that
the document should not be adopted as a working group document.

/Loa
--
Loa Andersson                        email: [email-masked]<mailto:[email-masked]>
Senior MPLS Expert                          [email-masked]<mailto:[email-masked]>
Bronze Dragon Consulting             phone: +46 739 81 21 64

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/mpls__;!!NEt6yMaO-gk!Rv2gb2m4mE5CZFSipcU1qBgXQqxAZMjvaaM1LBwq6R-6iX_gzTw8AN9rTfpohOUd$>

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 13 Dec 2021 11:00:22 +0530

Hi Shraddha,

Thanks for considering my comments. Snipping to the only open point -

Section 3
>
> o            This text
>
>             While using the procedures described in this document, the
> reply mode MUST be set to 5 and Return Path TLV MUST be included in the
> echo request message.
>
>
>
>             This is coming from 7110, thus it is better to refer to it
> and not state it as a new text with normative MUST in this I-D. This needs
> <SH> That is correct but the Reply Path TLV is optional. This document
> suggests that while using procedures in this document its a MUST.
>
>      Other MUSTs in the document appear specific to this document and not
> specified in RFC 7110. Let me know if I missed any.
>
>
>
RFC 7110 says -

   The Reply Path (RP) TLV is an optional TLV within the LSP ping
   protocol.  However, if the Reply via Specified Path mode requested,
   as described in Section 4.1, the Reply Path (RP) TLV MUST be included
   in an echo request message, and its absence is treated as a malformed
   echo request, as described in [RFC4379].

So the TLV is already a MUST as per 7110 and not a new thing defined in
this I-D. Or am I missing something?

Thanks!
Dhruv

>
> *From:* Dhruv Dhody <[email-masked]>
> *Sent:* Wednesday, December 1, 2021 10:24 PM
> *To:* Loa Andersson <[email-masked]>
> *Cc:* [email-masked]; [email-masked];
> [email-masked]
> *Subject:* Re: [mpls] working group adoption poll on
> *[External Email. Be cautious of content]*
>
>
>
> Hi Loa, WG,
>
> I support the adoption.
>
>    - I find the use of term domain to mean just the IGP area (see
>    abstract and section 1.1) to be an issue. The title of the document says
>    - *While using the procedures described in this document, the reply
>          mode MUST be set to 5 and Return Path TLV MUST be included in the echo
>          request message.*
>          changing it to “Reserved (MBZ)” with “MUST be set to zero when sending;
>          has no meaning and thus MUST be set to zero on transmission and ignored on
>          receipt.
>
>
>    - *The Segment Types described above MAY contain following flags in
>          the “Flags” field…*
>          suggest that someone may not understand the meaning of the flag instead?
>
>
>    - Section 8
>
>
>    - Avoid assigning a value (6,7) for the new reply path return code,
>          leave that for IANA. This is also missing in the IANA section.
>
>
>    - Suggestion: Consider moving examples to the appendix to simplify the
>       core of the I-D.
>
> Nits
>
>    - Fix Nits -
>    <https://urldefense.com/v3/__https:/www.ietf.org/tools/idnits?url=https:**Awww.ietf.org*archive*id*draft-ninan-mpls-spring-inter-domain-oam-04.txt__;Ly8vLy8!!NEt6yMaO-gk!Rv2gb2m4mE5CZFSipcU1qBgXQqxAZMjvaaM1LBwq6R-6iX_gzTw8AN9rTYds7LWf$>
>    - Expand on first use
>
>
>    - PMS
>       - LSP
>       - BGP-LU
>       - OAM
>       - SRGB
>       - LFIB
>       - BGP-LS
>
>
>    - Use updated Requirement Language as per RFC 8174
>    - s/ip/IP/g
>    - Suggestion: Consider using SR-MPLS instead of SR for clarity
>    throughout the document!
>    - s/mpls/MPLS/
>    - s/Pure/pure/
>    - s/Section Section 4.4/Section 4.4/g
>    - s/Return path TLV/Reply Path (RP) TLV/g
>    - s/RFC 4379/[RFC4379]/
>
> Thanks!
> Dhruv
>
>
>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/mpls__;!!NEt6yMaO-gk!Rv2gb2m4mE5CZFSipcU1qBgXQqxAZMjvaaM1LBwq6R-6iX_gzTw8AN9rTfpohOUd$>
>
>

---

From: Shraddha Hegde <[email-masked]>
Date: Mon, 13 Dec 2021 06:36:54 +0000

Dhruv,

"While using the procedures described in this document, the Reply via Specified Path mode requested  MUST be used"

Does the above statement sound like what you would be ok with?
Or you are suggesting there shouldn't be any normative statement here?

Rgds
Shraddha

Juniper Business Use Only
From: Dhruv Dhody <[email-masked]>
Sent: Monday, December 13, 2021 11:00 AM
To: Shraddha Hegde <[email-masked]>
Cc: Loa Andersson <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] working group adoption poll on draft-ninan-mpls-spring-inter-domain-oam

Hi Shraddha,

Section 3
o            This text

RFC 7110 says -

So the TLV is already a MUST as per 7110 and not a new thing defined in this I-D. Or am I missing something?

Thanks!
Dhruv

Juniper Business Use Only
From: Dhruv Dhody <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, December 1, 2021 10:24 PM
To: Loa Andersson <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] working group adoption poll on draft-ninan-mpls-spring-inter-domain-oam

Hi Loa, WG,

I support the adoption.

     *   This text

        *   While using the procedures described in this document, the reply mode MUST be set to 5 and Return Path TLV MUST be included in the echo request message.
        *   This is coming from 7110, thus it is better to refer to it and not state it as a new text with normative MUST in this I-D. This needs fixing at multiple places.
        *   Also, add "Reply via Specified Path" as the meaning for reply mode 5.

  *   Section 4

     *   Type 1,3,4 and the Type in the sub-TLV which when assigned by IANA (will be of different values) is bound to be a source of confusion.
     *   I was not able to locate the registry "Sub-TLV Target FEC stack TLV", should this be "Sub-TLVs for TLV Types 1, 16, and 21" instead?
     *   This text for RESERVED

        *   SHOULD be unset on transmission and MUST be ignored on receipt.
        *   This is quite unusual. Why SHOULD? Why "unset"? I suggest changing it to "Reserved (MBZ)" with "MUST be set to zero when sending; MUST be ignored on receipt."

        *   The Segment Types described above MAY contain following flags in the "Flags" field...
        *   MAY is incorrect! It is not an optional field. Do you mean to suggest that someone may not understand the meaning of the flag instead?

     *   Section 8

Nits

     *   PMS
     *   LSP
     *   BGP-LU
     *   OAM
     *   SRGB
     *   LFIB
     *   BGP-LS

Thanks!
Dhruv

/Loa

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 13 Dec 2021 14:50:42 +0530

Hi Shraddha,

On Mon, Dec 13, 2021 at 12:07 PM Shraddha Hegde <[email-masked]>
wrote:

> Dhruv,
>
>
>
> “While using the procedures described in this document, the Reply via
> Specified Path mode requested  MUST be used”
>
>
>
> Or you are suggesting there shouldn’t be any normative statement here?
>
>
>

IMHO it is a good practice to avoid normative MUST when
restating procedures from existing RFCs. My recommendation would be -

OLD:
   While using the procedures described in this document, the
   reply mode MUST be set to 5 and Return Path TLV MUST be included in
   the echo request message.  The procedures decribed in [RFC7110] are
   applicable for constructing the Return Path TLV.

NEW:
   While using the procedures described in this document, the
   reply mode is set to 5 (Reply via Specified Path), and Reply Path
   TLV is included in the echo request message as described in
   [RFC7110]. The Reply Path TLV is constructed as per Section 4.2 of
   [RFC7110].

END

Thanks,
Dhruv

> *Sent:* Monday, December 13, 2021 11:00 AM
> *To:* Shraddha Hegde <[email-masked]>
> *Cc:* Loa Andersson <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]
> §            While using the procedures described in this document, the
> §            This is coming from 7110, thus it is better to refer to it

---

From: Loa Andersson <[email-masked]>
Date: Mon, 13 Dec 2021 17:32:15 +0800

Foks,

I think Dhruv correct, but we don't need to reference the same RFC in 

      RFC7110.

/Loa

On 2021-12-13 17:20, Dhruv Dhody wrote:
> Hi Shraddha,
> 
> 
> On Mon, Dec 13, 2021 at 12:07 PM Shraddha Hegde <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Dhruv,____
> 
>     __ __
> 
>     “While using the procedures described in this document, the Reply
>     via Specified Path mode requested  MUST be used”____
> 
>     __ __
> 
>     Does the above statement sound like what you would be ok with?____
> 
>     Or you are suggesting there shouldn’t be any normative statement
>     here?____
> 
>     __
> 
> 
>     __
>     Rgds____
>     Shraddha____
>     __ __
>     __ __
>     Juniper Business Use Only____
> 
>     *From:* Dhruv Dhody <[email-masked]
>     <mailto:[email-masked]>>
>     *To:* Shraddha Hegde <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc:* Loa Andersson <[email-masked] <mailto:[email-masked]>>; [email-masked]
>     <mailto:[email-masked]>;
>     [email-masked]
>     <mailto:[email-masked]>;
>     [email-masked] <mailto:[email-masked]>
>     draft-ninan-mpls-spring-inter-domain-oam____
> 
>     __ __
> 
>     *[External Email. Be cautious of content]____*
> 
>     __ __
> 
>     Hi Shraddha, ____
> 
>     __ __
> 
>     Thanks for considering my comments. Snipping to the only open point
>     - ____
> 
>     __ __
> 
>     __ __
> 
>         Section 3 ____
> 
>         o            This text ____
> 
>         §            While using the procedures described in this
>         document, the reply mode MUST be set to 5 and Return Path TLV
>         MUST be included in the echo request message.____
> 
>         ____
> 
>         §            This is coming from 7110, thus it is better to
>         refer to it and not state it as a new text with normative MUST
>         in this I-D. This needs fixing at multiple places.____
> 
>         <SH> That is correct but the Reply Path TLV is optional. This
>         document suggests that while using procedures in this document
>         its a MUST.____
> 
>               Other MUSTs in the document appear specific to this
>         document and not specified in RFC 7110. Let me know if I missed
>         any.____
> 
>         __ __
> 
>     __ __
> 
>     RFC 7110 says - ____
> 
>     __ __
> 
>         The Reply Path (RP) TLV is an optional TLV within the LSP ping____
> 
>         echo request, as described in [RFC4379]. ____
> 
>     __ __
> 
>     So the TLV is already a MUST as per 7110 and not a new thing defined
>     in this I-D. Or am I missing something? ____
> 
>     __ __
> 
>     Thanks! ____
> 
>     Dhruv____
> 
>     __ __
> 
>         Juniper Business Use Only____
> 
>         *From:* Dhruv Dhody <[email-masked]
>         <mailto:[email-masked]>>
>         *To:* Loa Andersson <[email-masked] <mailto:[email-masked]>>
>         *Cc:* [email-masked] <mailto:[email-masked]>;
>         [email-masked]
>         <mailto:[email-masked]>;
>         [email-masked] <mailto:[email-masked]>
>         draft-ninan-mpls-spring-inter-domain-oam____
> 
>         ____
> 
>         *[External Email. Be cautious of content]*____
> 
>         ____
> 
>         Hi Loa, WG, ____
> 
>         I support the adoption.____
> 
>         I have some comments that can be handled now or post-adoption.____
> 
>           * I find the use of term domain to mean just the IGP area (see
>             abstract and section 1.1) to be an issue. The title of the
>             document says inter-domain BTW. My suggestion would be to
>             keep the term "domain" as a generic term and have a
>             sub-section for inter-AS and inter-area.____
>           * Section 3____
> 
>               o This text____
> 
>                   + /While using the procedures described in this
>                     document, the reply mode MUST be set to 5 and Return
>                     Path TLV MUST be included in the echo request
>                     message./____
>                   + This is coming from 7110, thus it is better to refer
>                     to it and not state it as a new text with normative
>                     MUST in this I-D. This needs fixing at multiple
>                     places.____
>                   + Also, add “Reply via Specified Path” as the meaning
>                     for reply mode 5.____
> 
>           * Section 4____
> 
>               o Type 1,3,4 and the Type in the sub-TLV which when
>                 assigned by IANA (will be of different values) is bound
>                 to be a source of confusion.____
>               o I was not able to locate the registry “Sub-TLV Target
>                 FEC stack TLV”, should this be “Sub-TLVs for TLV Types
>                 1, 16, and 21” instead?____
>               o This text for RESERVED____
> 
>                   + /SHOULD be unset on transmission and MUST be ignored
>                     on receipt./____
>                   + This is quite unusual. Why SHOULD? Why "unset"? I
>                     suggest changing it to “Reserved (MBZ)” with “MUST
>                     be set to zero when sending; MUST be ignored on
>                     receipt.”____
> 
>               o Add references for the meaning of the fields Label, TC,
>                 S, TTL.____
>               o This text for SR Algorithm____
> 
>                   + /When A-Flag is not encoded, this field SHOULD be
>                     unset on transmission and MUST be ignored on
>                     receipt./____
>                   + It could be better worded as when A-flag is unset,
>                     this field has no meaning and thus MUST be set to
>                     zero on transmission and ignored on receipt.____
> 
>               o This text for Segment Flags____
> 
>                   + /The Segment Types described above MAY contain
>                     following flags in the “Flags” field…/____
>                   + MAY is incorrect! It is not an optional field. Do
>                     you mean to suggest that someone may not understand
>                     the meaning of the flag instead?____
> 
>               o Section 8____
> 
>                   + Avoid assigning a value (6,7) for the new reply path
>                     return code, leave that for IANA. This is also
>                     missing in the IANA section.____
> 
>               o Suggestion: Consider moving examples to the appendix to
>                 simplify the core of the I-D.____
> 
> 
>                 Nits____
> 
>           * Fix Nits -
>             <https://urldefense.com/v3/__https:/www.ietf.org/tools/idnits?url=https:**Awww.ietf.org*archive*id*draft-ninan-mpls-spring-inter-domain-oam-04.txt__;Ly8vLy8!!NEt6yMaO-gk!Rv2gb2m4mE5CZFSipcU1qBgXQqxAZMjvaaM1LBwq6R-6iX_gzTw8AN9rTYds7LWf$>____
>           * Expand on first use____
> 
>               o PMS____
>               o LSP____
>               o BGP-LU____
>               o OAM____
>               o SRGB____
>               o LFIB____
>               o BGP-LS____
> 
>           * Use updated Requirement Language as per RFC 8174____
>           * s/ip/IP/g____
>           * Suggestion: Consider using SR-MPLS instead of SR for clarity
>             throughout the document!____
>           * s/mpls/MPLS/____
>           * s/Pure/pure/____
>           * s/Section Section 4.4/Section 4.4/g____
>           * s/Return path TLV/Reply Path (RP) TLV/g____
>           * s/RFC 4379/[RFC4379]/____
> 
>         Thanks!
>         Dhruv____
> 
>         ____
> 
>         On Tue, Nov 16, 2021 at 2:29 PM Loa Andersson <[email-masked]
>         <mailto:[email-masked]>> wrote:____
> 
>             Working Group,
> 
>             group mailing list ([email-masked] <mailto:[email-masked]>).
>             Please give a technical
>             <mailto:[email-masked]>
>             <mailto:[email-masked]>
>             [email-masked] <mailto:[email-masked]>
>             <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/mpls__;!!NEt6yMaO-gk!Rv2gb2m4mE5CZFSipcU1qBgXQqxAZMjvaaM1LBwq6R-6iX_gzTw8AN9rTfpohOUd$>____
>

---

From: Shraddha Hegde <[email-masked]>
Date: Mon, 13 Dec 2021 15:20:18 +0000

Ok. Will update and post new version.

Rgds
Shraddha

-----Original Message-----
From: Loa Andersson <[email-masked]> 
Sent: Monday, December 13, 2021 3:02 PM
To: Dhruv Dhody <[email-masked]>; Shraddha Hegde <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] working group adoption poll on draft-ninan-mpls-spring-inter-domain-oam

Foks,

/Loa

On 2021-12-13 17:20, Dhruv Dhody wrote:
> IMHO it is a good practice to avoid normative MUST when restating 
> procedures from existing RFCs. My recommendation would be -
>
> OLD:
>             https://urldefense.com/v3/__https://www.ietf.org/tools/idnits?url=https:**Awww.ietf.org*archive*id*draft-ninan-mpls-spring-inter-domain-oam-04.txt__;Ly8vLy8!!NEt6yMaO-gk!XZQgXKOjOS8QKRvg-BzGfDWZ4sR0c6iu1bo-MGNlxCJRLKwwyeWhEcwNwoHAuwo4$
>             https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mpls__;!!NEt6yMaO-gk!XZQgXKOjOS8QKRvg-BzGfDWZ4sR0c6iu1bo-MGNlxCJRLKwwyeWhEcwNwnziuVwA$
>             
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/mpls
> __;!!NEt6yMaO-gk!Rv2gb2m4mE5CZFSipcU1qBgXQqxAZMjvaaM1LBwq6R-6iX_gzTw8A
> N9rTfpohOUd$>____
>