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

[Loa Andersson <[e-mail]>]

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 <[e-mail] 
> <mailto:[e-mail]>> 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 <[e-mail]
>     <mailto:[e-mail]>>
>     *Sent:* Monday, December 13, 2021 11:00 AM
>     *To:* Shraddha Hegde <[e-mail]
>     <mailto:[e-mail]>>
>     *Cc:* Loa Andersson <[e-mail] <mailto:[e-mail]>>; [e-mail]
>     <mailto:[e-mail]>;
>     [e-mail]
>     <mailto:[e-mail]>;
>     [e-mail] <mailto:[e-mail]>
>     *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 <[e-mail]
>         <mailto:[e-mail]>>
>         *Sent:* Wednesday, December 1, 2021 10:24 PM
>         *To:* Loa Andersson <[e-mail] <mailto:[e-mail]>>
>         *Cc:* [e-mail] <mailto:[e-mail]>;
>         [e-mail]
>         <mailto:[e-mail]>;
>         [e-mail] <mailto:[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____
> 
>               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://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____
> 
>               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 <[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$>____
> 

-- 
Loa Andersson                        email: [e-mail]
Senior MPLS Expert                          [e-mail]
Bronze Dragon Consulting             phone: [phone]