Hi Loa, Is there any known implementations you can show here which builds its IPv6 load balancing hash bases on the *variable length* IPv6 extension headers content ? Or is your concern simply a speculation ? :)
As Zafar already indicated bunch of IETF work went into proposing to use flow label which is part of base IPv6 header (fixed 40 bytes) - to name a few RFC6437, RFC6438, RFC6294 etc ... for that very purpose. So at min if someone indeed wants to expose himself and construct a hash based on the variable length fields a knob should be provided to allow to configure such network element to skip extension headers. Regards, Robert. On Sat, Jun 2, 2018 at 10:21 AM, Loa Andersson <[email protected]> wrote: > Zafar, > > My concern is that any load balancing tool might hash on the field where > you have the O-bit, if it does OAM traffic and normal payload traffic > will take different paths through the network. > > How do you guarantee this this will not happen? > > /Loa > > On 2018-05-29 19:11, Zafar Ali (zali) wrote: > >> Hi Loa, >> >> Thanks for your question. >> >> O-bit "move" from SRH draft to this SRv6 OAM draft is part of a comment >> received an agreement made during the LC of the SRH draft. Please review >> the mail chain https://www.ietf.org/mail-arch >> ive/web/ipv6/current/msg30131.html. There was never a suggestion or >> agreement to "remove" O-bit or SRH.Flags field. >> >> Load balancing and ECMP in an SRv6 network are explained in >> https://tools.ietf.org/html/draft-ietf-6man-segment-routing- >> header-13#section-4.4. An implementation is expected to use the minimum >> of (source, dest) address and flow label in the outer IPv6 header to >> compute the hash. RFC6437 describes the use of flow labels to compute a >> hash for IPv6 packets. >> >> Thanks >> >> Regards … Zafar >> >> *From: *Loa Andersson <[email protected]> >> *Date: *Tuesday, May 29, 2018 at 9:48 AM >> *To: *Huzhibo <[email protected]>, "Zafar Ali (zali)" <[email protected]>, >> "[email protected]" <[email protected]>, >> "[email protected]" <[email protected]> >> *Cc: *Lizhenbin <[email protected]>, Yangang <[email protected]> >> *Subject: *Re: [spring] About draft-ali-spring-srv6-oam-00 >> >> Folks, >> >> I thought we had an agreement to remove the O-bit. As ZhiBo Hu points >> >> out other drafts drops it. >> >> The obvious reason to not use an O-bit is that if it ever is part of >> >> what an multipath functions hash on it will csue OAM traffic and >> >> "normal" traffic to use different paths. This defeats the idea with >> >> OAM traffic. >> >> /Loa >> >> On 2018-05-16 06:56, Huzhibo wrote: >> >> Hi, >> >> draft-ali-spring-srv6-oam-00 says The OAM packets are identified by >> >> setting the O-bit in SRH，But I Notice the latest >> >> I-D.6man-segment-routing-headerhas removed O-bit in the SRH extension >> >> header. I want to confirm that draft-ali-spring-srv6-oam-00 will also >> >> remove o-bit or keep the o-bit in the later version? >> >> Ths >> >> ZhiBo Hu >> >> _______________________________________________ >> >> spring mailing list >> >> [email protected]<mailto:[email protected]> >> >> https://www.ietf.org/mailman/listinfo/spring >> >> -- >> >> Loa Andersson email: [email protected]<mailto:[email protected]> >> >> Senior MPLS Expert >> >> Bronze Dragon Consulting phone: +46 739 81 21 64 >> >> >> >> _______________________________________________ >> spring mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/spring >> >> > -- > > > Loa Andersson email: [email protected] > Senior MPLS Expert > Bronze Dragon Consulting phone: +46 739 81 21 64 > > _______________________________________________ > spring mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/spring >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
