Hi Loa Responses in-line On Mon, May 27, 2024 at 5:33 AM Loa Andersson <l...@pi.nu> 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 > > > > >
_______________________________________________ Gen-art mailing list -- gen-art@ietf.org To unsubscribe send an email to gen-art-le...@ietf.org
