Re: [nvo3] [spring] L4 Checksum and draft-ietf-6man-segment-routing-header
Robert Raszuk <robert@raszuk.net> Mon, 23 May 2016 08:10 UTC
Return-Path: <rraszuk@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3BD212D656; Mon, 23 May 2016 01:10:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.4
X-Spam-Level:
X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ABO1pXu2Z_1; Mon, 23 May 2016 01:09:57 -0700 (PDT)
Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 980C212D64D; Mon, 23 May 2016 01:09:56 -0700 (PDT)
Received: by mail-lf0-x229.google.com with SMTP id e126so44207777lfg.2; Mon, 23 May 2016 01:09:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=NhDnD1GyBvFkk7+CJsCHm+pJ0i0/uudnKCMtzcQnHAc=; b=tQ1wW2hrNHibAUZKT/Jg8JwIYp5RZ4ktiRf0stkGP1xoX0MHlsKVk+78uODRyiqylY jzJ+/7Iw39olhskrbz6zTxSTAKsJryYN1/hrNvcKmeZqkzqzswwA3LtJCjafBBl84U9U EE7o9BfEuI/MxwZ4aA7JH7Z0KSuMpiNOs79q6YW5uoqt8LJN0BlSBh0xfSjOHYDyQYoD CSw7oUNcqR2xmEpxs5k2wbenTmfdBDunv3hSx55k3klWmjyR5H57HkpHOBD3hkcm/Qc+ 4+OZaAD60aVPgIUaX2MUUHjZRUQ0/5oD9RZp/l+rIu2NlFaURIhnvGsGo9ZHKFMVYMWt IeAg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=NhDnD1GyBvFkk7+CJsCHm+pJ0i0/uudnKCMtzcQnHAc=; b=M349/Q5HOpfq/5TffQMQZPlTuqoczRC1YyBsMmjg2+Uata6cVRs3NFVKg3ZnhEyew1 k8Y7MTjJqxbf6inL1hqgNdZKnVoko7nPR7nTzGuZ1VnaF9DQ52PS/1sbT1q03ZJEQ+Hx SSgcy6UBWg7FAmLaWQNb7tD6FJ0JSqNwZUbZt0pxk12k18iP4MmMpyzIYYt4Az6nmx8O 1RNxnHIEKIxdo3GA0536l+6/9LmDq7/Mjth8dZLHOYpkunbD0wugWEsZL74NDyPRKMZe GcH8p9ijCJQhfLzxM5uTgxN6aE9CMnnP20Iws8SeFflCTEkrZJgrQI6sYf6MwRTTuXyg Xjdw==
X-Gm-Message-State: AOPr4FXsVJUdAYPXSn7dXaaGxHRSIRCNx4GtzWCuFH96mtrlyz9FZ5pNn9IuyFFAgJ5KChg6xQa1WPw026Gl5w==
MIME-Version: 1.0
X-Received: by 10.25.152.136 with SMTP id a130mr4597765lfe.104.1463990994609; Mon, 23 May 2016 01:09:54 -0700 (PDT)
Sender: rraszuk@gmail.com
Received: by 10.25.126.210 with HTTP; Mon, 23 May 2016 01:09:54 -0700 (PDT)
In-Reply-To: <1c27bb3513bc48889ec310e8d143784c@IL-EXCH02.marvell.com>
References: <eaf5cad817624c7a8758758aa058399b@IL-EXCH02.marvell.com> <AD825FC8-E5AB-437D-992B-F5900B67EFA7@employees.org> <ECB16B90-392C-4C98-B3EA-86050AE2BEBA@cisco.com> <5dc56935eba94c2390120244564f9b21@IL-EXCH02.marvell.com> <A5EFDE4C-BE25-4F5C-B176-E63740E94F4B@cisco.com> <ed76a19f5995465e8f4eddcba5d0c95c@IL-EXCH02.marvell.com> <0551686F-F1D2-4C34-81C8-530F1BEE1BDF@cisco.com> <5d889e7013b44b27ae1e75cf7ea2dd22@IL-EXCH02.marvell.com> <CALx6S35iChUWbF_Qp6Sf2s5ipPDqkNfVB1k0i=45Nq5q4OnS_w@mail.gmail.com> <3549ABBE-9828-42D2-A056-851432487E2E@cisco.com> <1e13d2e32b2448af94bf23d5acf17740@IL-EXCH02.marvell.com> <569a4067fd1f45dd85d60e983be69b90@IL-EXCH02.marvell.com> <CA+b+ER=zQbceetmYE-ehVczCVTcx0tawEZb1bdRB9ZktdfW7ZA@mail.gmail.com> <bb99730deb8348bcac4f5c433e88d435@IL-EXCH02.marvell.com> <CA+b+ERkQf5ezEZdP=+U0MBHHSX7cKVnxudVKCrJ0BX+5HBq1oQ@mail.gmail.com> <1c27bb3513bc48889ec310e8d143784c@IL-EXCH02.marvell.com>
Date: Mon, 23 May 2016 10:09:54 +0200
X-Google-Sender-Auth: aIS4qnwx_37XzLTxkimaoLI7LWQ
Message-ID: <CA+b+ERmsCQbjcGLK4sNo+B51pZyXTqFW6On_CeTbYq4gSjHwRw@mail.gmail.com>
Subject: Re: [nvo3] [spring] L4 Checksum and draft-ietf-6man-segment-routing-header
From: Robert Raszuk <robert@raszuk.net>
To: Tal Mizrahi <talmi@marvell.com>
Content-Type: multipart/alternative; boundary="001a11402cb830354505337df7cc"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipv6/trK5OZqboktH_AQd6aLWKsAxIco>
Cc: "spring@ietf.org" <spring@ietf.org>, 6man WG <ipv6@ietf.org>, "draft-ietf-nvo3-vxlan-gpe@tools.ietf.org" <draft-ietf-nvo3-vxlan-gpe@tools.ietf.org>, "nvo3@ietf.org" <nvo3@ietf.org>, "draft-ietf-6man-segment-routing-header@tools.ietf.org" <draft-ietf-6man-segment-routing-header@tools.ietf.org>, "draft-ietf-nvo3-geneve@tools.ietf.org" <draft-ietf-nvo3-geneve@tools.ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 May 2016 08:10:01 -0000
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 <talmi@marvell.com> 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:* rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of *Robert > Raszuk > *Sent:* Monday, May 23, 2016 10:47 AM > > *To:* Tal Mizrahi > *Cc:* spring@ietf.org; 6man WG; draft-ietf-nvo3-vxlan-gpe@tools.ietf.org; > nvo3@ietf.org; draft-ietf-6man-segment-routing-header@tools.ietf.org; > draft-ietf-nvo3-geneve@tools.ietf.org; 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 <talmi@marvell.com> 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:nvo3-bounces@ietf.org] *On Behalf Of *Robert Raszuk > *Sent:* Monday, May 23, 2016 10:29 AM > *To:* Tal Mizrahi > *Cc:* spring@ietf.org; 6man WG; draft-ietf-nvo3-vxlan-gpe@tools.ietf.org; > nvo3@ietf.org; draft-ietf-6man-segment-routing-header@tools.ietf.org; > draft-ietf-nvo3-geneve@tools.ietf.org; 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 <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 > > > > >
- L4 Checksum and draft-ietf-6man-segment-routing-h… Tal Mizrahi
- Re: [spring] L4 Checksum and draft-ietf-6man-segm… otroan
- RE: [spring] L4 Checksum and draft-ietf-6man-segm… Tal Mizrahi
- Re: [spring] L4 Checksum and draft-ietf-6man-segm… Stefano Previdi (sprevidi)
- Re: [spring] L4 Checksum and draft-ietf-6man-segm… Stefano Previdi (sprevidi)
- RE: [spring] L4 Checksum and draft-ietf-6man-segm… Tal Mizrahi
- Re: [spring] L4 Checksum and draft-ietf-6man-segm… Stefano Previdi (sprevidi)
- RE: [spring] L4 Checksum and draft-ietf-6man-segm… Tal Mizrahi
- Re: [spring] L4 Checksum and draft-ietf-6man-segm… Stefano Previdi (sprevidi)
- RE: [spring] L4 Checksum and draft-ietf-6man-segm… Tal Mizrahi
- Re: [spring] L4 Checksum and draft-ietf-6man-segm… Tom Herbert
- Re: [spring] L4 Checksum and draft-ietf-6man-segm… Stefano Previdi (sprevidi)
- RE: [spring] L4 Checksum and draft-ietf-6man-segm… Tal Mizrahi
- RE: [spring] L4 Checksum and draft-ietf-6man-segm… Mark Smith
- Re: L4 Checksum and draft-ietf-6man-segment-routi… Alexandre Petrescu
- Re: [spring] L4 Checksum and draft-ietf-6man-segm… Alexandre Petrescu
- Re: [spring] L4 Checksum and draft-ietf-6man-segm… Alexandre Petrescu
- Re: L4 Checksum and draft-ietf-6man-segment-routi… Mark Smith
- Re: L4 Checksum and draft-ietf-6man-segment-routi… Tom Herbert
- RE: [nvo3] [spring] L4 Checksum and draft-ietf-6m… Tal Mizrahi
- Re: [spring] [nvo3] L4 Checksum and draft-ietf-6m… Robert Raszuk
- RE: [nvo3] [spring] L4 Checksum and draft-ietf-6m… Tal Mizrahi
- Re: [nvo3] [spring] L4 Checksum and draft-ietf-6m… Robert Raszuk
- RE: [nvo3] [spring] L4 Checksum and draft-ietf-6m… Tal Mizrahi
- Re: [nvo3] [spring] L4 Checksum and draft-ietf-6m… Robert Raszuk
- Re: [nvo3] [spring] L4 Checksum and draft-ietf-6m… Jesse Gross
- Re: [nvo3] [spring] L4 Checksum and draft-ietf-6m… Larry Kreeger (kreeger)
- RE: [nvo3] [spring] L4 Checksum and draft-ietf-6m… Tal Mizrahi
- Re: [nvo3] [spring] L4 Checksum and draft-ietf-6m… Stefano Previdi (sprevidi)