Re: [spring] [nvo3] L4 Checksum and draft-ietf-6man-segment-routing-header

[Robert Raszuk <[e-mail]>]

Hi Tal,

> In order to avoid ambiguity, it would be great if the
> authors could explicitly mention that IPv6 extension
> headers are permitted.

Well the drafts are complaint to RFC2119 (normative reference) so unless
the text excludes elements with MUST/MUST NOT - everything else defined in
the building blocks they (re)use is permitted.

However as you say perhaps for clarity what could be added to those drafts
is a normative reference to IPv4 and IPv6 base RFCs.

Best,
R.


On Mon, May 23, 2016 at 9:54 AM, Tal Mizrahi <[e-mail]> wrote:

> Hi Robert,
>
>
>
> That makes sense.
>
> However, in this case the figures may be a bit confusing WRT the possible
> existence of extension headers. This confusion is what led to the
> discussion in this thread about whether segment routing is possible with
> VXLAN/VXLAN-GPE/Geneve encapsulations.
>
>
>
> In order to avoid ambiguity, it would be great if the authors could
> explicitly mention that IPv6 extension headers are permitted.
>
>
>
> Regards,
>
> Tal.
>
>
>
> *From:* [e-mail] [mailto:[e-mail]] *On Behalf Of *Robert
> Raszuk
> *Sent:* Monday, May 23, 2016 10:47 AM
>
> *To:* Tal Mizrahi
> *Cc:* [e-mail]; 6man WG; [e-mail];
> [e-mail]; [e-mail];
> [e-mail]; Stefano Previdi (sprevidi)
> *Subject:* Re: [nvo3] [spring] L4 Checksum and
> draft-ietf-6man-segment-routing-header
>
>
>
> Hi Tal,
>
>
>
> Indeed .. I saw the figures, but figures are non normative in any
> draft/rfc unless text below specifically spells it out.
>
>
>
> For example from vxlan-gpe:
>
>
>
> "When the outer IP header is IPv4, VTEPs MUST set the DF bit."
>
>
>
> Besides it is pretty challenging to add animation to the current draft
> formats to illustrate all possibly allowed field values/combinations in any
> figure :)  Figures just illustrate one use example.
>
>
>
> To me the current specs permit any value of IPv6 NxtHdr field as permitted
> in both encapsulations.
>
>
>
> Best,
>
> Robert.
>
>
>
>
>
> On Mon, May 23, 2016 at 9:35 AM, Tal Mizrahi <[e-mail]> wrote:
>
> Hi Robert,
>
>
>
>
>
> > Where say in draft draft-quinn-vxlan-gpe do you see such statement that
> would imply
>
> > that v6 NxtHdr must be only equal to 17 (UDP) and not be a pointer to
> any other type
>
> > of extension header further followed by UDP ?
>
>
>
>
>
> The following text is from Figure 4 in draft-ietf-nvo3-vxlan-gpe:
>
>
>
>       Outer IPv6 Header:
>
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>       |Version| Traffic Class |           Flow Label                  |
>
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>       |         Payload Length        | NxtHdr=17(UDP)|   Hop Limit   |
>
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>       |                                                               |
>
>
>
>
>
> There is a similar figure in draft-ietf-nvo3-geneve.
>
>
>
> Best regards,
>
> Tal.
>
>
>
> *From:* nvo3 [mailto:[e-mail]] *On Behalf Of *Robert Raszuk
> *Sent:* Monday, May 23, 2016 10:29 AM
> *To:* Tal Mizrahi
> *Cc:* [e-mail]; 6man WG; [e-mail];
> [e-mail]; [e-mail];
> [e-mail]; Stefano Previdi (sprevidi)
>
>
> *Subject:* Re: [nvo3] [spring] L4 Checksum and
> draft-ietf-6man-segment-routing-header
>
>
>
> Hi Tal,
>
>
>
> > drafts seem to imply
>
>
>
> Where say in draft draft-quinn-vxlan-gpe do you see such statement that
> would imply that v6 NxtHdr must be only equal to 17 (UDP) and not be a
> pointer to any other type of extension header further followed by UDP ?
>
>
>
> Thx,
> R.
>
>
>
>
>
> On Mon, May 23, 2016 at 7:50 AM, Tal Mizrahi <[e-mail]> wrote:
>
> Dear Authors of VXLAN-GPE / Geneve,
>
> I am reiterating on this question, as I haven't seen a response yet:
>
> Have you considered the use of Segment Routing with VXLAN-GPE / Geneve?
> The current VXLAN-GPE / Geneve drafts seem to imply that IPv6 extension
> headers are currently not supported.
>
> Thanks,
> Tal.
>
>
>
>
> >-----Original Message-----
> >From: nvo3 [mailto:[e-mail]] On Behalf Of Tal Mizrahi
> >Sent: Tuesday, May 17, 2016 12:09 PM
> >To: Stefano Previdi (sprevidi); Tom Herbert; draft-ietf-nvo3-
> >[e-mail]; [e-mail]
> >Cc: [e-mail]; [e-mail]; 6man WG; draft-ietf-6man-segment-
> >[e-mail]
> >Subject: Re: [nvo3] [spring] L4 Checksum and draft-ietf-6man-segment-
> >routing-header
> >
> >Stefano,
> >
> >If I understand your point correctly:
> >IPv6 segment routing does not work with VXLAN / VXLAN-GPE / Geneve, since
> >these encapsulations do not currently allow the use of IPv6 extension
> >headers.
> >
> >I wonder if the authors of VXLAN-GPE and Geneve have considered the use of
> >segment routing.
> >
> >Thanks,
> >Tal.
> >
> >
> >
> >>-----Original Message-----
> >>From: Stefano Previdi (sprevidi) [mailto:[e-mail]]
> >>Sent: Tuesday, May 17, 2016 10:41 AM
> >>To: Tom Herbert
> >>Cc: Tal Mizrahi; 6man WG; [e-mail];
> >>draft-ietf-6man-segment-routing- [e-mail]
> >>Subject: Re: [spring] L4 Checksum and draft-ietf-6man-segment-routing-
> >>header
> >>
> >>
> >>> On May 16, 2016, at 7:10 PM, Tom Herbert <[e-mail]>
> >wrote:
> >>>
> >>> On Mon, May 16, 2016 at 4:32 AM, Tal Mizrahi <[e-mail]>
> >>wrote:
> >>>>> it’s all about IP, not layer-2.
> >>>>>
> >>>>> s.
> >>>>
> >>>> Right. However, it appears that at least in some cases a VXLAN VTEP
> >>>> will
> >>use SR. It certainly may be the case in SFC use cases (see Section 2.3
> >>in draft- ietf-spring-ipv6-use-cases).
> >>>>
> >>>
> >>> draft-ietf-6man-segment-routing-header mentions that the packet is
> >>> encapsulated
> >>
> >>
> >>into an outer ipv6 header which makes it a layer-3 encap.
> >>
> >>
> >>> , but I don't think it is explicit as to exact encapsulation format
> >>> (I suppose simple ip6ip6 is implied).
> >>
> >>
> >>see section 2.2
> >>
> >>
> >>> But, it
> >>> seems like any of several encapsulation techniques could work (VXLAN,
> >>
> >>
> >>I have some problems to understand where to fit an extension header
> >>into a vxlan encap…
> >>
> >>
> >>> GRE/IP, ESP/IP, GUE, foo over UDP, etc.) and if a device that wants
> >>> to do SR is already doing tunneling it seems reasonable to me to only
> >>> have one layer of encapsulation. Maybe this should be clarified in
> >>> the draft?
> >>
> >>
> >>the draft is about IPv6 extension header and more precisely a new type
> >>of the routing extension header defined in rfc2460. That’s the context.
> >>
> >>
> >>s.
> >>
> >>
> >>
> >>
> >>>
> >>> Tom
> >>>
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Stefano Previdi (sprevidi) [mailto:[e-mail]]
> >>>>> Sent: Monday, May 16, 2016 2:24 PM
> >>>>> To: Tal Mizrahi
> >>>>> Cc: Ole Trøan;
> >>>>> [e-mail];
> >>>>> [e-mail]; 6man WG
> >>>>> Subject: Re: [spring] L4 Checksum and
> >>>>> draft-ietf-6man-segment-routing- header
> >>>>>
> >>>>>
> >>>>>> On May 16, 2016, at 1:19 PM, Tal Mizrahi <[e-mail]> wrote:
> >>>>>>
> >>>>>> Hi Stefano,
> >>>>>>
> >>>>>> Thanks again for the prompt response.
> >>>>>>
> >>>>>>> 2. the SRH is originated by the ingress node of the SR domain.
> >>>>>>> This is done by encapsulating the packet into a outer
> >>>>>>> (additional) ipv6 header followed by an SRH. This is L3
> >>>>>>> encapsulation and no L4 checksum is involved. When the  packet
> >>>>>>> leaves the SR tunnel the outer encapsulation  (including the SRH)
> >>>>>>> is removed and the packet continues  its journey like nothing
> >happened.
> >>>>>>
> >>>>>> So VXLAN is off the table?
> >>>>>
> >>>>>
> >>>>> it’s all about IP, not layer-2.
> >>>>>
> >>>>> s.
> >>>>>
> >>>>>
> >>>>>> It would be worthwhile to clarify this in the draft. If you have a
> >>>>>> specific
> >>>>> encapsulation in mind, it would be great if the draft would specify
> it.
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Tal.
> >>>>>>
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: Stefano Previdi (sprevidi) [mailto:[e-mail]]
> >>>>>>> Sent: Monday, May 16, 2016 2:13 PM
> >>>>>>> To: Tal Mizrahi
> >>>>>>> Cc: Ole Trøan;
> >>>>>>> [e-mail];
> >>>>>>> [e-mail]; 6man WG
> >>>>>>> Subject: Re: [spring] L4 Checksum and
> >>>>>>> draft-ietf-6man-segment-routing- header
> >>>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> On May 16, 2016, at 11:04 AM, Tal Mizrahi <[e-mail]>
> >>wrote:
> >>>>>>>>
> >>>>>>>> Hi Stefano,
> >>>>>>>>
> >>>>>>>> Thanks for the responses.
> >>>>>>>>
> >>>>>>>>> exactly.
> >>>>>>>>>
> >>>>>>>>> Moreover, draft-ietf-6man-segment-routing-header assumes
> >>>>>>>>> encapsulation so clearly there’s no L4 involved here.
> >>>>>>>>>
> >>>>>>>>> s.
> >>>>>>>>
> >>>>>>>> Two questions:
> >>>>>>>> 1. What if the encapsulation is VXLAN? L4 would still be
> >>>>>>>> involved,
> >>right?
> >>>>>>>
> >>>>>>>
> >>>>>>> See below.
> >>>>>>>
> >>>>>>>
> >>>>>>>> 2. When you say 'assumes encapsulation', does it mean that a
> >>>>>>>> host cannot
> >>>>>>> send an IPv6 packet with an SRH? The current draft says:
> >>>>>>>>
> >>>>>>>> A Source SR Node can be any node originating an IPv6 packet with
> >>>>>>>> its
> >>>>>>>> IPv6 and Segment Routing Headers.  This include either:
> >>>>>>>>
> >>>>>>>>    A host originating an IPv6 packet.
> >>>>>>>>
> >>>>>>>>    An SR domain ingress router encapsulating a received IPv6
> packet
> >>>>>>>>    into an outer IPv6 header followed by an SRH.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Will appreciate if you can clarify that.
> >>>>>>>
> >>>>>>>
> >>>>>>> ok, two cases:
> >>>>>>>
> >>>>>>> 1. the SRH is inserted at the source.
> >>>>>>> the source originates the packet, the ipv6 header and  the SRH.
> >>>>>>> The source computes L4 checksum taking into  account the whole
> >>IPv6+SRH.
> >>>>>>> Here, theres’ nothing new  compared to rfc2460.
> >>>>>>>
> >>>>>>> 2. the SRH is originated by the ingress node of the SR domain.
> >>>>>>> This is done by encapsulating the packet into a outer
> >>>>>>> (additional) ipv6 header followed by an SRH. This is L3
> >>>>>>> encapsulation and no L4 checksum is involved. When the  packet
> >>>>>>> leaves the SR tunnel the outer encapsulation  (including the SRH)
> >>>>>>> is removed and the packet continues  its journey like nothing
> >happened.
> >>>>>>>
> >>>>>>> s.
> >>>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>> Tal.
> >>>>>>>>
> >>>>>>>>> -----Original Message-----
> >>>>>>>>> From: Stefano Previdi (sprevidi) [mailto:[e-mail]]
> >>>>>>>>> Sent: Monday, May 16, 2016 11:59 AM
> >>>>>>>>> To: Ole Trøan; Tal Mizrahi
> >>>>>>>>> Cc: [e-mail];
> >>>>>>>>> [e-mail]; 6man WG
> >>>>>>>>> Subject: Re: [spring] L4 Checksum and
> >>>>>>>>> draft-ietf-6man-segment-routing- header
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> On May 15, 2016, at 8:06 PM, [e-mail] wrote:
> >>>>>>>>>>
> >>>>>>>>>> Tal,
> >>>>>>>>>>
> >>>>>>>>>>> [Apologies if this issue has been discussed before.]
> >>>>>>>>>>>
> >>>>>>>>>>> According to draft-ietf-6man-segment-routing-header, an ‘SR
> >>>>>>>>>>> Segment
> >>>>>>>>> Endpoint Node’ updates the Destination IP address.
> >>>>>>>>>>> Therefore, it must also update the Layer 4 Checksum, right?
> >>>>>>>>>>>
> >>>>>>>>>>> I wonder if there is an upper bound on the size of the SRH.
> >>>>>>>>>>> Otherwise, the
> >>>>>>>>> L4 Checksum may be located in a pretty deep location.
> >>>>>>>>>>> Speaking from a chip vendor’s perspective this may be a
> problem.
> >>>>>>>>>>
> >>>>>>>>>> From RFC2460, RH0:
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>   o  If the IPv6 packet contains a Routing header, the
> Destination
> >>>>>>>>>>      Address used in the pseudo-header is that of the final
> >>>>>>>>>>      destination.  At the originating node, that address will
> be in
> >>>>>>>>>>      the last element of the Routing header; at the
> recipient(s),
> >>>>>>>>>>      that address will be in the Destination Address field of
> the
> >>>>>>>>>>      IPv6 header.
> >>>>>>>>>>
> >>>>>>>>>> I would expect SR would work the same.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> exactly.
> >>>>>>>>>
> >>>>>>>>> Moreover, draft-ietf-6man-segment-routing-header assumes
> >>>>>>>>> encapsulation so clearly there’s no L4 involved here.
> >>>>>>>>>
> >>>>>>>>> s.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Cheers,
> >>>>>>>>>> Ole
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>>> --------------------------------------------------------------------
> >>>> IETF IPv6 working group mailing list [e-mail] Administrative
> >>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>>> --------------------------------------------------------------------
> >
> >_______________________________________________
> >nvo3 mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/nvo3
>
> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>
>
>
>
>