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

[Robert Raszuk <[e-mail]>]

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
>
>
>