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

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

Juniper Business Use Only
>
> *From:* Dhruv Dhody <dhruv.ietf@gmail.com>
> *Sent:* Wednesday, December 1, 2021 10:24 PM
> *To:* Loa Andersson <loa@pi.nu>
> *Cc:* mpls@ietf.org; draft-ninan-mpls-spring-inter-domain-oam@ietf.org;
> mpls-chairs@ietf.org
> *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 <loa@pi.nu> 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 (mpls@ietf.org) 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: loa@pi.nu
> Senior MPLS Expert                          loa.pi.nu@gmail.com
> Bronze Dragon Consulting             phone: +46 739 81 21 64
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/mpls__;!!NEt6yMaO-gk!Rv2gb2m4mE5CZFSipcU1qBgXQqxAZMjvaaM1LBwq6R-6iX_gzTw8AN9rTfpohOUd$>
>
>