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

[Gyan Mishra <[e-mail]>]

Hi Loa

Responses in-line
On Mon, May 27, 2024 at 5:33 AM Loa Andersson <[e-mail]> wrote:

> 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.
>

    Gyan> Yes I see as normative - good.

    Agreed, I will ask the authors & WG on updating RFC 8029.

>
> /Loa
> >
> >
>