Re: [mpls] Initial AD review for https://datatracker.ietf.org/doc/draft-ietf-mpls-spring-inter-domain-oam/

[Shraddha Hegde <[e-mail]>]

Hi James,

Thanks for careful review and comments.
Pls find replies inline <SH>.
Version -13 addresses your comments.

Rgds
Shraddha



Juniper Business Use Only
From: James Guichard <[e-mail]>
Sent: Monday, April 22, 2024 5:28 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Initial AD review for https://datatracker.ietf.org/doc/draft-ietf-mpls-spring-inter-domain-oam/

[External Email. Be cautious of content]

Dear authors,

I have completed my initial review of draft-ietf-mpls-spring-inter-domain-oam-12 with the following comments:


General Comment:



- You use Segment Routing, SR, Segment-routing, terms throughout the document. Please choose one, perhaps expand Segment Routing (SR) on first use and then simply use SR throughout the rest of the document.

<SH> Done



20      The Routing (SR) architecture leverages source routing and tunneling

21      paradigms and can be directly applied to the use of a Multiprotocol

22      Label Switching (MPLS) data plane.  A network may consist of multiple



Jim> Insert 'Segment' before 'Routing' above. What are 'tunneling paradigms'? Suggest to remove this as in its simplest form SR simply leverages source routing. Also, it is not necessary to expand on MPLS above as it is a well-known abbreviation as per https://www.rfc-editor.org/materials/abbrev.expansion.txt<https://urldefense.com/v3/__https:/www.rfc-editor.org/materials/abbrev.expansion.txt__;!!NEt6yMaO-gk!Cpmjolb_K3Wo6XJP-sfRbwMEphAtEi04OghJ7PR0SxgGlPeguJdqcP2eb4EwHJqWVkpzNTle3rL-p2Vv6kaQ0v5z7uR4mD4$>. I would simply shorten the above sentence to "The Segment Routing (SR) architecture leverages source routing and can be directly applied to the MPLS data plane (SR-MPLS).". Then start the next sentence 'An SR-MPLS network...'.

<SH> Done



23      IGP domains or multiple Autonomous Systems(ASes) under the control of

24      the same organization.  It is useful to have the Label Switched Path

25      (LSP) ping and traceroute procedures when an SR end-to-end path spans

26      across multiple ASes or domains.  This document describes mechanisms



Jim> Perhaps replace 'spans across' with 'traverses'?

<SH> ok.



27      to facilitate LSP ping and traceroute in inter-AS/inter-domain SR-



Jim> Replace 'inter-AS/inter-domain' with 'inter-AS and inter-domain'

<SH> Done



28      MPLS networks in an efficient manner with a simple Operations,

29      Administration and Maintenance (OAM) protocol extension which uses

30      data plane forwarding alone for forwarding echo replies on transit

31      nodes.



Jim> It is unclear to me what 'uses data plane forwarding alone for forwarding echo replies on transit nodes' means. How else would you do it given the current state of the art for MPLS LSP ping and trace route? I would simply end the sentence after 'protocol extension'.

<SH> RFC7743 defines another way of solving the interdomain problem but in this mechanism return traffic reaches control plane at anchor nodes and then gets forwarded. Since the mechanism described in this document uses forwording plane only for return packet. This sentence was added to justify, this propses a different mechanism.



33    Requirements Language



35      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

36      "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and

37      "OPTIONAL" in this document are to be interpreted as described in BCP

38      14 [RFC2119] [RFC8174] when, and only when, they appear in all

39      capitals, as shown here.



Jim> Please remove the above requirements language section as it does not belong here. You have correctly inserted it as Section 1.2 after the introduction section.

<SH> Done



116   1.  Introduction



118     Many network deployments have built their networks consisting of

119     multiple ASes either for the ease of operations or as a result of

120     network mergers and acquisitions.  Segment Routing can be deployed in

121     such scenarios to provide end-to-end paths, traversing multiple

122     Autonomous systems(ASes).  These paths consist of Segment Identifiers

123     (SIDs) of different types as per [RFC8402].



Jim> I am not sure of the relevance of the last sentence above (?). Does the ability to carry different types of SIDs have any bearing on how OAM extensions are defined in this document? If not then I would remove the sentence or if it is relevant expand to explain why.

<SH> Removed last sentence



125     [RFC8660] specifies Segment Routing with an MPLS data plane.

126     [RFC9087] describes BGP peering SIDs, which will help in steering



Jim> This is not strictly true. BGP peering SIDs are defined in [RFC8402] and [RFC9087] describes BGP egress peer engineering - how BGP peering SIDs may be used and advertised using BGP-LS.

<SH> Updated



130                       +----------------+

131                       | Controller/PMS |

132                       +----------------+



134     |---AS1-----|                |------AS2------|            |----AS3---|



136                   ASBR2----ASBR3                ASBR5------ASBR7

137                   /             \               /            \

138                   /               \             /              \

139     PE1----P1---P2                 P3---P4---PE4              P5---P6--PE5

140                   \               /            \               /

141                   \             /              \             /

142                     ASBR1----ASBR4              ASBR6------ASBR8



Jim> Is the above figure as intended or is PE4 a typo? You have PE4 directly connected to ASBR5/ASBR6 - wouldn't this typically be a P router or is there some nuance to have a PE directly attached to an ASBR that you are trying to convey?

<SH> There is no special nuance related to PE4 described in the document.

I would leave it as is because real world networks are far from text book topologies.



152     For example, Figure 1 describes an inter-AS network scenario

153     consisting of ASes AS1, AS2 and AS3.  AS1, AS2 and AS2 are Segment



Jim> Typo 'AS2' change to 'AS3' above.

<SH> Done



205     The current document is focused on the inter-domain use case.

206     However, the protocol extensions described in this document may be

207     applied to indicate the return path for other use cases as well.



Jim> I would add a sentence to make it clear that these other use cases are out-of-scope for this document and therefore not further described.

<SH> Done



221     capable.  It is also applies to SR-MPLS networks where SR acts an an



Jim> Remove 'is' and replace 'an' with 'as' above.

<SH> Done



256   3.  Reply Path TLV



Jim> To be more specific, [RFC7110] defines the 'Reply Path (RP) TLV'. Please correct the reference here and elsewhere in the document.

<SH> Done



263     the reply mode is set to 5 (Reply via Specified Path), and Reply Path



Jim> Please update the above to make it clear that reply mode (5) is defined in [RFC7110] Section 4.1.

<SH> Done



290   4.  Segment Sub-TLV



292     [RFC9256] defines various types of segments.  The types of segments



Jim> I would change the above to read 'Section 4 of [RFC9256] defines various segments types. Also, it is very unclear, at least to me, why the segment types in [RFC9256] cannot be re-used e.g. how does Type A [RFC9256] differ from Type A (SID only) defined in this document? Is the intent to update [RFC9256] with these new segment types? If not, why not? You appear to define your own segment types in this document but do not indicate why [RFC9256] differs and/or cannot be updated with the segment types that you want to be used specifically for OAM.

<SH> Reuse of RFC 9256 directly was discussed within the WG. The type length field is one byte in BGP where as is it it 2 bytes in the TLVs defined for OAM. It was concluded to redefine the applicable segment type sub-TLVs for OAm purposes by keeping the TLV definition inline with other OAM sub-TLVs.





330     Length is 8.



Jim> 8 what? Octets? Please specify what portion of the Sub-TLV is covered by the length.



<SH> done.

Length is 8 octets. The length excludes the length of the the Type and Length Fields



499     A-Flag applies to Segment Type-C and Type-D.  If A-Flag appears with

500     Type-A Segment Type, it MUST be ignored.



Jim> The last sentence does not seem necessary as in a Type-A that is the RESERVED field that MUST be set to zero and MUST be ignored upon receipt. If you agree remove the sentence.

<SH> Flags field is there in Type A segment as well so if its set MUST be ignored.I feel its relevant. Not sure what I am missing.





504     SRv6 dataplane is not in the scope of this document.



Jim> Is there a separate document for SRv6? If so please provide a reference.

<SH> I am not aware on any



574     code is "Use Reply Path TLV in the echo reply for building the next

575     echo request", the Reply Path TLV from the echo Reply MUST be sent in



Jim> Please make it clear in the text that the stated Reply Path return code is defined in THIS document and not [RFC7110].

<SH> ok



580   7.  Detailed Example



582     The example topology given in Figure 1 will be used will be used in



Jim> Remove duplicate 'will be used' text above.

<SH> Done



583     the below sections to explain LSP ping and traceroute procedures.

584     The PMS/Head-end has a complete view of topology.  PE1, P1, P2, ASBR1

585     and ASBR2 are in AS1.  Similarly ASBR3, ASBR4, P3, P4 and PE4 are in

586     AS2.



588     AS1 and AS2 have Segment Routing enabled.  IGPs like OSPF/ISIS are

589     used to flood SIDs in each AS.  The ASBR1, ASBR2, ASBR3 and ASBR4

590     advertise BGP EPE-SIDs for the inter-AS links.  Topology of AS1 and

591     AS2 are advertised via BGP-Link State (BGP-LS) to the controller/PMS

592     or Head-end node.  The EPE-SIDs are also advertised via BGP-LS as

593     described in [RFC9086].  The example uses EPE-SIDs for the inter-AS

594     links but the same could be achieved using adjacency-SIDs advertised

595     for a passive IGP link.



597     The description in the document uses below notations for Segment

598     Identifiers(SIDs).



600     Node SIDs: N-PE1, N-P1, N-ASBR1 N-ABR1, N-ABR2etc.



Jim> There is no ABR2 in Figure 1 - I assume you mean ASBR2 - please correct the text.

<SH> Removed N-ABR1, N-ABR2



606     Let us consider a traffic-engineered path built from PE1 to PE4 with

607     Segment List stack as below.  N-P1, N-ASBR1, EPE-ASBR1-ASBR4, N-PE4

608     for following procedures.  This stack may be programmed by

609     controller/PMS or Head-end router PE1 may have imported the whole

610     topology information from BGP-LS and computed the inter-AS path.



Jim> Is the above paragraph needed given that the next sections repeat the example? If not please remove the paragraph.

<SH> done
Thanks!

Jim