Hi,
I read the draft and I have a couple of questions/comments I would like to
share with you.
Figure 1 in the draft (copied below for convenience) shows Replication and
Elimination nodes as being different from the ingress and egress nodes R1 and
R2 at the edge of the SRv6 domain.
| |
|<--------------- SRv6 Domain ---------------->|
| |
| +-----+ |
| +-----+ R3 +-----+ |
| | +-----+ | |
+-----+ +--+--+ +--+--+ +-----+
-------+ R1 +--------+ Rep | | Elm +-------+ R2 +-------
+-----+ +--+--+ +--+--+ +-----+
| +-----+ |
+-----+ R4 +-----+
+-----+
One (probably typical) use case could be that R1 and R2 are Provider Edge (PE)
nodes running multiple instances of BGP-based services on top of the SRv6
underlay as defined in RFC 9252.
In this case service SIDs would be advertised using MP-BGP and.any intermediate
nodes would not be aware about any specific service instances and their
associated Service SIDs.
Now my questions:
Question 1: How can R1 and R2 be aware of the existence of the Replication
node?
Question 2: How can the ingress PE guarantee that the desired services pass
thru the specific replication node?
Question 3: How would the repllcaton node be aware of each of these service
instances so that theyir respective packetd could be encapsulated with a
service-specific FIDs? And how would this affect scalability of the proposed
solution?
Obviously these questions would become moot if the Replication and Elimination
nodes are also the Ingress and Egress PEs of the services.
I would also like to comment comment on Note 2 in Section 3.3 that says:
Note2: Encoding the FID and SeqNum as Arguments of the SID implies that when
the RSID is in the IPv6 DA, the DA changes on a per packet basis for the
redundancy protected flow, and it may alter the ECMP hashing. This can be
avoided for example by using additional node specific SIDs before the RSID
(e.g., End) or by excluding those bits from ECMP hashing.
I have serious doubts about the marked, because behavior of ECMP in transient
nodes cannot be controlled.
Your feedbck would be highly appreciated,.
Regards, and lots of thanks in advance,
Sasha
Disclaimer
This e-mail together with any attachments may contain information of Ribbon
Communications Inc. and its Affiliates that is confidential and/or proprietary
for the sole use of the intended recipient. Any review, disclosure, reliance or
distribution by others or forwarding without express permission is strictly
prohibited. If you are not the intended recipient, please notify the sender
immediately and then delete all copies, including any attachments.
_______________________________________________
spring mailing list -- [email protected]
To unsubscribe send an email to [email protected]
