[mpls] Re: Genart last call review of draft-ietf-mpls-sr-epe-oam-15

[Gyan Mishra <[e-mail]>]

Hi Shraddha

I reviewed rev 17 looks good.

Responses in-line


Thanks

Gyan
On Mon, May 27, 2024 at 6:00 AM Shraddha Hegde <[e-mail]> wrote:

> Hi Gyan,
>
> Thanks for review and comments.
>
> Pls see inline for replies..
> Ver -17 will address your comments
>
>
> Juniper Business Use Only
> -----Original Message-----
> From: Gyan Mishra via Datatracker <[e-mail]>
> Sent: Monday, May 27, 2024 11:21 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail];
> [e-mail]
> Subject: Genart last call review of draft-ietf-mpls-sr-epe-oam-15
>
> [External Email. Be cautious of content]
>
>
> Reviewer: Gyan Mishra
> Review result: Ready with Issues
>
> I am the assigned Gen-ART reviewer for this draft. The General Area Review
> Team (Gen-ART) reviews all IETF documents being processed by the IESG for
> the IETF Chair.  Please treat these comments just like any other last call
> comments.
>
> For more information, please see the FAQ at
>
> <
> https://urldefense.com/v3/__https://wiki.ietf.org/en/group/gen/GenArtFAQ__;!!NEt6yMaO-gk!EUv7mZjWsdK5ZAgikE_3V4ShuimGrtrvRSjuKH0jVOB28f2tvQMxvUftDxD7zPAy6CO7yaxMUkbtg-Zs$
> >.
>
> Document: draft-ietf-mpls-sr-epe-oam-??
> Reviewer: Gyan Mishra
> Review Date: 2024-05-26
> IETF LC End Date: 2024-05-17
> IESG Telechat date: Not scheduled for a telechat
>
> Summary:
> Egress Peer Engineering (EPE) is an application of Segment Routing to
> solve the problem of egress peer selection. The Segment Routing based
> BGP-EPE solution allows a centralized controller, e.g. a Software Defined
> Network (SDN) controller to program any egress peer. The EPE solution
> requires a node to program the PeerNode Segment Identifier(SID) describing
> a session between two nodes, the PeerAdj SID describing the link (one or
> more) that is used by sessions between peer nodes, and the PeerSet SID
> describing an arbitrary set of sessions or links between a local node and
> its peers. This document provides new sub-TLVs for EPE Segment Identifiers
> (SID) that would be used in the MPLS Target stack TLV (Type 1), in MPLS
> Ping and Traceroute procedures.
>
> The draft is well written and I is almost ready for publication.
>
> Major issues:
> None
>
> Minor issues:
>
> AFAIK, In the abstract this sentence appears in correct describing the
> PeerNode SID, PeerAdj SID & PeerSet SID
>
> Old
>
> The EPE solution requires a node to program the PeerNode Segment
> Identifier(SID) describing a session between two nodes, the PeerAdj SID
> describing the link (one or more) that is used by sessions between peer
> nodes, and the PeerSet SID describing an arbitrary set of sessions or links
> between a local node and its peers.
>
> New
> The EPE solution requires the SDN controller or PCE to program the
> PeerNode Segment Identifier(SID) describing the two peering nodes, the
> PeerAdj SID describing the link (one or more) that is used by sessions
> between peer nodes, and the PeerSet SID is a SID that is describing an
> attribute that is shared between the PeerNode SID & PeerAdj SID such as
> load balancing.
>
> <SH> EPE-SIDs can be locally programmed as well. Updated text as below.
>
> The EPE solution requires the node or the SDN controller to program the
> PeerNode Segment
> Identifier(SID) describing a session between two nodes, the PeerAdj SID
> describing the link (one or more) that is used by sessions between peer
> nodes, and the PeerSet SID
> describing any connected interface to any peer in the related group.
>

    Gyan> I read v17 looks good

>
>
>
> Nits/editorial comments:
> AFAIK since this solution describes OAM mechanism for EPE  which would be
> programmed by a PCE/SDN controller I think RFC 8664 SR PCE should be at
> least an informative reference.
> <SH> RFC 8664 is used to program head-end which consist of EPE-SIDs.
> The draft doesnot focus on the head-end programming aspect and hence I am
> finding it difficult
> To introduce informal reference.
>

     Gyan> Good point, agreed

>
>
>  Since SR EPE OAM extension of FEC Stack with the additional IANA TLVs for
> target substack is being developed with this specification AFAIK I think
> RFC 4379 should be added as a information reference that includes a list of
> all the target FEC stack sub tlvs. Would this draft update RFC 4379 adding
> these additional FEC stack Sub TLVs. It maybe a good idea to add some
> verbiage related to RFC 4379 and now with this draft adding the additional
> FEC Stack Sub TLVs thereby updating RFC 4379 making RFC 4379 a normative
> reference.
> <SH> RFC 8029 obsoleted the RFC 4379. RFC 8029 is in the normative
> reference list in this draft


    Gyan>I would like the authors and WG if RFC 8029 should be updated
since we are adding three new sub TLV to the target FEC stack shown in RFC
8029 section 3.2.   It appears that there are many more FEC stack Sub TLVs
that are not in RFC 8029 shown in IANA link below, so I agree that there is
no need to update RFC 8029.

>
https://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.xhtml


>
>  RFC 9086 has the EPE sids listed in the order PeerNode SID, PeerAdj SID,
> PeerSet SID. I think it maybe better to list in this order in the draft for
> readability since the node info is required first, followed by the link
> between the nodes, then the node/link attributes.
> <SH> ok
>
>
>
>