Hi Bala'zs, Thanks for your answer. Makes sense. Good point that for non "strict' detnet uses cases, the PREOF-SID may be hidden in the SRH for most of the way. (at the expense of requiring an SRH even if uSID/NEXT may possibly have avoided it given PREOF-SID requirement for "only" 48 bits of ARG)
Thanks & cheers, --Bruno > > -----Original Message----- > From: Balázs Varga A <balazs.a.varga=40ericsson....@dmarc.ietf.org> > Sent: Thursday, July 25, 2024 12:02 PM > To: DECRAENE Bruno INNOV/NET <bruno.decra...@orange.com>; Joel Halpern > <j...@joelhalpern.com>; draft-varga-spring-preof-...@ietf.org > Cc: SPRING WG <spring@ietf.org> > Subject: [spring] Re: draft-varga-spring-preof-sid > > > Hi Bruno, > > Many thanks for your thoughts. Yes, in draft-varga-spring-preof-sid, it's a > design choice to include the Sequence Number in the IPv6 destination address. > I agree, that its impacts have to be discussed more detailed in the draft's > future updates. > > 1, ECMP hashing > There is one more very relevant aspect of the design choice, namely "The > DetNet-specific SID must be the last segment in an SR Policy!". > > In a DetNet scenario: > - In DetNet case the explicit route MUST be constructed to avoid any load > balancing. As ECMP is prohibited, the warning of RFC8986 regarding the > possible negative impact does not apply. > > Using the method in other use-cases: > - The PREOF function is used together with "explicit routes". The explicit > route is described by one or more SIDs before the PREOF-SID in the SRH. The > segment list of the explicit route can be constructed so that the PREOF-SID > become "visible" only at the final node. So, any load balancing along the > path using <FlowLabel, srcIP, dstIP> will never see the PREOF-SID in the > "dstIP". > By doing so, again, the warning of RFC8986 regarding the possible negative > impact does not apply. > > 2, Using the IPv6 destination option > The ARG part of SID provides an excellent opportunity in SRv6 to map both > parameters (Flow-ID + SeqNum) that are needed for the PREOF function. > Creating the destination option TLVs for these two parameters would result in > using more octets than what they use in the PREOF-SID. > > Again, many thanks for your comment, we will incorporate them in the next > version. > > Thanks & Cheers > Bala'zs > > > -----Original Message----- > From: bruno.decra...@orange.com <bruno.decra...@orange.com> > Sent: Wednesday, July 24, 2024 2:32 PM > To: Joel Halpern <j...@joelhalpern.com>; draft-varga-spring-preof-...@ietf.org > Cc: SPRING WG <spring@ietf.org> > Subject: RE: [spring] draft-varga-spring-preof-sid > > Joel, authors, > > [speaking as individual contributor for this whole email thread] > > > From: Joel Halpern <j...@joelhalpern.com> > > 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, bruno.decra...@orange.com 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://da/ > > > ta%2F&data=05%7C02%7Cbalazs.a.varga%40ericsson.com%7Cc8240d885c3c4bd > > > 27b1508dcabdcb1ff%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C63857 > > > 4211573163109%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2 > > > luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=ZRhEw%2BiNuL > > > 38ePz5pyADP4hCll77%2Bk11KbOkT93TtI4%3D&reserved=0 > > > tracker.ietf.org%2Fdoc%2Fhtml%2Frfc8986&data=05%7C02%7Cbruno.decraen > > > e% > > > 40orange.com%7C22f344f377d24b51eb2308dcab3b9367%7C90c7a20af34b40bfbc > > > 48 > > > b9253b6f5d20%7C0%7C0%7C638573519567842840%7CUnknown%7CTWFpbGZsb3d8ey > > > JW > > > IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7 > > > C% > > > 7C%7C&sdata=SrIyZrvvOQ4DnmRhggUH1Yzk55plIJMF6RRaXhmcu%2FI%3D&reserve > > > d= > > > 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 -- spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org
