On Fri, May 31, 2019 at 7:05 AM Ahmed Abdelsalam <ahabdels....@gmail.com> wrote: > > On Thu, 30 May 2019 14:50:21 -0700 > Tom Herbert <t...@herbertland.com> wrote: > > > Mutable fields related to segment routing are: destination address, > > segments left, and modifiable TLVs (those whose high order bit is set). > > > > Add support to rearrange a segment routing (type 4) routing header to > > handle these mutability requirements. This is described in > > draft-herbert-ipv6-srh-ah-00. > > > > Hi Tom, David, > I think it is very early to have such implementation in the mainline of the > Linux kernel. > The draft (draft-herbert-ipv6-srh-ah-00) has been submitted to IETF draft > couple of days ago. > We should give the IETF community the time to review and reach a consensus on > this draft.
Hi Ahmed, That draft is based on the mutability requirements specified in draft-ietf-6man-segment-routing-header-19. It was quite an arduous battle even to get them to nail down any requirements about what bits the network is allowed to change (and even though the that draft is in WGLC, they _still_ are making changes in the area). IMO, the AH requirements should be part of the SRH specification as it is with any other extension headers, but the WG chairs decided to defer that to other docs and that is their prerogative-- hence my draft in response which is simple and straightforward. Regardless of the history and current state though, the current implementation allows both AH and SRH to be configured simultaneously. This won't work. If a user does this they may be in a world of hurt because the effects may be non deterministic. For instance, some packets for a flow might take a route that uses SRH, and some may not, so some packets get through and others don't-- that's going to be hard to debug. IMO, we shouldn't wait for IETF to get their act together on this which in their time frame can be years. We should take action to address an identified issue that could adversely impact users. If implementing this method isn't the right direction, please suggest an alternative. Thanks, Tom > Thanks, > Ahmed > > -- > Ahmed Abdelsalam <ahabdels....@gmail.com>
