Hi,
As an individual contributor, please find below some proposed comments.
Thanks,
Regards,
Bruno
---
"A SR Replication segment allows a packet to be replicated from a replication
node to downstream nodes."
May be adding "Each downstream node is reached by using a unicast segment or SR
policy."
(otherwise, the building of a multicast tree seem possibly within the scope)
-----
"a Replication segment is a logical segment"
- I'm not sure what you mean by "logical".
- My understanding is that the replication is a local segment as per RFC8402.
i.e. it is instantiated on one single node. Can you make this clear in the
document?
-----
"A Downstream Node could be
represented by the node's Node SID (i.e. it does not matter how
traffic gets to the Downstream Node, whether it's directly connected
or not), or in case of a directly connected node it could be
represented by the Adjacency SID (for the interface connecting to the
directly connected Leaf Node). Alternatively, a Downstream Node
could be represented by a SID-list or a Segment Routing Policy
[I-D.ietf-spring-segment-routing-policy] that partially/fully
specifies the explicit path from the Replication Node to the
Downstream Node, or even represented by another Replication segment."
This definition uses only "could", "alternatively", "or even".
Would it be possible to phrase it to describe what _it is_ ?
On the list, Andrew proposed the following text
"downstreamIngressReplicationSid and SID Path". Which may be could be phrased
as: a unicast SR policy, (possibly) followed by a replication segment. And if
you extend the SR-Policy to include the use of a Replication segment, may be
specification of a branch could simply be 'one SR policy'.
-----
" For the root of a Multi-point service, the Replication SID
SHOULD be considered to be the equivalent of Binding SID
[I-D.ietf-spring-segment-routing-policy] of a Segment Routing Policy.
At a downstream node of the Multi-point service, the Replication SID
MAY be used to identify that portion of the Multi-point service."
>From this text, it's not clear whether the replication SID/segment is a local
>segment, or a global segment, or something new to be defined.
Why not replacing the above text with
" the Replication SID
SHOULD be considered to be the equivalent of Binding SID
[I-D.ietf-spring-segment-routing-policy] of a Segment Routing Policy."
-------
" o When the Active Segment [RFC8402] is the Replication SID. In this
case, the operation for a replicated copy is CONTINUE."
"CONTINUE" would mean that the segment is not a local segment.
So the document really needs to clarify whether the replication SID/segment is
a local segment, or a global segment, or something new to be defined.
-----
" o On the root of a Multi-point service, based on local policy-based
routing. In this case, the operation for a replicated copy is
PUSH."
Introduction states that the building of a tree (hence the root) is out of
scope of this document.
Could the section 2 "Replication Segment" of this document be focused on the
definition and specification of this local replication segment?
-----
" If a Downstream Node is an egress (aka leaf) of the Multi-point
service, i.e. no further replication is needed, then that leaf node's
Replication segment will not have any Replication State and the
operation is NEXT. Notice that the segment on the leaf node is still
referred to as a Replication segment for the purpose of
generalization.
A node can be a bud node, i.e. it is a replication node and a leaf
node of a Multi-point service at the same time
[I-D.voyer-pim-sr-p2mp-policy]. In this case, the Replication
segment's Replication State includes a branch with the Downstream
Node being itself and the operation for the replicated copy is NEXT."
same comment: Could the section 2 "Replication Segment" of this document be
focused on the definition and specification of this local replication segment?
----
"Replication segments apply equally to both SR-MPLS and SRv6 instantiations of
Segment Routing."
May be, but there are differences between both data planes and the draft does
not talk about those differences.
e.g. for SR-MPLS, labels are local to a node (including labels of global
segments). Hence it's not crystal clear to me if/how a segment/label can follow
a replication segment. Because that label would be received by N nodes, which
may understand it differently (different FEC). How is this handled? In essence,
the situation is similar to the use of anycast SID. So this seems possible to
handle it, but may be not trivial up to the point of not mentioning it. (some
options are using upstream allocated labels with context forwarding tables,
enforcing that all receivers use the same FEC for the label. cf the spring
anycast draft)
e.g. for SRv6, the use of binding SID implies the use of new (another) IPv6
encapsulation [1]. So if N consecutive replication segments are used along the
path, N IPv6 encapsulation are performed. I'm not seen a provision for
performing the N de-encapsulations. How is this handled, on which node(s)?
[1]
https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-16#section-5
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
