Hi Loa
Responses in-line
On Mon, May 27, 2024 at 5:33 AM Loa Andersson <loa@xxxxx> 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
>
>
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
