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

[Loa Andersson <[e-mail]>]

Gyan, authors,

Two comments inline.

Den 2024-05-27 kl. 07:51, skrev Gyan Mishra via Datatracker:
> 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://wiki.ietf.org/en/group/gen/GenArtFAQ>.
> 
> 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.


A thought on the abstract is that to me it looks like it is too 
"deep-diving", the intention that it should be possible to understand by 
someone that has good technical understanding, but is not an expert in 
the subject-area. Can we assume that "PeerNode", "PeerAdj", "PeerSet" 
will be generally understood?


> 
> 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.  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. 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.
> 
No we are not going to update RFC 4379, RFC 4379 was obsoleted by RFC 
8029 a bit more than 7 years ago.

RFC 8029 is there are as normative reference, I'm not sure an update of 
RFC 8029 is needed, should be discussed with the authors and the MPLS WG.

/Loa
> 
>