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

From: <[email-masked]>
Date: Wed, 2 Jun 2021 06:54:54 +0800 (CST)

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: [email-masked] 
www.zte.com.cn

Original Mail

Sender: ShraddhaHegde
To: gregory mirsky10211915;[email-masked];[email-masked];[email-masked];[email-masked];
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: [email-masked] <[email-masked]> 
 Sent: Tuesday, May 25, 2021 1:40 AM
 To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
 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: [email-masked] 
 www.zte.com.cn

---

From: <[email-masked]>
Date: Thu, 3 Jun 2021 06:18:04 +0800 (CST)

Dear Sharaddha, et al.,
my apologies for sending out my notes in an unreadable format. 

Regards,
Greg Mirsky
------------------Original Mail------------------
Sender: gregory mirsky10211915
To: ShraddhaHegde;
CC: [email-masked];[email-masked];[email-masked];[email-masked];
Date: 2021/06/01 15:54
Subject: Re:[mpls] MPLS-RT review of draft-ninan-mpls-spring-inter-domain-oam
Hi Shraddha,

Regards,
Greg Mirsky
#zreadTextPanel v\:* {behavior:url(#default#VML);}  #zreadTextPanel o\:* {behavior:url(#default#VML);}  #zreadTextPanel w\:* {behavior:url(#default#VML);}  #zreadTextPanel .shape {behavior:url(#default#VML);}Hi Greg,

---

From: Shraddha Hegde <[email-masked]>
Date: Thu, 3 Jun 2021 04:36:34 +0000

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

<Shraddha> Yes. RFC 7743 is applicable to SR networks as well. This draft is providing an alternate mechanism for SR networks which is much simpler.

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

<Shraddha> This draft also uses TTL expiry mechanism. No change there. Only additional thing is every Echo-request will consist of a return path TLV. The return path will correspond to the next node on which TTL will expire.
Probably traceroute needs better explanation on how it works. I'll update the draft and post in a couple of days.

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Thursday, June 3, 2021 3:48 AM
To: Shraddha Hegde <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re:[mpls] MPLS-RT review of draft-ninan-mpls-spring-inter-domain-oam

Dear Sharaddha, et al.,

Regards,
Greg Mirsky
------------------Original Mail------------------
Sender: gregory mirsky10211915
To: ShraddhaHegde;
CC: [email-masked];[email-masked];[email-masked];[email-masked];
Date: 2021/06/01 15:54
Subject: Re:[mpls] MPLS-RT review of draft-ninan-mpls-spring-inter-domain-oam
Hi Shraddha,

Regards,
Greg Mirsky
Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部  Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation Division
E: [email-masked]
www.zte.com.cn
Sender: ShraddhaHegde
To: gregory mirsky10211915;[email-masked];[email-masked];[email-masked];[email-masked];
Date: 2021/05/31 10:18
Subject: RE: Re:[mpls] MPLS-RT review of draft-ninan-mpls-spring-inter-domain-oam
#zreadTextPanel v\:* {behavior:url(#default#VML);}  #zreadTextPanel o\:* {behavior:url(#default#VML);}  #zreadTextPanel w\:* {behavior:url(#default#VML);}  #zreadTextPanel .shape {behavior:url(#default#VML);}Hi Greg, Thanks for the review and comments.
Pls see inline for the reply.
Juniper Business Use Only
From: [email-masked] <[email-masked]>
Sent: Tuesday, May 25, 2021 1:40 AM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
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: [email-masked]
www.zte.com.cn