Hi Robert, Please see inline:
From: Robert Raszuk [mailto:[email protected]] Sent: Friday, December 11, 2020 5:16 PM To: Dongjie (Jimmy) <[email protected]> Cc: Peter Psenak <[email protected]>; Acee Lindem (acee) <[email protected]>; lsr <[email protected]> Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01 Hi Jie, But if node A sends SRv6 packets with node C's SRv6 SID in FA 128 as the destination address, when the packet arrives at E, it will be dropped, because node E does not have the forwarding entry for C's SRv6 SID in FA 128. * How can E be on the SRv6 SID list if it did not advertise SRv6 participation in the first place ? [Jie] In this case, there is no SID list in the packet, only node C’s SRv6 SID associated with FA 128 is carried in the destination IP field. While in node A’s (also D’s) FA computation, node E is on the lowest latency path to C. * What do you mean by "SRv6 SID in FA 128" ? Aren't SIDs global and not per FA ? [Jie] Yes the SRv6 SIDs are global. Node C will assign different SRv6 SIDs for each FA it participates in. here I mean node C’s SRv6 SID which is associated with FA 128. Btw this is good discussion but how is this related to IP Flex Algo topic/draft ? [Jie] This is about the rules of defining new applications for Flex-Algo. As I mentioned in previous mails, it is not quite clear to me why IP and SR are defined as different applications, while SR-MPLS and SRv6 are defined as one application, and IPv4 and IPv6 are defined as one application. There may be other applications in future. As Zhibo said, it is better to have a clear and consistent rule in the beginning. Last - I do share your concern on how topology computation can be data plane independent. Yes it works for IP Flex Algo when IPv4 and IPv6 are topologically congruent, but when you add running SR on subset of nodes to the mix it is no longer the case. [Jie] Agreed. Best regards, Jie Thx, R.
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
