Re: [spring] [nvo3] 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 <talmi@marvell.com> 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:nvo3-bounces@ietf.org] On Behalf Of Tal Mizrahi
> >Sent: Tuesday, May 17, 2016 12:09 PM
> >To: Stefano Previdi (sprevidi); Tom Herbert; draft-ietf-nvo3-
> >geneve@tools.ietf.org; draft-ietf-nvo3-vxlan-gpe@tools.ietf.org
> >Cc: spring@ietf.org; nvo3@ietf.org; 6man WG; draft-ietf-6man-segment-
> >routing-header@tools.ietf.org
> >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:sprevidi@cisco.com]
> >>Sent: Tuesday, May 17, 2016 10:41 AM
> >>To: Tom Herbert
> >>Cc: Tal Mizrahi; 6man WG; spring@ietf.org;
> >>draft-ietf-6man-segment-routing- header@tools.ietf.org
> >>Subject: Re: [spring] L4 Checksum and draft-ietf-6man-segment-routing-
> >>header
> >>
> >>
> >>> On May 16, 2016, at 7:10 PM, Tom Herbert <tom@herbertland.com>
> >wrote:
> >>>
> >>> On Mon, May 16, 2016 at 4:32 AM, Tal Mizrahi <talmi@marvell.com>
> >>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:sprevidi@cisco.com]
> >>>>> Sent: Monday, May 16, 2016 2:24 PM
> >>>>> To: Tal Mizrahi
> >>>>> Cc: Ole Trøan;
> >>>>> draft-ietf-6man-segment-routing-header@tools.ietf.org;
> >>>>> spring@ietf.org; 6man WG
> >>>>> Subject: Re: [spring] L4 Checksum and
> >>>>> draft-ietf-6man-segment-routing- header
> >>>>>
> >>>>>
> >>>>>> On May 16, 2016, at 1:19 PM, Tal Mizrahi <talmi@marvell.com> 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:sprevidi@cisco.com]
> >>>>>>> Sent: Monday, May 16, 2016 2:13 PM
> >>>>>>> To: Tal Mizrahi
> >>>>>>> Cc: Ole Trøan;
> >>>>>>> draft-ietf-6man-segment-routing-header@tools.ietf.org;
> >>>>>>> spring@ietf.org; 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 <talmi@marvell.com>
> >>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:sprevidi@cisco.com]
> >>>>>>>>> Sent: Monday, May 16, 2016 11:59 AM
> >>>>>>>>> To: Ole Trøan; Tal Mizrahi
> >>>>>>>>> Cc: draft-ietf-6man-segment-routing-header@tools.ietf.org;
> >>>>>>>>> spring@ietf.org; 6man WG
> >>>>>>>>> Subject: Re: [spring] L4 Checksum and
> >>>>>>>>> draft-ietf-6man-segment-routing- header
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> On May 15, 2016, at 8:06 PM, otroan@employees.org 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 ipv6@ietf.org Administrative
> >>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>>> --------------------------------------------------------------------
> >
> >_______________________________________________
> >nvo3 mailing list
> >nvo3@ietf.org
> >https://www.ietf.org/mailman/listinfo/nvo3
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>