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

Ok. Will update and post new version.

Rgds
Shraddha

Juniper Business Use Only

-----Original Message-----
From: Loa Andersson <loa@pi.nu> 
Sent: Monday, December 13, 2021 3:02 PM
To: Dhruv Dhody <dhruv.ietf@gmail.com>; Shraddha Hegde <shraddha@juniper.net>
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]

Foks,

I think Dhruv correct, but we don't need to reference the same RFC in the same paragrapn, this would work:

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

/Loa

On 2021-12-13 17:20, Dhruv Dhody wrote:
> Hi Shraddha,
>
>
> On Mon, Dec 13, 2021 at 12:07 PM Shraddha Hegde <shraddha@juniper.net 
> <mailto:shraddha@juniper.net>> 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?____
>
>     __
>
>
> 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
>
>     __
>
>     Rgds____
>
>     Shraddha____
>
>     __ __
>
>     __ __
>
>     Juniper Business Use Only____
>
>     *From:* Dhruv Dhody <dhruv.ietf@gmail.com
>     <mailto:dhruv.ietf@gmail.com>>
>     *Sent:* Monday, December 13, 2021 11:00 AM
>     *To:* Shraddha Hegde <shraddha@juniper.net
>     <mailto:shraddha@juniper.net>>
>     *Cc:* Loa Andersson <loa@pi.nu <mailto:loa@pi.nu>>; mpls@ietf.org
>     <mailto:mpls@ietf.org>;
>     draft-ninan-mpls-spring-inter-domain-oam@ietf.org
>     <mailto:draft-ninan-mpls-spring-inter-domain-oam@ietf.org>;
>     mpls-chairs@ietf.org <mailto: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 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
>         <mailto:dhruv.ietf@gmail.com>>
>         *Sent:* Wednesday, December 1, 2021 10:24 PM
>         *To:* Loa Andersson <loa@pi.nu <mailto:loa@pi.nu>>
>         *Cc:* mpls@ietf.org <mailto:mpls@ietf.org>;
>         draft-ninan-mpls-spring-inter-domain-oam@ietf.org
>         <mailto:draft-ninan-mpls-spring-inter-domain-oam@ietf.org>;
>         mpls-chairs@ietf.org <mailto: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____
>
>               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!XZQgXKOjOS8QKRvg-BzGfDWZ4sR0c6iu1bo-MGNlxCJRLKwwyeWhEcwNwoHAuwo4$
>             <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 <loa@pi.nu
>         <mailto: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 <mailto: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
>             <mailto:loa@pi.nu>
>             Senior MPLS Expert loa.pi.nu@gmail.com
>             <mailto:loa.pi.nu@gmail.com>
>             Bronze Dragon Consulting             phone: +46 739 81 21 64
>
>             _______________________________________________
>             mpls mailing list
>             mpls@ietf.org <mailto:mpls@ietf.org>
>             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$>____
>

--
Loa Andersson                        email: loa@pi.nu
Senior MPLS Expert                          loa.pi.nu@gmail.com
Bronze Dragon Consulting             phone: +46 739 81 21 64