Would it make sense to note (in an operability section or similar) that
the replication behavior does under soem circumstances result in a
packet with a partially processed segment list in an SRH and a
destination address that does not appear explicitly or by mechanical
manipulation in the SRH? (Yes, I think this still complies with the
SRv6 and general segment routing architectures. It is however something
that operators using this technique need to be aware of.)
Yours,
Joel
On 2/16/2023 12:29 AM, Rishabh Parekh wrote:
James,
Replies inline @ [RP]
On Wed, Feb 15, 2023 at 6:58 AM James Guichard
<james.n.guich...@futurewei.com> wrote:
Hi Rishabh, Authors, & WG:
Having reviewed the latest version of
https://datatracker.ietf.org/doc/draft-ietf-spring-sr-replication-segment/
<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-spring-sr-replication-segment%2F&data=05%7C01%7Cjames.n.guichard%40futurewei.com%7C60f2bcc04ef24f5ec5b908db0ee6f572%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638120157363761147%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=uCFEzdCq5sYQCRvqLbpb%2Bcd6DJK5WXyNBHLutSDLPXc%3D&reserved=0>
I would appreciate some clarification from the authors on the
specifics of packet replication and forwarding between the
replication point and downstream nodes. The draft as I read it
bases forwarding at a replication point on the combination of a
replication SID which triggers and selects the behavior and the
replication state held at that node. The replication state
indicates which downstream nodes the packet should be replicated
to and those nodes may or may not be adjacent to the replication
node. In the non-adjacent case my understanding is that the
replication state may include an additional segment-list and this
seems to be what the text in section 2.2. is saying by referencing
H.Encaps.Red to re-encapsulate the packet with a new SRH and outer
IPv6 header. If this is correct could it be made more explicit; at
a minimum I would expect to see a reference to RFC 8986 section 5.2.
[RP] Your understanding is correct. We can add a reference to RFC 8986
Section 5.2 as you suggest, but you say "... could it be made more
explicit ..". Do you mean the current text is not clear about this?
In addition to this I would like to clarify the case where
re-encapsulation is not needed i.e. when an explicit path to a
downstream node is not necessary and best path forwarding
suffices. The text says that in this case the outer IPv6 header is
re-used and the downstream replication SID is written into the
IPv6 header destination address. This address is most likely NOT
contained within the SRH which is a detachment from the normal
SRv6 forwarding case and I would like to hear the authors and WGs
opinions on this.
[RP] Yes, an encapsulation is not needed when a Downstream node is
adjacent or best path forwarding to a non-adjacent node is sufficient.
The downstream node's Replication SID (from Replication State) is
written in outer IPv6 DA and packet is forwarded based on the locator
of the downstream node. Our (i.e. authors) opinion is that is
permissible within the SRv6 architecture by new End.Replication
behavior (associated with incoming local Replication SID) defined in
the draft. Furthermore, there is already precedence in SRv6
architecture to process an incoming packet based on local state and
forward the modified packet. RFC 8986 defines End.B6.Encaps and
End.B6.Encaps.Red (and End.BM) functions that rely on local SR policy
state to modify an incoming packet.
Thanks,
-Rishabh
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
