Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields)
Tom Herbert <tom@herbertland.com> Sat, 06 April 2019 23:06 UTC
Return-Path: <tom@herbertland.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 E86D1120167 for <ipv6@ietfa.amsl.com>; Sat, 6 Apr 2019 16:06:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.089
X-Spam-Level:
X-Spam-Status: No, score=0.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 ESRh3fuXqf7g for <ipv6@ietfa.amsl.com>; Sat, 6 Apr 2019 16:06:37 -0700 (PDT)
Received: from mail-qt1-x842.google.com (mail-qt1-x842.google.com [IPv6:2607:f8b0:4864:20::842]) (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 F1F29120283 for <ipv6@ietf.org>; Sat, 6 Apr 2019 16:06:36 -0700 (PDT)
Received: by mail-qt1-x842.google.com with SMTP id p20so11449280qtc.9 for <ipv6@ietf.org>; Sat, 06 Apr 2019 16:06:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dLudskw2ivLynr1sk8PPC4FK13aE3fDOGxLg7py9rmE=; b=B89u7WyyTRjOnAxv2Gu30AjKQXzEVQ+d9riACfDRSD+FJONGlguUL36+XrWelss7Xf er833ks1TAT9bwPUPVTDovCysFiYD24vGQm2qsS1FpOIzSeXv/Is/lEgu6PTKksjDfEK lauI7o1cMj8htMy7ISdDiea43DQ2fOJAuTXTPz5Jvftt7hEx9OQH5bnkCZGyJ2GVHrDu /WwMswtNTnI/NZkfQrHmZpU5LDsEMubZSl/Y7Vtr5i+TeqyVMfH22Jg9mlh364ZMZQ/8 2EKB/Y9zrsQ66HL4XU5naSTHWzfJ5SiCoC/wl9nlAnljr0Rju9zxYQXZfbyHeCpzNIX9 Nvow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dLudskw2ivLynr1sk8PPC4FK13aE3fDOGxLg7py9rmE=; b=H5OZSZRglgYHEs3bXgRM/oZ0evyAFlICfMpqW8xi/Y3vQcwkXaVt26cDGHmKeBF2Ut UcygqLDddDVcsc1s/FpoFYc2pHrEyB60dUhlQaRaCW/AyHSRRs6gxUdFXhr1cv68Xhe1 sVUagdD/BLidwTZEzOLYV5rWgyxLeiFOIh/fAqnNHc1BI1oXztvqcucTDmhYxFUX9Ua+ WeTLg0XGcmQFrZEUzzZFGbu6V939HbHQN7kHHwKw1nlBHuwMS14v9lqnsXLhfwrbE5AC ecIMKSdt9j793A2PSwciqd0gcfZ6Gsn85mtM8R3EzYwHpq4Dj3vUxVevgW0fpbf8lI7U gAKw==
X-Gm-Message-State: APjAAAXL5Prv2X+HfPRlNAYV2eXPYgEZ7yO6sTaC4KaxUBURJKvl9Xdr kBnCBRicLXPDWJ1S3qwlfCuERo8nSyxQFgZBAKKPYw==
X-Google-Smtp-Source: APXvYqyL7TgE5Sp1Vlu9GiTKC8LrlvPbdw4I20/G2of7+2XD5miD61lizn9Chg9Jo1jX7/ohLat6ovk7QfUw+kC2GL8=
X-Received: by 2002:ac8:1833:: with SMTP id q48mr17871274qtj.133.1554591995713; Sat, 06 Apr 2019 16:06:35 -0700 (PDT)
MIME-Version: 1.0
References: <CACL_3VGxyn-PYosFsKPVdd8C=P5AbE6HD1zrimHKuh2MPkhnuQ@mail.gmail.com> <505272eac2dd44fa891d4d36d14da9af@XCH-RCD-008.cisco.com> <CAO42Z2wGMzc_RT=eWTx9Ve-5reS0nCWiteGOuE16=MB4Fg8mkg@mail.gmail.com> <f50040ab52d04867b9a5cefa1c3131c3@XCH-RCD-008.cisco.com> <CAO42Z2zgguekybwVuCh8Az3mK8gHp292BYnWYhJq-8KEyfKzOA@mail.gmail.com> <7ea9049fe6f44a40aefe4801bd796322@XCH-RCD-008.cisco.com> <CAO42Z2y5TS1+8YxNsr=BKz5v8-ZPTiO-M7CU2k6FzNqVZoU4VA@mail.gmail.com> <CY4PR11MB1335960AD9BF9A4B990F7E10DA4A0@CY4PR11MB1335.namprd11.prod.outlook.com> <CAO42Z2xqq=uksNQPxvF_CRSxf1V_MADbFurzW4hqQW0v478cyw@mail.gmail.com> <DM6PR11MB36254EAC97ACF07F5BAD43CADA5F0@DM6PR11MB3625.namprd11.prod.outlook.com> <DM6PR11MB362528DB0EADA21493CC49A3DA590@DM6PR11MB3625.namprd11.prod.outlook.com> <alpine.DEB.2.20.1904011139550.3490@uplift.swm.pp.se> <BN8PR11MB36181C47785968D8FCA2DED9DA550@BN8PR11MB3618.namprd11.prod.outlook.com> <alpine.DEB.2.20.1904020744260.3490@uplift.swm.pp.se> <MN2PR11MB36299BC5A8F12770A6EABA01DA560@MN2PR11MB3629.namprd11.prod.outlook.com> <4278D47A901B3041A737953BAA078ADE1478D5E2@DGGEML532-MBX.china.huawei.com> <VI1PR05MB4125507A0428AA013BDC9B1BB9500@VI1PR05MB4125.eurprd05.prod.outlook.com> <4278D47A901B3041A737953BAA078ADE1478EC8B@DGGEML532-MBX.china.huawei.com> <CALx6S34K_ph8n8woCQ=OVUtYLadOkuBDHRwLj+rtMYRba1ELdA@mail.gmail.com> <14A3D5C9-1EED-4E11-9329-B62B819271A2@broadcom.com> <CALx6S36wRZ_e8urjUxn_mxiPEEHNoddyCQddWhdCHuADeKMNNQ@mail.gmail.com> <20D6FCDB-3357-4728-BD52-8069C32F3CCA@broadcom.com> <CALx6S37wH7CaeK62V01-3c3ZzoKOYt9jLO7ZdZwynXk_K21v4Q@mail.gmail.com> <C2536DCF-7A40-4B64-8F6B-FBD2A14AA6D2@broadcom.com> <CALx6S374kUHibOvmFTHKKbu6bh2=eUo6s0LYW046KON68J-NHg@mail.gmail.com> <DBE7FD78-1049-4B15-945D-940974E0DB40@broadcom.com> <CALx6S35daeVxuaya+YNUu=nA-cTWL8bLqVOpJHD9rd1SvRFQqg@mail.gmail.com> <57A32C37-AAE9-44F2-9C96-39AFA71BDC21@broadcom.com> <CALx6S35rnb-gfKiHCmrJwF98OqCSUO4mC58Ss9o6A_CxOo5SyQ@mail.gmail.com> <36B9204A-D1EE-4067-92BB-6C33CB2DF791@broadcom.com> <CALx6S34iPGSv7wvbQE6juCv+JdK3rWFkvkJ-2+HtMfRRf8hMOQ@mail.gmail.com> <6E177A89-8488-4E24-A37A-B4C14D8ACB0D@broadcom.com> <CALx6S37TPjxQkOp+FNXrZ_vgknf5zpB0mENzGtwZMWwZ8hwE9g@mail.gmail.com> <0B28F885-A556-4E1A-ABE5-42E5B078D257@broadcom.com> <CAO42Z2wFj7HeM+EaVgCvZ2DpKOxTYOLNDc8t8Cuian4_gBK0cg@mail.gmail.com>
In-Reply-To: <CAO42Z2wFj7HeM+EaVgCvZ2DpKOxTYOLNDc8t8Cuian4_gBK0cg@mail.gmail.com>
From: Tom Herbert <tom@herbertland.com>
Date: Sat, 06 Apr 2019 15:56:47 -0700
Message-ID: <CALx6S35YGb4_qk==hgoyUDR2LMTD6_aW6BZ-9qKaUvN2ptA2nA@mail.gmail.com>
Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields)
To: Mark Smith <markzzzsmith@gmail.com>
Cc: Jai Kumar <jai.kumar=40broadcom.com@dmarc.ietf.org>, "C. M. Heard" <heard@pobox.com>, 6man <ipv6@ietf.org>, ippm <ippm@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000aceddf0585e4a791"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/lBLEMnmmu8oaK6RHFtnnzewhEYQ>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
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: Sat, 06 Apr 2019 23:06:43 -0000
On Sat, Apr 6, 2019, 3:36 PM Mark Smith <markzzzsmith@gmail.com> wrote: > On Sun, 7 Apr 2019 at 07:06, Jai Kumar > <jai.kumar=40broadcom.com@dmarc.ietf.org> wrote: > > > > Tom, > > > > We are talking about nexthop I.e. packet forwarding not member link > selection in load balancing. > > Basic packet forwarding is broken with options. > > > > If I understand this statement correctly, it isn't basic forwarding if > options other than the Hop-by-Hop option is considered. > > IPv6 forwarding is designed to only use the fields in the fixed IPv6 > header (with one exception) - that is why those fields are not > optional. > Thanks for the explanation Mark. I would only add that RFC8200 essentially makes that one exception (HBH options) optional to process. Tom > The only IPv6 option/EH that can be used in forwarding is the > Hop-by-Hop option, and it is required to be directly after the IPv6 > fixed header. > > Any other IPv6 options/EH are not designed nor intended to be used in > IPv6 forwarding. > > > Perhaps one thing people suggesting things to this Working Group can > forget is that our protocol is more than two decades old and that we > have a very large installed base of devices that support it and that > are being used constantly (this email is coming over IPv6). > > So we can't just make arbitrary changes to the protocol to suit new > requirements, unlike greenfield IETF Working Groups with no or a very > limited installed base can. We have to try our hardest to accommodate > those new requirements within the specifications and within existing > deployments. > > So if a new method of doing something is proposed, we here are going > to be looking to see how it can be done using existing, proven and > well-known methods first (e.g, adding supplementary information to > packets via IPv6-in-IPv6 encapsulation, ECMP via Flow Label rather > than digging up the UDP/TCP headers.) > > Regards, > Mark. > > > > -Jai > > > > > On Apr 6, 2019, at 12:55 PM, Tom Herbert <tom@herbertland.com> wrote: > > > > > >> On Sat, Apr 6, 2019 at 9:41 AM Jai Kumar <jai.kumar@broadcom.com> > wrote: > > >> > > >> Tom, > > >> > > >> Please read the IOAM draft again. There is a variable length metadata > stack as well with trace option. Forwarding becomes completely > indeterministic. > > > > > > Jai, > > > > > > Use the flow label and addresses as input to ECMP forwarding _is_ > > > deterministic. And not just for deterministic for TCP or UDP, but for > > > _any_ protocol, combination of EH, encryptions, etc. that a packet > > > carries. See RFC6438. > > > > > >> In short using options forwarding gets impacted for EH. You still > want to push for it go by all means but don't expect a silicon vendor or > deployment to agree for it. > > > > > > I'm not sure what we're trying to get agreement on. The only > > > expectation we have is that vendors, and everyone else for that > > > matter, conform to IETF standards. Extension headers have be defined > > > for over twenty years and are full standard, and now that people want > > > to use them there appears to be _some_ implementations (emphasis on > > > the word "some") that seem to have a problem processing them. Frankly, > > > that is a shortcoming of implementation, not of the protocol. The only > > > protocol shortcoming that has thus far been identified in the IOAM > > > discussion is the fact that EH don't exist in IPv4 and there is really > > > no alternative that provides the necessary functionality-- this is > > > something I believe IETF can work on. > > > > > > Tom > > > > > >> > > >> -Jai > > >> > > >> On 4/5/19, 5:05 PM, "Tom Herbert" <tom@herbertland.com> wrote: > > >> > > >>> On Fri, Apr 5, 2019 at 4:40 PM Jai Kumar <jai.kumar@broadcom.com> > wrote: > > >>> > > >>> Tom, > > >>> > > >>> > > >>> > > >>> You are right. There are two main cases where accessibility of > transport header becomes an issue. And that is mainly because of current > generation of fixed pipeline cell based architecture parse depth (not so > much an issue for high end NPU where next packet header bytes can be DMA’ed > in, though it impacts the performance. For eg. Cisco QFP NPU, EZ Chip, > Juniper’s MX 3D NPU, or Broadcom’s Jerricho NPU ). This was mentioned > earlier by Mikael as well. > > >>> > > >>> > > >>> > > >>> Case 1. SRv6 > > >>> > > >>> Case 2. IPv6 with EH (mainly for 5G deployments where RH, DH, and > IFA Header) > > >>> > > >>> > > >>> > > >>> Typically NPUs provide capability that it will handle 3 or 4 EH or > SRH without performance penalty. With the presence of IFA header this means > that for eg there can be only 2 or 3 SRH or EH. This is same as in MPLS > label stack depth handling (PUSH or POP at PE router). Given the evolution > SRV6 and MPLS-SR kind of headers, silicon vendors have taken a notice of it > and are evolving the silicon arch to handle more chained headers. > > >>> > > >>> > > >>> > > >>> IFA supports fragmentation of metadata stack and also postcard mode > so beyond the transport header it’s not an issue. > > >>> > > >>> > > >>> > > >>> Just a quick feedback on using IPv6 options, inserting hop by hop > options for data path processing pushes the EH further down and impacts the > node’s forwarding function (say if it is not able to reach Destination EH) > vs if IFA header is the last EH then atmost transit node do not perform > metadata collection which can be identified. > > >> > > >> Maybe it does impact it, maybe it doesn't. It clearly depends on > the > > >> device capabilities. For a device with a parsing buffer of 256 > bytes > > >> that should be plenty of room for HBH options, SR header, transport > > >> layer, etc. > > >> > > >>> > > >>> > > >>> > > >>> -Jai > > >>> > > >>> > > >>> > > >>> From: Tom Herbert <tom@herbertland.com> > > >>> Date: Friday, April 5, 2019 at 3:34 PM > > >>> To: Jai Kumar <jai.kumar@broadcom.com> > > >>> Cc: "Pengshuping (Peng Shuping)" <pengshuping@huawei.com>, 6man < > ipv6@ietf.org>, ippm <ippm@ietf.org>, "C. M. Heard" <heard@pobox.com>, > Mikael Abrahamsson <swmike@swm.pp.se> > > >>> Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 > feedback (Re: v6 option types for IOAM data fields) > > >>> > > >>> > > >>> > > >>> Jai, > > >>> > > >>> > > >>> > > >>> You might want to consider how IFA works in the presence of segment > routing. The second someone puts an SRH in the packet the IFA headers get > pushed down and the transport headers end up being deep in the packet > anyway so that all the effort of IFA is nullified. If the requirement is to > ensure that the transport layer information appear as early as possible in > the packet, one could define a Hop-by-Hop option to carry some sort of > pseudo header for the transport layer. This also would work in the case > that the actual transport layer is obfuscated. > > >>> > > >>> > > >>> > > >>> Tom > > >>> > > >>> > > >>> > > >>> On Fri, Apr 5, 2019, 3:09 PM Jai Kumar <jai.kumar@broadcom.com> > wrote: > > >>> > > >>> “That is going to require justifying the protocol even in light of > shortcomings in existing protocoIs.” > > >>> > > >>> > > >>> > > >>> Agreed !!! True for any proposal. > > >>> > > >>> > > >>> > > >>> -Jai > > >>> > > >>> > > >>> > > >>> From: Tom Herbert <tom@herbertland.com> > > >>> Date: Friday, April 5, 2019 at 2:34 PM > > >>> To: Jai Kumar <jai.kumar@broadcom.com> > > >>> Cc: "Pengshuping (Peng Shuping)" <pengshuping@huawei.com>, 6man < > ipv6@ietf.org>, ippm <ippm@ietf.org>, "C. M. Heard" <heard@pobox.com>, > Mikael Abrahamsson <swmike@swm.pp.se> > > >>> Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 > feedback (Re: v6 option types for IOAM data fields) > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> On Fri, Apr 5, 2019, 2:07 PM Jai Kumar <jai.kumar@broadcom.com> > wrote: > > >>> > > >>> Tom, > > >>> > > >>> Its all explained in the requirements section of the draft. IFA > header is essentially treated as an EH both in IPv4 and IPv6 (very similar > to AH/ESP EH). > > >>> > > >>> Just like in AH/ESP the IP protocol is copied in the AH header and > IP protocol field is replaced in the IP header with the AH proto. > > >>> > > >>> There are several advantages to this approach. > > >>> - devise know how to parse AH header and can follow very similar > approach > > >>> - Protocol agnostics, silicon need not support N encaps (just like > AH/ESP). Single implementation works for all protocol types. > > >>> - No need to creation options and teach devices that options is NOT > an exception path processing > > >>> - Really worry about ordering in IPv6 options > > >>> - Note that all the OAM data need to be deleted as well so position > need to be optimal for removal. We can always do tail stamping of the data > but this puts considerable constrains on the cell based architecture > > >>> - L4 accessibility I have already mentioned > > >>> > > >>> I am happy to discuss with you in person and explain more but bottom > line is that this proposal is what came out with MSDC discussions in light > of shortcomings from other IETF proposals. > > >>> > > >>> > > >>> > > >>> As they say, you are free to run whatever you want in your > proprietary network, but if you expect to create an interoperable, > deployable protocoI and get a protocol number assignment, you'll need to > work in ietf. That is going to require justifying the protocol even in > light of shortcomings in existing protocoIs. > > >>> > > >>> > > >>> > > >>> Tom > > >>> > > >>> > > >>> > > >>> > > >>> Regards, > > >>> -Jai > > >>> > > >>> > > >>> On 4/5/19, 12:28 PM, "Tom Herbert" <tom@herbertland.com> wrote: > > >>> > > >>>> On Fri, Apr 5, 2019 at 12:03 PM Jai Kumar < > jai.kumar@broadcom.com> wrote: > > >>>> > > >>>> " Great, but this IETF" > > >>>> Does it mean that drafts have no relevance to deployment and actual > adoption. > > >>>> > > >>>> For all your queries please take a look at IFA draft. > > >>>> https://datatracker.ietf.org/doc/draft-kumar-ippm-ifa/ > > >>>> > > >>> I've looked at that draft. It's is creating a complete new IP > > >>> protocolas well as a new packet format for TCP and UDP that > somehow > > >>> inserts meta data between the TCP header and payload. I don't > > >>> understand why this could possibly be better than just using flow > > >>> label for ECMP and teaching devices that need to extract transport > > >>> information how to walk over EH, or just using some UDP > encpasulation > > >>> like in draft-herbert-ipv4-udpencap-eh-01. > > >>> > > >>> Tom > > >>> > > >>>> It handles IPv6, IPv4 TCP/UDP with altering the packet path (due to > inserting options and/or encaping them in GRE header) as well as IPSec > AH/ESP/WESP both tunnel and transport and guess what it is successfully > deployed. > > >>>> > > >>>> -Jai > > >>>> > > >>>> On 4/5/19, 11:54 AM, "Tom Herbert" <tom@herbertland.com> wrote: > > >>>> > > >>>>> On Fri, Apr 5, 2019 at 11:25 AM Jai Kumar < > jai.kumar@broadcom.com> wrote: > > >>>>> > > >>>>> Tom, > > >>>>> > > >>>>> I am speaking based on the actual deployment not based on if all > the traffic is/will move to IPSec tunnel. > > >>>>> > > >>>>> I have 6 large customer deployments and one someone previously > called as "Yahoo" who insist on visibility in L4 even for IOAM packets. > > >>>>> > > >>>> And I've worked in datcenters much larger, and my first rule is > that I > > >>>> don't want random router vendors dictating to me what protocols > I'm > > >>>> allowed to use in my datacenter. > > >>>> > > >>>>> I can quote you on that and lose my business :-) > > >>>>> > > >>>>> ECMP argument is weak as well as it works for IPv6 flow label. > What about IPv4 TCP/UDP traffic which typically is 80% of the traffic in > MSDC. > > >>>>> > > >>>> > > >>>> draft-herbert-ipv4-udpencap-eh-01 > > >>>> > > >>>>> If someone tells me that proposal will work only for my 20% of > traffic then again as I said before, they will lose my business :-) > > >>>>> > > >>>> Great, but this IETF. Where are the protocol requirements? If > you are > > >>>> saying that there are requirements for "visibility in L4" what > are > > >>>> they? If you are saying that ACLs are now required for packet > > >>>> forwarding, where is that described? Is it a MUST that teh only > > >>>> transport protocols we're allowed to use are UDP or TCP? Are we > > >>>> allowed to use extension headers at all? I suppose fragmentation > is > > >>>> right out... Are we violating the requirements if we encrypt the > > >>>> transport headers? If you say that we shouldn't send long headers > > >>>> because we'll overflow parsing buffers, then what is the limit? > Please > > >>>> be SPECIFC in setting requirements; we are trying to build > protocols > > >>>> that work and are interoperable and we need to get out of this > morass > > >>>> of reverse engineering to discover the least common denominator. > > >>>> > > >>>> Tom > > >>>> > > >>>>> Regards, > > >>>>> -Jai > > >>>>> > > >>>>> On 4/5/19, 11:15 AM, "Tom Herbert" <tom@herbertland.com> wrote: > > >>>>> > > >>>>>> On Fri, Apr 5, 2019 at 10:55 AM Jai Kumar < > jai.kumar@broadcom.com> wrote: > > >>>>>> > > >>>>>> Even if we use flow label for ECMP, lack of accessibility of L4 > information (for various services, most simple is ACL) makes the proposal > pretty much unusable. > > >>>>>> > > >>>>> That is convoluting router and firewall functionality and > > >>>>> requirements. This a discussion about packet forwarding which > does > > >>>>> _not_ require ACLs. In a limited domain, for which IOAM is > intended, > > >>>>> it is unlikely that they'll ACLs would be used in internal > nodes, but > > >>>>> we do need good ECMP routing at all intermediate nodes need to > be > > >>>>> consistent rather or not that the IOAM option is present. As > side > > >>>>> note, the ability to extract L4 information out of packets is > > >>>>> dwindling anyway thanks to encryption and other techniques > trying to > > >>>>> undo protocol ossification. For instance, good luck getting L4 > > >>>>> information out of an IPsec tunnel :-). > > >>>>> > > >>>>> Tom > > >>>>> > > >>>>>> NIC cards are not used pervasively for ACLs and other services, I > believe iptables in kernel are good enough for host but that’s not > acceptable in networking elements. > > >>>>>> > > >>>>>> -Jai > > >>>>>> > > >>>>>> On 4/5/19, 10:31 AM, "ippm on behalf of Tom Herbert" < > ippm-bounces@ietf.org on behalf of tom@herbertland.com> wrote: > > >>>>>> > > >>>>>> On Fri, Apr 5, 2019 at 9:16 AM Pengshuping (Peng Shuping) > > >>>>>> <pengshuping@huawei.com> wrote: > > >>>>>>> > > >>>>>>> Hi Barak, > > >>>>>>> > > >>>>>>> We are certainly not designing for the lowest capable solutions > but exploring optimal solutions which could help to keep the forwarding > performance while inserting the iOAM data with variable length. > > >>>>>> > > >>>>>> Shuping, > > >>>>>> > > >>>>>> That's exactly the argument for using the flow label in ECMP. > > >>>>>> Efficeint packet forwarding can be done solely by inspected > the forty > > >>>>>> byte fixed length header of the packet regardless of the > contents of > > >>>>>> the rest of the packet. That is an optimal solution. Anything > else for > > >>>>>> ECMP like doing DPI or hacking up IOAM to try do pull > transport layers > > >>>>>> into the parsing buffer (whatever size that may be) are > nothing more > > >>>>>> than hacks and unnecessarily perpetuate techniques used with > IPv4 that > > >>>>>> either don't work or are unnecessary in IPv6. > > >>>>>> > > >>>>>> Tom > > >>>>>> > > >>>>>> > > >>>>>>> > > >>>>>>> In terms of the forwarding efficiency, we would all agree that a > short and fixed header would be better than a variable header. > > >>>>>>> > > >>>>>>> Best regards > > >>>>>>> Shuping > > >>>>>>> > > >>>>>>> > > >>>>>>> 发件人: Barak Gafni<gbarak@mellanox.com> > > >>>>>>> 收件人: Pengshuping (Peng Shuping)<pengshuping@huawei.com>;Frank > Brockners (fbrockne)<fbrockne@cisco.com>;Mikael Abrahamsson< > swmike@swm.pp.se> > > >>>>>>> 抄送: C. M. Heard<heard@pobox.com>;6man WG<ipv6@ietf.org>;Mark > Smith<markzzzsmith@gmail.com>;ippm<ippm@ietf.org> > > >>>>>>> 主题: RE: draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 > feedback (Re: v6 option types for IOAM data fields) > > >>>>>>> 时间: 2019-04-05 03:18:26 > > >>>>>>> > > >>>>>>> Hi Shuping, > > >>>>>>> I think that the question is whether we design for the lowest > capable solutions. I assume someone can find solutions with even lower > amount of parsing.. The low end solutions for these capabilities may need > to either adopt with new designs or use solutions such as what is suggested > in this thread by Tom Herbert. > > >>>>>>> Personally, I don't think we should go this way, but to design > appropriate solutions, with appropriate layers in the headers. For example, > prevent dependencies between "remote" headers. > > >>>>>>> > > >>>>>>> Thanks, > > >>>>>>> Barak > > >>>>>>> > > >>>>>>> -----Original Message----- > > >>>>>>> From: ippm <ippm-bounces@ietf.org> On Behalf Of Pengshuping > (Peng Shuping) > > >>>>>>> Sent: Wednesday, April 3, 2019 6:47 AM > > >>>>>>> To: Frank Brockners (fbrockne) <fbrockne@cisco.com>; Mikael > Abrahamsson <swmike@swm.pp.se> > > >>>>>>> Cc: C. M. Heard <heard@pobox.com>; 6man WG <ipv6@ietf.org>; > Mark Smith <markzzzsmith@gmail.com>; ippm@ietf.org > > >>>>>>> Subject: [ippm] 答复: > draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option > types for IOAM data fields) > > >>>>>>> > > >>>>>>> Hi, > > >>>>>>> > > >>>>>>> The parsing depth of the early chips is 96B/128B. For the new > chips the parsing depth has been increased but still limited. So Mikael's > concern makes sense especially in the tracing mode that the IOAM data > fields are going to increase significantly along the path, which will even > push the Routing Header out of the parsing depth of the chip. So it would > make sense to split the IOAM data part from the IOAM header/instruction > part, and place the IOAM data after the RH or even after the L4 header in > order to be able to read the L4 information to enable ECMP, as stated in > the draft > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-li-6man-ipv6-sfc-ifit-00&data=02%7C01%7Cgbarak%40mellanox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636898960379485833&sdata=Dob4zN%2F1jSGxLTlqGma29JJNvqJDBt4VzqHsN4OpxM4%3D&reserved=0 > . > > >>>>>>> > > >>>>>>> BR, > > >>>>>>> Shuping > > >>>>>>> > > >>>>>>> > > >>>>>>> -----邮件原件----- > > >>>>>>> 发件人: ippm [mailto:ippm-bounces@ietf.org] 代表 Frank Brockners > (fbrockne) > > >>>>>>> 发送时间: 2019年4月2日 17:40 > > >>>>>>> 收件人: Mikael Abrahamsson <swmike@swm.pp.se> > > >>>>>>> 抄送: C. M. Heard <heard@pobox.com>; 6man WG <ipv6@ietf.org>; > Mark Smith <markzzzsmith@gmail.com>; ippm@ietf.org > > >>>>>>> 主题: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 > feedback (Re: v6 option types for IOAM data fields) > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> -----Original Message----- > > >>>>>>> From: Mikael Abrahamsson <swmike@swm.pp.se> > > >>>>>>> Sent: Dienstag, 2. April 2019 08:06 > > >>>>>>> To: Frank Brockners (fbrockne) <fbrockne@cisco.com> > > >>>>>>> Cc: Mark Smith <markzzzsmith@gmail.com>; C. M. Heard < > heard@pobox.com>; 6man WG <ipv6@ietf.org>; ippm@ietf.org > > >>>>>>> Subject: RE: draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 > feedback (Re: v6 option types for IOAM data fields) > > >>>>>>> > > >>>>>>>> On Mon, 1 Apr 2019, Frank Brockners (fbrockne) wrote: > > >>>>>>>> > > >>>>>>>> ...FB: There is obviously no easy answer. Couple of thoughts: > > >>>>>>>> * IOAM is considered a "domain specific" feature (see > > >>>>>>>> draft-ietf-ippm-ioam-data-05, section 3). Routers in the IOAM > domain > > >>>>>>>> should be IOAM capable. And IMHO, we should add a statement to > > >>>>>>>> draft-ioametal-ippm-6man-ioam-ipv6-deployment that an > implementation > > >>>>>>>> of IOAM MUST ensure "C1". > > >>>>>>>> > > >>>>>>>> * That said, there can be situations, where C1 cannot be > achieved, e.g.. > > >>>>>>>> consider a network which does ECMP scheduling based on packet > length. > > >>>>>>>> > > >>>>>>>> * What one could consider - and which is one suggested > deployment > > >>>>>>>> model > > >>>>>>>> - is that by default IOAM data fields are added to _all_ > customer > > >>>>>>>> packets. The decapsulating node would decide whether the IOAM > > >>>>>>>> information contained in a packet would be used (and exported) > or not. > > >>>>>>>> That way one would not need to deal with the situation that some > > >>>>>>>> traffic carries IOAM while other does not - and might thus be > treated > > >>>>>>>> differently. > > >>>>>>> > > >>>>>>> Yes, I think this is the only way. Is there a risk that > intermediate routers would not be IOAM capable? I think the C1 requirement > is really really hard to fulfil and I'm also afraid that adding the IOAM > header will actually make ECMP stop working on some platforms (because they > would not have the capability to look deep enough into the packet to find > L4 information, so it'll go back to 2 tuple ECMP instead of 5 tuple. > > >>>>>>> > > >>>>>>> But this question can only be answered by people with deep NPU > knowledge... > > >>>>>>> > > >>>>>>> .....FB2: Given that IOAM is a domain specific feature - I > expect that folks initially start to use it in domains (like e.g. a DC) > where all boxes are IOAM capable and can trace the packet appropriately - > or per Tom's note, can be configured so that one would do ECMP based on > addresses and flow-label. There are chips with pretty deep parsing > capability (up to a few hundred bytes). > > >>>>>>> > > >>>>>>>> ...FB: The comparison to MPLS is interesting. How often do MPLS > > >>>>>>>> packets leak and cause harm? For IOAM, > > >>>>>>>> draft-ioametal-ippm-6man-ioam-ipv6-options-02 proposes a > deployment > > >>>>>>>> model similar to what we do for MPLS: Unless an interface is > > >>>>>>>> explicitly configured for IOAM, packets with IOAM data fields > MUST be dropped. > > >>>>>>>> Hence leakage would only occur, if we have a clearly misbehaving > > >>>>>>>> router which violates this rule. Similar to you, I'd also > greatly > > >>>>>>>> appreciate any pointers to research on how common MPLS leaked > packets are. > > >>>>>>> > > >>>>>>> When it comes to "cause harm" I imagine there are (at least) two > ways to cause harm, one is privacy/secrecy/security loss and the other one > is actual operational loss. > > >>>>>>> > > >>>>>>> I know of bugs where labeled packets went the wrong way and > caused them to be lost, I've also seen bugs where bugs caused traffic to > "hop" between VRFs in MPLS VPN (or to "global" VRF). I don't have numbers > on this though. > > >>>>>>> > > >>>>>>> Depending on the deployment scenario, it might make sense to > make IOAM packets not valid for non-IOAM aware devices (basically encap > entire packet/payload), but that might be a problem for intermediate > non-IOAM nodes then. This would affect the ECMP requirement. I can see > cases where one would operationally turn on IOAM for some customers traffic > and then see the problem go away because now ECMP changed. > > >>>>>>> > > >>>>>>>> ...FB: One idea that Shwetha came up with to identify the > source AS of > > >>>>>>>> a leaked packet, would be to add a new new IOAM E2E option - as > > >>>>>>>> proposed in section 5.1.1 bullet 2 of > > >>>>>>>> draft-ioametal-ippm-6man-ioam-ipv6-deployment-01. > > >>>>>>> > > >>>>>>> Yes, that'd solve that problem. > > >>>>>>> > > >>>>>>> How much has the silicon people been involved so far in the > design of the headers? What is the current thinking of amount of data going > into the IOAM header? Considering things like trace options etc it seems to > me the header can grow quite large? To satisfy the ECMP requirement what > about putting the IOAM information as a trailer behind the regular payload? > Or is there a problem for the hw to manipulate information that far into > the packet (I also imagine this will considerably lower the forwarding > performance of IOAM packets on IOAM aware platforms). > > >>>>>>> > > >>>>>>> .....FB2: There are quite a few folks with hardware background > that co-author the IOAM drafts. Parsing capability differs between chips, > as does the ability to deal with new/flexible headers and the ability to > modify data in the extension headers. So the unfortunate answer to that > question is "it depends" (what information do you gather, how large is your > domain, what are the capabilities of your hardware/software forwarder, > etc.), but I do expect that for specific deployment domains (e.g. DC, > Enterprise) - but also for overlay networks / VPNs - we'll see an > increasing amount of chips that are well suited for processing large > extension header. > > >>>>>>> > > >>>>>>> Cheers, Frank > > >>>>>>> > > >>>>>>> -- > > >>>>>>> Mikael Abrahamsson email: swmike@swm.pp.se > > >>>>>>> > > >>>>>>> _______________________________________________ > > >>>>>>> ippm mailing list > > >>>>>>> ippm@ietf.org > > >>>>>>> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&data=02%7C01%7Cgbarak%40mellanox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636898960379485833&sdata=VjZ1PiwifYGCf159je0yef3BJFz6AQNNAtkgmAMDFKM%3D&reserved=0 > > >>>>>>> _______________________________________________ > > >>>>>>> ippm mailing list > > >>>>>>> ippm@ietf.org > > >>>>>>> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&data=02%7C01%7Cgbarak%40mellanox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636898960379485833&sdata=VjZ1PiwifYGCf159je0yef3BJFz6AQNNAtkgmAMDFKM%3D&reserved=0 > > >>>>>>> > -------------------------------------------------------------------- > > >>>>>>> IETF IPv6 working group mailing list > > >>>>>>> ipv6@ietf.org > > >>>>>>> Administrative Requests: > https://www.ietf.org/mailman/listinfo/ipv6 > > >>>>>>> > -------------------------------------------------------------------- > > >>>>>> > > >>>>>> _______________________________________________ > > >>>>>> ippm mailing list > > >>>>>> ippm@ietf.org > > >>>>>> https://www.ietf.org/mailman/listinfo/ippm > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>> > > >>>> > > >>>> > > >>> > > >> > > >> > > >> > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- >
- v6 option types for IOAM data fields Frank Brockners (fbrockne)
- Re: v6 option types for IOAM data fields C. M. Heard
- RE: v6 option types for IOAM data fields Frank Brockners (fbrockne)
- Re: v6 option types for IOAM data fields Mark Smith
- RE: v6 option types for IOAM data fields Frank Brockners (fbrockne)
- Re: v6 option types for IOAM data fields Mark Smith
- Re: v6 option types for IOAM data fields Tom Herbert
- RE: v6 option types for IOAM data fields Frank Brockners (fbrockne)
- Re: v6 option types for IOAM data fields Mark Smith
- RE: v6 option types for IOAM data fields Frank Brockners (fbrockne)
- Re: v6 option types for IOAM data fields Tom Herbert
- RE: v6 option types for IOAM data fields Frank Brockners (fbrockne)
- Re: v6 option types for IOAM data fields Tom Herbert
- RE: v6 option types for IOAM data fields Frank Brockners (fbrockne)
- RE: v6 option types for IOAM data fields Frank Brockners (fbrockne)
- draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 … Mark Smith
- Re: draft-ioametal-ippm-6man-ioam-ipv6-deployment… Rajiv Asati (rajiva)
- RE: draft-ioametal-ippm-6man-ioam-ipv6-deployment… Frank Brockners (fbrockne)
- Re: v6 option types for IOAM data fields Tom Herbert
- RE: v6 option types for IOAM data fields Frank Brockners (fbrockne)
- RE: draft-ioametal-ippm-6man-ioam-ipv6-deployment… Frank Brockners (fbrockne)
- RE: draft-ioametal-ippm-6man-ioam-ipv6-deployment… Mikael Abrahamsson
- RE: draft-ioametal-ippm-6man-ioam-ipv6-deployment… Frank Brockners (fbrockne)
- RE: draft-ioametal-ippm-6man-ioam-ipv6-deployment… Mikael Abrahamsson
- Re: draft-ioametal-ippm-6man-ioam-ipv6-deployment… Tom Herbert
- Re: draft-ioametal-ippm-6man-ioam-ipv6-deployment… Mikael Abrahamsson
- RE: draft-ioametal-ippm-6man-ioam-ipv6-deployment… Frank Brockners (fbrockne)
- Re: draft-ioametal-ippm-6man-ioam-ipv6-deployment… Tom Herbert
- 答复: draft-ioametal-ippm-6man-ioam-ipv6-deployment… Pengshuping (Peng Shuping)
- RE: draft-ioametal-ippm-6man-ioam-ipv6-deployment… Barak Gafni
- RE: draft-ioametal-ippm-6man-ioam-ipv6-deployment… Pengshuping (Peng Shuping)
- Re: draft-ioametal-ippm-6man-ioam-ipv6-deployment… Tom Herbert
- Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-dep… Jai Kumar
- Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-dep… Tom Herbert
- Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-dep… Jai Kumar
- Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-dep… Tom Herbert
- Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-dep… Jai Kumar
- Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-dep… Jai Kumar
- Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-dep… Tom Herbert
- Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-dep… Jai Kumar
- Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-dep… Tom Herbert
- Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-dep… Mark Smith
- Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-dep… Jai Kumar
- Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-dep… Tom Herbert
- Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-dep… Jai Kumar
- Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-dep… Tom Herbert
- Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-dep… Jai Kumar
- Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-dep… Tom Herbert
- Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-dep… Jai Kumar
- Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-dep… Mark Smith
- Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-dep… Tom Herbert