Robert Wilton has entered the following ballot position for draft-ietf-spring-sr-replication-segment-15: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-spring-sr-replication-segment/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi, (1) p 2, sec 1. Introduction Replication segment is a new type of segment for Segment Routing(SR) [RFC8402], which allows a node (henceforth called a Replication node) to replicate packets to a set of other nodes (called Downstream nodes) in a Segment Routing Domain. Replication segments provide building blocks for Point-to-Multipoint Service delivery via SR Point-to-Multipoint (SR P2MP) policy. A Replication segment can replicate packets to directly connected nodes or to downstream nodes (without need for state on the transit routers). This document focuses on the Replication segment building block. The use of one or more stitched Replication segments constructed for SR P2MP Policy tree is specified in [I-D.ietf-pim-sr-p2mp-policy]. This document focuses on specifying replication behavior in an SR domain. The management of IP multicast groups, building IP multicast trees, and performing multicast congestion control are out of scope of this document. This isn't directly my technology area, but I found this document, at least up to section 2.2.1 to be quite heavy going. I don't have any great suggestions on how to significantly improve this, but found the examples helpful and wished that I had looked at them first. So, perhaps include a forward reference to them at the end of the introduction section. Minor level comments: (2) p 5, sec 2.1. SR-MPLS data plane SIDs MAY be added before the downstream SR-MPLS Replication SID in order to guide a packet from a non-adjacent SR node to a Replication node. A Replication node MAY replicate a packet to a non-adjacent Downstream node using SIDs it inserts in the copy preceding the downstream Replication SID. The Downstream node may be a leaf node of the Replication segment, or another Replication node, or both in case of bud node. A Replication node MAY use an Anycast SID or BGP PeerSet SID in segment list to send a replicated packet to one downstream Replication node in an Anycast set if and only if all nodes in the set have an identical Replication SID and reach the same set of receivers. For some use cases, there MAY be SIDs after the Replication SID in the segment list of a packet. These SIDs are used only by the Leaf/Bud nodes to forward a packet off the tree independent of the Replication SID. Coordination regarding the absence or presence and value of context information for Leaf/Bud nodes is outside the scope of this document. As a minor tweak to readability, I did wondering whether the above paragraph could be split into something more like a list, i.e., something like: SIDs MAY ... - A Repliaction node MAY ... - A Replication node MAY ... - For some use cases, there MAY ... Regards, Rob _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
