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
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
