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

From: Huub van Helvoort <[email-masked]>
Date: Mon, 24 May 2021 21:21:54 +0200

All,

I’ve been selected as one of the MPLS-RT reviewers for
draft-ninan-mpls-spring-inter-domain-oam
which is currently a candidate for MPLS WG adoption.

I have carefully read the draft. According to the Abstract the
document describes mechanisms to facilitae LSP ping and traceroute
in inter-AS/inter-domain SR networks in an efficient manner.

In the body of the document only a single/simple example is used
to describe a mechanism. I.e. two Autonomous Systems.

There is no description how to use the mechanism in a more generic
topology with multiple Autonomous Systems.

I think a description of the application in a generic topology
should be added before this draft can be adopted as WG draft.

Best regards, Huub.

-- 
================================================================
Always remember that you are unique...just like everyone else...

---

From: <[email-masked]>
Date: Tue, 25 May 2021 04:09:40 +0800 (CST)

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.

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?

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.

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: Shraddha Hegde <[email-masked]>
Date: Mon, 31 May 2021 17:01:31 +0000

Hi Huub,

Thanks for the review and comments. I'll add another example with generic topology and
Post an update.

Rgds
Shraddha

Juniper Business Use Only

-----Original Message-----
From: Huub van Helvoort <[email-masked]> 
Sent: Tuesday, May 25, 2021 12:52 AM
To: Loa Andersson <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: MPLS-RT review of draft-ninan-mpls-spring-inter-domain-oam

[External Email. Be cautious of content]

All,

I’ve been selected as one of the MPLS-RT reviewers for draft-ninan-mpls-spring-inter-domain-oam
which is currently a candidate for MPLS WG adoption.

I have carefully read the draft. According to the Abstract the document describes mechanisms to facilitae LSP ping and traceroute in inter-AS/inter-domain SR networks in an efficient manner.

In the body of the document only a single/simple example is used to describe a mechanism. I.e. two Autonomous Systems.

There is no description how to use the mechanism in a more generic topology with multiple Autonomous Systems.

I think a description of the application in a generic topology should be added before this draft can be adopted as WG draft.

Best regards, Huub.

---

From: Shraddha Hegde <[email-masked]>
Date: Mon, 31 May 2021 17:18:02 +0000

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

  1.  clarity of the document
  2.  the technical value of the problem addressed
  3.  technical feasability of the proposed solution

  1.  The document is reasonably well-written and is readable.
  2.  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<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc7743__;!!NEt6yMaO-gk!VTgakYnhqtUppuq0ACQyr49BeNNYULEBWSJV95zXx24NsknZs8Ec0rZzz4EKFQ58$>.

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

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

Regards,

Greg Mirsky

E: [email-masked]<mailto:[email-masked]>
www.zte.com.cn<https://urldefense.com/v3/__http:/www.zte.com.cn/__;!!NEt6yMaO-gk!VTgakYnhqtUppuq0ACQyr49BeNNYULEBWSJV95zXx24NsknZs8Ec0rZzz2FEIVnD$>