Re: [mpls] MPLS-RT review of draft-ninan-mpls-spring-inter-domain-oam

[[e-mail]]

Hi Shraddha,



thank you for your answers to my review. Please find my follow-up notes in-lined below under the GIM>> tag.








Regards,


Greg Mirsky






Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation Division









E: [e-mail] 
www.zte.com.cn






Original Mail



Sender: ShraddhaHegde
To: gregory mirsky10211915;[e-mail];[e-mail];[e-mail];[e-mail];
Date: 2021/05/31 10:18
Subject: RE: Re:[mpls] MPLS-RT review of draft-ninan-mpls-spring-inter-domain-oam




Hi Greg,


 


Thanks for the review and comments.


 


Pls see inline for the reply.


 


 


Juniper Business Use Only



From: [e-mail] <[e-mail]> 
 Sent: Tuesday, May 25, 2021 1:40 AM
 To: [e-mail]; [e-mail]; [e-mail]; [e-mail]
 Subject: Re:[mpls] MPLS-RT review of draft-ninan-mpls-spring-inter-domain-oam




 


[External Email. Be cautious of content]


 

Dear Authors, WG Chairs, et al.,

I've been asked to review the draft-ninan-mpls-spring-inter-domain-oam. I've concentrated on three criteria:

clarity of the document

the technical value of the problem addressed

technical feasability of the proposed solution

Below are my notes on these three aspects:

The document is reasonably well-written and is readable.

I couldn't find a sufficient technical explanation for introducing a new mechanism for the inter-domain ping/traceroute in addition to the one described in RFC 7743.

<Shraddha> Introduction section has some text on how this draft is different from RFC 7743


“   [RFC7743] describes a Echo-relay based solution based on advertising


   a new Relay Node Address Stack TLV containing stack of Echo-relay ip


   addresses.  That mechanism requires the return ping packet to reach

   the control plane on every relay node.”

 

Basically, RFC 7743 mechanism requires that the relay nodes receive reply packet interpret it and then forward further.

This draft is proposing much simplified solution which does not require control plane involvement on intermediate nodes.

It uses segment routing forwarding plane. I can add some more text to clarify this.

GIM>> What role or actions of the control plane, in your opinion, is required in RFC 7743? I agree with you that the proposed in this draft solution is different from the one described in RFC 7743. But, as I understand it, RFC 7743 is equally applicable to the SR-MPLS case, and it appears that the problem of e2e LSP ping in a multi-domain case is already being addressed.




It seems that the proposed mechanism has several issues:

Three types of SID sub-TLVs are defined, but only use of one is mentioned in the document.

I couldn't find an explanation of the relationship between IPv4/IPv6 Node Address and SID in Type 3 and Type 4 sub-TLVs, respectively

Also, in which scenario the SID field in Type 3 and Type 4 sub-TLVs is recommended?

<Shraddha> Type 3 and type 4 is useful when the SRGB of the  remote node is not available on the headend/PMS that is constructing the return path TLV.

                      The IPv4 node address is used by the receiving node to create mpls label from it’s own SRGB.  The SID is optional. It can be added if the PMS/headend knows the

                      SID. There is no strong usecase for the optional SID field. These TLV structure are directly derived from the SR policy TLV structures in order to be consistent with the

                        Segment routing conventions of describing a path.

I’ll add a new section to describe this.

And further, traceroute mode is called out of the scope of RFC 7743. I've read the explanation of traceroute in the draft, and I don't think it is a workable solution.

<Shraddha> The draft defines two different solutions for trace route. The headend/PMS constructed is define in sec 7.2 and the dynamically constructed return path

                      Described in section 8. Which one are you saying isn’t workable? Also would be helpful if you can specify details of why you think it will not work.

GIM>> As I recall the traceroute mode described in RFC 8029 and RFC 8287, TTL expiration is used s the exception mechanism. I couldn't find in the draft the explanation of which exception mechanisms are used to trace an SR-MPLS e2e tunnel. Also, the mechanism described in Section 7.2 appears as series of LSP pings rather than tracing a path through.




I don't feel that the draft is ready for WG adoption at this point.

I much appreciate your consideration of my comments and looking forward to discussing them with the authors.

 

Regards,


Greg Mirsky


 


Sr. Standardization Expert
 预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation Division


 






 E: [e-mail] 
 www.zte.com.cn