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

[Shraddha Hegde <[e-mail]>]

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 <[e-mail]>
Sent: Wednesday, December 1, 2021 10:24 PM
To: Loa Andersson <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: [mpls] working group adoption poll on 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

     *   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 <[e-mail]<mailto:[e-mail]>> 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 ([e-mail]<mailto:[e-mail]>). 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: [e-mail]<mailto:[e-mail]>
Senior MPLS Expert                          [e-mail]<mailto:[e-mail]>
Bronze Dragon Consulting             phone: [phone]

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