Re: [mpls] I-D Action: draft-ninan-mpls-spring-inter-domain-oam-03.txt

[Shraddha Hegde <[e-mail]>]

Hi Greg,



Thank you for the follow-up.

Pls see inline for replies.



-----Original Message-----

From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>

Sent: Monday, June 14, 2021 5:50 AM

To: Shraddha Hegde <[e-mail]<mailto:[e-mail]>>

Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>

Subject: Re:[mpls] I-D Action: draft-ninan-mpls-spring-inter-domain-oam-03.txt



[External Email. Be cautious of content]





Hi Shraddha and Authors,

thank you for updating the draft. I've reviewed the new version and couldn't find most of my comments addressed. Could you kindly help by pointing to the specific changes in the draft that, in your opinion, address my comments @ https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/mpls/wmd0wbToaCEtDhgd2gFcX2HzG90/__;!!NEt6yMaO-gk!Rw6JdmD9WO__g0GzLwDiRtgamBQBekpwXb-QKJzwwfZB14cHNoFoYk7utpZBQaKX$<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/mpls/wmd0wbToaCEtDhgd2gFcX2HzG90/__;!!NEt6yMaO-gk!Rw6JdmD9WO__g0GzLwDiRtgamBQBekpwXb-QKJzwwfZB14cHNoFoYk7utpZBQaKX$>  ?

<Shraddha>

Comment: 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

Addressed in section: 1 Introduction

Diff:

[cid:image001.png@01D761D3.9DD86FC0]





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

Addressed in section: 8

Diff:

[cid:image002.png@01D761D3.F7823BA0]





Comment: 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?

Addressed in section: I would recommend reading  sections 6, 7 and 8 to get the complete description of how

Type 3 and type 4 can be used.

Diff:

[cid:image003.png@01D761D4.4A9615F0]



Comment: 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 work

Addressed in section: section 7.2

Diff:

[cid:image004.png@01D761D4.C8DB1140]







As I've noted, I am not sure what is referred to as "the control plane" in the draft in describing the solution defined in RFC 7743. RFC 7743 itself does not, as I understand it, require that an Echo Reply is sent to the control plane at any step.



<shraddha> RFC 7743 describes how to relay the echo-reply in section 4.4.

The relaying node receives the echo-reply packet with destination set to relay node. Then the relaying node need

To examine the "Relay Node Address stack TLV" to find the next relay node or the initiator and send either relayed- Echo-reply or a normal echo-reply based on whether there are further relay nodes to be visited.

My understanding is that this complex operation of finding the next relay node from the packet and replacing

That into the destination address of the packet would require packet to be sent to control plane and cannot be done in forwarding plane. Also relay node receives the packet with destination address set to the relay node. The normal behaviour of a router for self addressed packets is to send the packet to control plane, the draft does not talk about

Any forwarding plane behaviour change with respect to self destined packets.





If you have an implementation that does that, perhaps we can look at whether that is indeed the property of the solution or is implementation-specific.



<shraddha> I would like to understand if you have an implementation where the  relayed echo-reply processing on the relay node is done in forwarding plane. The RFC does not specify explicitly that  relay node processing is to be done in forwarding plane also does not

Provide enough details that would be needed to process the "relay node address stack TLV"  in forwarding plane.



Also, I'm still concern with the specification for traceroute mode in the draft. I have a couple of additional notes to add:

- RFC 7110, as well as RFC 7743 (I've pointed that out in my first comments), has traceroute outside the scope;

<Shraddha> This draft has addressed traceroute and provided enough details on how traceroute procedure

Works. Let me know if you have specific questions on traceroute procedure.

Do you have a concern with this draft addressing traceroute? As long as this draft provides a workable

Solution it should not matter whether previous RFCs in the area addressed traceroute or not!





- RFC 8029 (Section 4.3) recommends using the Downstream Detailed Mapping TLV. I couldn't find that TLV being mentioned in the draft. If you believe that TLV must not be used, could you list reasons for not using the Downstream Detailed Mapping TLV?

<Shraddha> Downstream Detailed Mapping TLV is very much used.

Section 6.2 specifies no changes to RFC 8029/RFC 8287 procedures.

The change is only in processing additional reply path TLV when it comes in echo-request

And also in adding this Return path TLV while sending echo-reply.



" The responder MUST follow the normal FEC

   validation procedures as described in [RFC8029] and [RFC8287] and

   this document does not suggest any change to those procedures."



If  it is not clear enough, I can update the text as below



" The responder MUST follow the normal FEC

   validation procedures and echo-reply building procedures as  described in [RFC8029] and [RFC8287] and

   this document does not suggest any change to those procedures."



Let me know if that works for you.



Regards,

Greg Mirsky

Sr. Standardization Expert

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



E: [e-mail]<mailto:[e-mail]>

www.zte.com.cn<http://www.zte.com.cn>

------------------Original Mail------------------

Sender: ShraddhaHegde

To: [e-mail];[e-mail]<mailto:[e-mail];[e-mail]> ;Mach Chen;gregory mirsky10211915;[e-mail];[e-mail];

Date: 2021/06/11 01:34

Subject: RE: [mpls] I-D Action: draft-ninan-mpls-spring-inter-domain-oam-03.txt

Hi All,



New version of draft-ninan-mpls-spring-inter-domain-oam is posted addressing comments from MPLS-RT review.

Pls take a look and let me know if you have further comments.



Rgds

Shraddha





Juniper Business Use Only



-----Original Message-----

From: mpls  On Behalf Of [e-mail]<mailto:[e-mail]>

Sent: Friday, June 11, 2021 2:00 PM

To: [e-mail]<mailto:[e-mail]>

Cc: [e-mail]<mailto:[e-mail]>

Subject: [mpls] I-D Action: draft-ninan-mpls-spring-inter-domain-oam-03.txt



[External Email. Be cautious of content]





A New Internet-Draft is available from the on-line Internet-Drafts directories.

This draft is a work item of the Multiprotocol Label Switching WG of the IETF.



Title           : PMS/Head-end based MPLS Ping and Traceroute in Inter-domain SR Networks

Authors         : Shraddha Hegde

Kapil Arora

Mukul Srivastava

Samson Ninan

Nagendra Kumar

Filename        : draft-ninan-mpls-spring-inter-domain-oam-03.txt

Pages           : 21

Date            : 2021-06-11



Abstract:

Segment Routing (SR) architecture leverages source routing and tunneling paradigms and can be directly applied to the use of a Multiprotocol Label Switching (MPLS) data plane.  A network may consist of multiple IGP domains or multiple ASes under the control of same organization.  It is useful to have the LSP Ping and traceroute procedures when an SR end-to-end path spans across multiple ASes or domains.  This document describes mechanisms to facilitae LSP ping and traceroute in inter-AS/inter-domain SR networks in an efficient manner with simple OAM protocol extension which uses dataplane forwarding alone for sending echo reply.







The IETF datatracker status page for this draft is:

https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ninan-mpls-spring-inter-domain-oam/__;!!NEt6yMaO-gk!WjDBRkDAvnDKCC6tb3iz7_nNl8kTHr2mV0bTh80i0AzKeABzFQV3dfGS5TuJNnI5%7B0%7Dlt;br<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ninan-mpls-spring-inter-domain-oam/__;!!NEt6yMaO-gk!WjDBRkDAvnDKCC6tb3iz7_nNl8kTHr2mV0bTh80i0AzKeABzFQV3dfGS5TuJNnI5%7B0%7Dlt;br>>

There is also an htmlized version available at:

https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ninan-mpls-spring-inter-domain-oam-03__;!!NEt6yMaO-gk!WjDBRkDAvnDKCC6tb3iz7_nNl8kTHr2mV0bTh80i0AzKeABzFQV3dfGS5VMFXpJm%7B0%7Dlt;br<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ninan-mpls-spring-inter-domain-oam-03__;!!NEt6yMaO-gk!WjDBRkDAvnDKCC6tb3iz7_nNl8kTHr2mV0bTh80i0AzKeABzFQV3dfGS5VMFXpJm%7B0%7Dlt;br>>

A diff from the previous version is available at:

https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-ninan-mpls-spring-inter-domain-oam-03__;!!NEt6yMaO-gk!WjDBRkDAvnDKCC6tb3iz7_nNl8kTHr2mV0bTh80i0AzKeABzFQV3dfGS5QEnIeV0%7B0%7Dlt;br<https://urldefense.com/v3/__https:/www.ietf.org/rfcdiff?url2=draft-ninan-mpls-spring-inter-domain-oam-03__;!!NEt6yMaO-gk!WjDBRkDAvnDKCC6tb3iz7_nNl8kTHr2mV0bTh80i0AzKeABzFQV3dfGS5QEnIeV0%7B0%7Dlt;br>>



Internet-Drafts are also available by anonymous FTP at:

https://urldefense.com/v3/__ftp://ftp.ietf.org/internet-drafts/__;!!NEt6yMaO-gk!WjDBRkDAvnDKCC6tb3iz7_nNl8kTHr2mV0bTh80i0AzKeABzFQV3dfGS5T0hqLuk%7B0%7Dlt;br<https://urldefense.com/v3/__ftp:/ftp.ietf.org/internet-drafts/__;!!NEt6yMaO-gk!WjDBRkDAvnDKCC6tb3iz7_nNl8kTHr2mV0bTh80i0AzKeABzFQV3dfGS5T0hqLuk%7B0%7Dlt;br>>



_______________________________________________

mpls mailing list

[e-mail]<mailto:[e-mail]>

https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mpls__;!!NEt6yMaO-gk!WjDBRkDAvnDKCC6tb3iz7_nNl8kTHr2mV0bTh80i0AzKeABzFQV3dfGS5TdmWWCx%7B0%7Dlt;br<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/mpls__;!!NEt6yMaO-gk!WjDBRkDAvnDKCC6tb3iz7_nNl8kTHr2mV0bTh80i0AzKeABzFQV3dfGS5TdmWWCx%7B0%7Dlt;br>>


Juniper Business Use Only