Re: [mpls] Rtgdir early review of draft-ietf-mpls-spring-inter-domain-oam-05

[Shraddha Hegde <[e-mail]>]

Hi Micheal,

Thank you for careful review and valuable comments.
I'll post -06 version updated for the comments.

Pls see replies below



Is RFC7743 widely implemented, or does the difficulty of slow path processing make it completely impractical?  Is this document likely to replace 7743, or if there was no 7743 deployment, why is this document more likely to deployed?
<SH> I am not aware of RFC 7743 deployments. RFC 7743 was a pre-segment routing mechanism. Segment-Routing is getting deployed in many networks and the mechanism described
In this document is based on segment-routing which has some improvements over RFC 7743.

"The TLV can either be derived by a smart application or controller which has a full topology view. " but in the multi-AS case, is there any controller which actually has a view of topologies in all ASes? 1.1's definition of domain seems rather intricate as to when it applies, and I wonder if a negative example might help solidify when this can and cannot be used.
<SH> Updated sec 1.1 to clarify the multi-AS scenario. All procedures described in this doc apply to multi-As networks belonging to single owner or to a closely co-ordinating administrations like domestic and international network of the same company.

"One of the ways this can be implemented on headend is to acquire the entire database (of all domains) and build return path for every node along the SR-MPLS path based on the knowledge of the database. "

But, if the headend knows all the connectivity, why do we need traceroute at all?
<SH> The head-end can learn the entire database via BGP-LS from other domains as well but that would just be control plane information. Traceroute is needed to make sure
          Forwarding plane paths are up and running and if there is problem, which router has problem.


I found the rules in section 6.2 to be hard to read.
<SH> made some edits to this section and the previous. Let me know if it helps.

I didn't find section 7.1 useful as an example, as it wasn't specific enough.
<SH> Rewrote sec 7.1

7.2: "When echo request reaches ASBR1, and echo reply is received, the next echo request needs to include additional label as ASBR1 is a border node."
It's unclear how the headend knows it has reached ASBR1.
<SH> Updated detail as below

When echo request reaches
the border node ASBR1, and echo reply is received from ASBR1, the next echo request needs
to include additional label as ASBR1 is a border node. The head-end node has
complete visibility of the network database learnt via BGP-LS <xref target="RFC7752"/>
and <xref target="RFC9086"/> and can derive the details of ASBR nodes.


Please split the two examples (PE1->PE4) from the PE1->PE5 example in different sections so that they be referred to easier.
<SH> done

I am not sure if the proceedure in 8.1 is really normative, or just an example of one proceedure.
I found the use of "MUST" here not useful.
I think that the intention of text like:

    The Reply Path TLV MUST consist of its own node label and an EPE-SID to
    the AS from where the traceroute message was received.

Is really, that it is saying that a Reply Path TLV that includes its own node label allows an EPE-SID to know where the traceroute was received.
I.e. it's not that any of it is "MUST", in the sense that the packet is invalid if it's not there, but rather, in order to be useful something specific needs to be done.


Perhaps some future use of these facilities will find other ways to organize the TLVs, those packets are not invalid (and need to be discarded), but rather may have other utility.
<SH> Have removed normative text from the return path building steps.

section 8.2 is begging to just be a time-sequence diagram.
<SH> Drawing sequence diagram in ASCII looks difficult. Might get more confusing than not having one.
           Any example document that has sequence diagram would be helpful.

I didn't find the Security Considerations useful.
summary: "Don't let bad packets in"
While it should say, "If bad packets get in, then this is what they can do"
<SH> If bad packets get-in , there isn't much in the scope of this document
that can help. In general,  mechanisms of DOS prevention on devices would help.
I'll add a couple of sentences on that.

Please supply an overview of the draft quality and readability.
Include any issues you've spotted, and whether you think these are major blocking issues or comments about clarity or technical accuracy. Include any questions you have on points that are unclear or seem ambiguous. Include anything else that you think will be helpful toward understanding your review.
Give as much context information as possible with your comments (e.g., section numbers, paragraph counts).

Nits:

s/facilitae/facilitate/



Juniper Business Use Only
-----Original Message-----
From: Michael Richardson via Datatracker <[e-mail]>
Sent: Thursday, June 29, 2023 4:33 AM
To: [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Rtgdir early review of draft-ietf-mpls-spring-inter-domain-oam-05

[External Email. Be cautious of content]


Reviewer: Michael Richardson
Review result: Ready

RtgDir Early review: draft-ietf-mpls-spring-inter-domain-oam-05
Hello

I have been selected to do a routing directorate “early” review of this draft.
​https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-foo-name/__;!!NEt6yMaO-gk!Az_g-9k-Y7Xz5SrlW4NCvZ5bW651szHJNlHmgtDv4WUEw4O7LujStu_Kt0TDLhn-ENaLSFzkIXKu_Glr$

The routing directorate will, on request from the working group chair, perform an “early” review of a draft before it is submitted for publication to the IESG. The early review can be performed at any time during the draft’s lifetime as a working group document. The purpose of the early review depends on the stage that the document has reached.

<case 1> As this document has recently been adopted by the working group, my focus for the review is on providing a new perspective on the work, with the intention of catching any issues early on in the document's life cycle.

For more information about the Routing Directorate, please see ​https://urldefense.com/v3/__http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir__;!!NEt6yMaO-gk!Az_g-9k-Y7Xz5SrlW4NCvZ5bW651szHJNlHmgtDv4WUEw4O7LujStu_Kt0TDLhn-ENaLSFzkIeACyRVw$

Document: draft-ietf-mpls-spring-inter-domain-oam-05
Reviewer: Michael Richardson
Review Date: 2023-06-28
Intended Status: Standards Track

Summary:

I have some minor concerns about this document that I think should be resolved before it is submitted to the IESG.
I think that most of the mechanism is probably obvious to those steeped in
SRv6 and modern MPLS.
I complain below about lots of small issues, but the document is basically ready.

Comments:

Is RFC7743 widely implemented, or does the difficulty of slow path processing make it completely impractical?  Is this document likely to replace 7743, or if there was no 7743 deployment, why is this document more likely to deployed?

"The TLV can either be derived by a smart application or controller which has a full topology view. " but in the multi-AS case, is there any controller which actually has a view of topologies in all ASes? 1.1's definition of domain seems rather intricate as to when it applies, and I wonder if a negative example might help solidify when this can and cannot be used.

"One of the ways this can be implemented on headend is to acquire the entire database (of all domains) and build return path for every node along the SR-MPLS path based on the knowledge of the database. "

But, if the headend knows all the connectivity, why do we need traceroute at all?

I found the rules in section 6.2 to be hard to read.
I didn't find section 7.1 useful as an example, as it wasn't specific enough.

7.2: "When echo request reaches ASBR1, and echo reply is received, the next echo request needs to include additional label as ASBR1 is a border node."
It's unclear how the headend knows it has reached ASBR1.

Please split the two examples (PE1->PE4) from the PE1->PE5 example in different sections so that they be referred to easier.

I am not sure if the proceedure in 8.1 is really normative, or just an example of one proceedure.  I found the use of "MUST" here not useful.
I think that the intention of text like:

    The Reply Path TLV MUST consist of its own node label and an EPE-SID to
    the AS from where the traceroute message was received.

Is really, that it is saying that a Reply Path TLV that includes its own node label allows an EPE-SID to know where the traceroute was received.
I.e. it's not that any of it is "MUST", in the sense that the packet is invalid if it's not there, but rather, in order to be useful something specific needs to be done.

Perhaps some future use of these facilities will find other ways to organize the TLVs, those packets are not invalid (and need to be discarded), but rather may have other utility.

section 8.2 is begging to just be a time-sequence diagram.

I didn't find the Security Considerations useful.
summary: "Don't let bad packets in"
While it should say, "If bad packets get in, then this is what they can do"

Please supply an overview of the draft quality and readability.
Include any issues you've spotted, and whether you think these are major blocking issues or comments about clarity or technical accuracy. Include any questions you have on points that are unclear or seem ambiguous. Include anything else that you think will be helpful toward understanding your review.
Give as much context information as possible with your comments (e.g., section numbers, paragraph counts).

Nits:

s/facilitae/facilitate/