Joel, authors, [speaking as individual contributor for this whole email thread]
> From: Joel Halpern <[email protected]> > Sent: Tuesday, July 23, 2024 7:19 PM > > As I understand it, as a participant, regarding your point 1, detnet > prohibits ECMP within detnet domains. (If you mean some other form of load > balancing, can you be more specific.) If this matches detnet restriction, this is good for detnet. Yet it may be up to SPRING to enforce it so we need to be aware of this. Also this may reused outside of a strict detnet network so users would need to be aware of this restriction. I meant any form of load-balancing. E.g. ECMP, UCMP, layer 2 LAGs... including dynamic usage of tactical TE to avoid congestion either in a centralized or distributed algorithm. We both know that IP routing may be unaware of layer-2 lags [1], in which case IP routing will have difficulties to enforce zero load-balancing. Coming back to draft-varga-spring-preof-sid, it's a design choice to include the Sequence Number in the IPv6 destination address: - this has negatives consequences which need to be considered in the draft IMO - this is frown upon as per RFC 8986 [2] " The ARG value of a routed SID SHOULD remain constant among packets in a given flow. Varying ARG values among packets in a flow may result in different ECMP hashing and cause reordering." - given that the draft mandates IPv6 decapsulation for such SID, it's not clear to me why an IPv6 destination option is not preferred. Doing so would also reduce the size of SRH -especially when compression is used as the PREOF behavior will be hard to compress- and helps all SR EndPoint routers in the way. [1] https://datatracker.ietf.org/doc/html/draft-decraene-lsr-lag-indication [2] https://datatracker.ietf.org/doc/html/rfc8986#name-sid-format Yours, --Bruno > Yours, > > Joel > > On 7/23/2024 11:52 AM, [email protected] wrote: > > [speaking as individual contributor] > > > > Hi authors, > > > > I've quickly read your draft. In the interest of saving meeting time, > > please find below two comments. > > > > 1) You are adding the packet sequence number in the IPv6 destination > > address. As consequence, in case of load balancing, packets from the same > > flow may have their order changed by IPv6 routers. > > Is this an issue of may be you don't care since DetNet re-ordering will > > take care of this? Or may be you are mandating a single forwarding path > > through an SR-Policy? > > Would increased packet de-ordering increase the DETNET re-ordering cost > > (e.g., extra delay, jitter, high bandwidth memory...)? > > If so (*2) you may consider discussing this in the draft. > > > > 2) End.PREOF performs SRv6 decapsulation. > > So far in SRv6 there seem to be a convention from [1] to use the > > letter "D" in the name of the behavior to indicate that decapsulation > > is performed. Perhaps you could consider using this soft convention. > > (e.g., :s/ End.PREOF/ End.DPREOF ) > > > > [1] > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata > > tracker.ietf.org%2Fdoc%2Fhtml%2Frfc8986&data=05%7C02%7Cbruno.decraene% > > 40orange.com%7C22f344f377d24b51eb2308dcab3b9367%7C90c7a20af34b40bfbc48 > > b9253b6f5d20%7C0%7C0%7C638573519567842840%7CUnknown%7CTWFpbGZsb3d8eyJW > > IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C% > > 7C%7C&sdata=SrIyZrvvOQ4DnmRhggUH1Yzk55plIJMF6RRaXhmcu%2FI%3D&reserved= > > 0 > > > > Thanks, > > Regards, > > --Bruno > > > > ______________________________________________________________________ > > ______________________________________ > > 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] To unsubscribe send an email to > > [email protected] > ____________________________________________________________________________________________________________ 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] To unsubscribe send an email to [email protected]
