Re: [ippm] Comment on draft-ietf-ippm-ioam-ipv6-options-00
"Frank Brockners (fbrockne)" <fbrockne@cisco.com> Wed, 20 November 2019 02:39 UTC
Return-Path: <fbrockne@cisco.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2BDB1201E0 for <ippm@ietfa.amsl.com>; Tue, 19 Nov 2019 18:39:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=GlCKAf2Q; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=SRj0mOQQ
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 051FIxZbb7bq for <ippm@ietfa.amsl.com>; Tue, 19 Nov 2019 18:39:47 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E55F1201EF for <ippm@ietf.org>; Tue, 19 Nov 2019 18:39:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14098; q=dns/txt; s=iport; t=1574217587; x=1575427187; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=gzKkUdxFAlaxlDHXbgxSYN20ZDeuEc2sRbyhzkx0XWs=; b=GlCKAf2QIh9o5LWQQ1d4KLC7MO/SH1JyUriuJAsN9p7pB/zHkQSql4Cv 0Ly3pEH9opgQArwSe0I2lK5XQcB41mhmmyTRwn+hyBfS7j7sqOL8TkCQ/ unTYF817mKsMndBhqXe4RVEAIIM12oivYyZncwRkWUtRdEWq0lved76TY Q=;
IronPort-PHdr: 9a23:wbbiwx1N5ONA2wDCsmDT+zVfbzU7u7jyIg8e44YmjLQLaKm44pD+JxKGt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSwdDjMwXmwI6B8vQB0fhK/XpaSESF8VZX1gj9Ha+YgBY
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DfAQA3p9Rd/51dJa1lGwEBAQEBAQEFAQEBEQEBAwMBAQGBfoFLUAVsWCAECyqEKoNGA4p0gXZomACCUgNUCQEBAQwBARgLCgIBAYRAAheCDiQ4EwIDDQEBBAEBAQIBBQRthTcMhVEBAQEBAwEBEBERDAEBJQQDCwELBAIBCBEEAQEBAgIZDQICAiULFQgIAgQOBQgagwGCRgMuAQIMpjYCgTiIYHWBMoJ+AQEFhQ4YghcDBoEOKIwVGIFAP4ERRoJMPoJiAQGBOimDDjKCLI0Egw+PDY8NCoIrhxqFJokqgj6MIoZ1hDyWBnqRUAIEAgQFAg4BAQWBaSKBWHAVO4JsUBEUkRoMF4NQhRSFP3SBKItRgWJeAQE
X-IronPort-AV: E=Sophos;i="5.69,220,1571702400"; d="scan'208";a="671085603"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Nov 2019 02:39:42 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id xAK2dgAe032435 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Nov 2019 02:39:43 GMT
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 19 Nov 2019 20:39:42 -0600
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 19 Nov 2019 20:39:42 -0600
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 19 Nov 2019 21:39:41 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=frf/67w1EaWmNOdabMWhhA/qzuf/B/PSrveDFNyH5XCDIANslG6clLXm+N91I7bETn+ddp5UdEJ9FOswiBNjWfOXQ/JkWdKVm1Zkj4FIS70txEpfNfOSGoR1P5k7u7MXZN2O/qk8ibsxoBxOVckL/8KWl9QmHKYyRIbuVE1+v1UgVzFDqpVM+eN7cR9ZNV+eo+obJE0xDmBXV6tKaJnlDagdFoPy8IZL2GlKckgELlswFQnaLV0oqxRqWY01Eniok5zi9NCcgW1a4sCCNdVuv9viZc+fPGvtafjQW2BI6A04hadH4W9jvghfkGMvFEAST5ur0hUtoGzTvI1BI0ZUnA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gzKkUdxFAlaxlDHXbgxSYN20ZDeuEc2sRbyhzkx0XWs=; b=NVOvuyCkde+Go582w9Gar8tHWydc+BIoHrQe+x3eOZLesW2uRM2t4BsCqann7WIgDufSMTHFk560pUfI0evOSyOA0/Z1Wh7keA/5j1K2sgdZJiZeSCh0VY9geOKHTZAH3QSsLkHJZubXO8sOXhL8iyuKXdj67Hh+FLTJrT2HWGKYuT8NUoLHe/YF8W27W51fhMG49b2mbtEWknt3Uy6H2IwlTDs4WSTO4VSHAYbW3wXTAlCVWaYgSsi57vexaZIJfTSdxlk7WCDwugEggnYzh5z/jRahSm6XmvFXZkWneNJoa/fZMUBHFeiRvjUSAW63jw4w+1XyfBAfCmuC1ckraA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gzKkUdxFAlaxlDHXbgxSYN20ZDeuEc2sRbyhzkx0XWs=; b=SRj0mOQQTZNOZNJKYpLS8VGATEUTg4SujIJBPcwIoGJcsLRoIdfL2yHIS2Aj5Nl9uRKz8omhytEuxqWIpZdmrGHzji4RtWCf9yYni2rbOAPQuXg/F0tBDKPJFUNpsegvMo1grW1h6HfIxB2q6AMkYSqjMCEY3gzfituBUsCovas=
Received: from BYAPR11MB2584.namprd11.prod.outlook.com (52.135.228.31) by BYAPR11MB3208.namprd11.prod.outlook.com (20.177.184.203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.30; Wed, 20 Nov 2019 02:39:40 +0000
Received: from BYAPR11MB2584.namprd11.prod.outlook.com ([fe80::854c:63ec:ff6f:7e8a]) by BYAPR11MB2584.namprd11.prod.outlook.com ([fe80::854c:63ec:ff6f:7e8a%6]) with mapi id 15.20.2451.031; Wed, 20 Nov 2019 02:39:40 +0000
From: "Frank Brockners (fbrockne)" <fbrockne@cisco.com>
To: Tom Herbert <tom@quantonium.net>
CC: "xiao.min2@zte.com.cn" <xiao.min2@zte.com.cn>, "ippm@ietf.org" <ippm@ietf.org>
Thread-Topic: [ippm] Comment on draft-ietf-ippm-ioam-ipv6-options-00
Thread-Index: AQHVnc+mkUUodDJUYkqiPluxlzl7UaeR2DNAgAAOdYCAAAZMkIAAufeAgACBNTCAAAvsAIAAJaZQ
Date: Wed, 20 Nov 2019 02:39:40 +0000
Message-ID: <BYAPR11MB2584F24B380D4415CBFA1BEFDA4F0@BYAPR11MB2584.namprd11.prod.outlook.com>
References: <201911181318081812271@zte.com.cn> <BYAPR11MB2584C26544D5CC6DEE766FC7DA4C0@BYAPR11MB2584.namprd11.prod.outlook.com> <CAPDqMeqzB-PzHJM3MDH9oubpo3f23T7+ZGqv3daezxCq5c941A@mail.gmail.com> <BYAPR11MB258404FD5756841E455C13D4DA4C0@BYAPR11MB2584.namprd11.prod.outlook.com> <CAPDqMerT80akH__AkCpvr_5A3Ww-1_NPX9qXGdP8ay87O6bDpA@mail.gmail.com> <BYAPR11MB25843C29CD2476E4FBCE72DBDA4C0@BYAPR11MB2584.namprd11.prod.outlook.com> <CAPDqMeqOqeqkOzgpw0YZMAufSfjDGzvvBVMVRDV2TNK3sjzUgA@mail.gmail.com>
In-Reply-To: <CAPDqMeqOqeqkOzgpw0YZMAufSfjDGzvvBVMVRDV2TNK3sjzUgA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=fbrockne@cisco.com;
x-originating-ip: [2001:420:c0c0:1005::5a]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: aa1a150a-102c-450a-603b-08d76d62e4a6
x-ms-traffictypediagnostic: BYAPR11MB3208:
x-microsoft-antispam-prvs: <BYAPR11MB32089CCC0F332FB94076119FDA4F0@BYAPR11MB3208.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 02272225C5
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(136003)(39860400002)(346002)(396003)(376002)(189003)(13464003)(199004)(81166006)(46003)(6246003)(81156014)(14444005)(256004)(6116002)(486006)(74316002)(6916009)(64756008)(305945005)(66446008)(316002)(446003)(33656002)(99286004)(52536014)(66556008)(66946007)(5660300002)(966005)(478600001)(25786009)(7736002)(14454004)(2906002)(8676002)(8936002)(66476007)(76116006)(6436002)(54906003)(11346002)(476003)(229853002)(186003)(66574012)(71200400001)(71190400001)(4326008)(86362001)(76176011)(6506007)(53546011)(6306002)(102836004)(9686003)(55016002)(7696005); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3208; H:BYAPR11MB2584.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: q+IW6whalWz2Tg1UN1xVvKSnYdBej0jnOE0vbduESSzUtFYp6t78Rfgvtd7IBUaxvfmqeEVgafaHvnQyeqke8vvrnTm9yO0dvBRmObiPpKiINVgcc8QQN91qmGhnT6lC1D/FXthZ+7ogFK69fe+rCDZHAAZ+vdMBkvrcZFmdz8/rLzba0VfSjljDUdEreO9C+vMIfyYkrEywER0f2gi8p3b2kD3IJzv1vfAkR3eRUb/X8BJtX4eTBDYo4160L2fAn8ee2muDq86Vvvi/3hTjj0EoXpAAUOoOsmTGD7LlYQY1jsEWbDgDfr79uQOMUB88GbUTo1smqwnLrXaVsZsaLsU/zRfMnudeiAcZBqm1ER5PqiHHgqlTBgSepSPh9BEou1x59l8ceuVVznw6+b5dcabi3ACLtXQ0FTBpJiM7HvfdOwsp5W08E6o5idqLe9gV
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: aa1a150a-102c-450a-603b-08d76d62e4a6
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Nov 2019 02:39:40.4077 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Ki079C2C128elBdwiyLE6u4aFwAcnJjje0WliNW0BgDmGf8dAPAjl4s5hUOS9eKIi9ooz1NZhrEDrbHxuedUDw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3208
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com
X-Outbound-Node: rcdn-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/FqUJDvFmcdmlHaLVzlsyG64csrM>
Subject: Re: [ippm] Comment on draft-ietf-ippm-ioam-ipv6-options-00
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Nov 2019 02:39:52 -0000
Tom, > -----Original Message----- > From: Tom Herbert <tom@quantonium.net> > Sent: Mittwoch, 20. November 2019 08:17 > To: Frank Brockners (fbrockne) <fbrockne@cisco.com> > Cc: xiao.min2@zte.com.cn; ippm@ietf.org > Subject: Re: [ippm] Comment on draft-ietf-ippm-ioam-ipv6-options-00 > > On Tue, Nov 19, 2019 at 3:51 PM Frank Brockners (fbrockne) > <fbrockne@cisco.com> wrote: > > > > Tom, > > > > > -----Original Message----- > > > From: Tom Herbert <tom@quantonium.net> > > > Sent: Dienstag, 19. November 2019 23:52 > > > To: Frank Brockners (fbrockne) <fbrockne@cisco.com> > > > Cc: xiao.min2@zte.com.cn; ippm@ietf.org > > > Subject: Re: [ippm] Comment on draft-ietf-ippm-ioam-ipv6-options-00 > > > > > > On Mon, Nov 18, 2019 at 8:49 PM Frank Brockners (fbrockne) > > > <fbrockne@cisco.com> wrote: > > > > > > > > Tom, > > > > > > > > > > > > > -----Original Message----- > > > > > From: Tom Herbert <tom@quantonium.net> > > > > > Sent: Dienstag, 19. November 2019 12:24 > > > > > To: Frank Brockners (fbrockne) <fbrockne@cisco.com> > > > > > Cc: xiao.min2@zte.com.cn; ippm@ietf.org > > > > > Subject: Re: [ippm] Comment on > > > > > draft-ietf-ippm-ioam-ipv6-options-00 > > > > > > > > > > On Mon, Nov 18, 2019 at 7:47 PM Frank Brockners (fbrockne) > > > > > <fbrockne@cisco.com> wrote: > > > > > > > > > > > > Hi Xiao, > > > > > > > > > > > > > > > > > > > > > > > > thanks for following up. Apparently the behavior described in > > > > > > draft-ietf-ippm-ioam-ipv6-options-00 isn’t a bug – as we > > > > > > speculated in the IPPM WG meeting yesterday, but the desired > > > > > > behavior that we arrived at after WG discussions in 6man and > > > > > > with several > > > IPv6 experts. > > > > > > See > > > > > > https://github.com/inband- > > > > > oam/ietf/commit/48175cf89de6369a4d01017ec80c > > > > > > 07b34f57f17c#diff-803b63dbe26303f504708318e255d884 (“Don't > > > > > > forward an IOAM packet unless configured to do so.”) > > > > > > > > > > > > This behavior for IPv6 is to ensure that packets with IOAM do > > > > > > not accidentally > > > > > leak from a domain that employs IPv6. > > > > > > > > > > > > This also means for IPv6, things are more constrained than > > > > > > what is stated in > > > > > the more generic draft-ietf-ippm-ioam-data-08. > > > > > > > > > > > Frank, > > > > > > > > > > Per the draft-ietf-ippm-ioam-ipv6-options-00 the act bits are 00 > > > > > which means "skip over this option and continue processing the > > > > > header". So if a router doesn't support IOAM, I believe other > > > > > act bits like maybe > > > > > 01 would be necessary to enforce the rule of “Don't forward an > > > > > IOAM packet unless configured to do so.” Of course, nodes may > > > > > also ignore HBH options completely per RFC8200 which means even > > > > > such packets might be forwarded out of the domain anyway. > > > > > > > > ... the current text is a for a more specific case, i.e. you have > > > > a router that > > > *does* understand IOAM and receives a packet with IOAM on an > > > interface that is not configured for IOAM. > > > > > > But the draft says "This ensures that IOAM data does not > > > unintentionally get forwarded outside the IOAM domain.", these > requirements don't do that. > > > > ... FB: If everything is properly setup, packets with IOAM data fields should > never leave the IOAM domain. > > Frank, > > If everything were set up correctly one would expect that the source would only > set IOAM in the packet if it knows that the destination is in the domain. From > that POV the purpose of an egress firewall is to protect against misconfiguration > or bugs. > > > Having a default of "drop" with the need to explicitly configure an "allow" > reduces the potential of errors. > > Which means we should soften the statement, given that it does not "ensure" > that bad things don't happen - but it does try to help avoid bad things happening. > > An explicit firewall at the edge could just as easily and more completely enforce > the isolation. Per the current draft requirements, even non-edge routers need to > act as firewalls for IOAM. ... not sure whether I'd call the function "drop packets of a specific type unless configured to accept them" a firewall. Would you call a router that drops v6 on an interface unless explicitly configured to forward v6 on an interface a firewall? Anyway - I think we agree on what behavior we refer to, hence no need to argue nomenclature. > > > > > > > > > I see another issue, the option may be in a Destination Options > > > header. So in order for a router to detect presence of the IOAM > > > option it would need to examine the Desintation Option while the > > > packet is inflight, but that prohibited by RFC8200: "Extension > > > headers (except for the Hop-by-Hop Options header) are not > > > processed, inserted, or deleted by any node along a packet's delivery path..." > > > > ...FB: Hmmm - I'm not following. Why would a router (i.e. transit node) look at > DO? The text does not say that anywhere. > > Per the draft: "IOAM data fields are encapsulated in "option data" > fields of two types of extension headers in IPv6 packets - either Hop-by-Hop > Options header or Destination options header." > > -and- > > "Unless a particular interface is explicitly enabled (i.e. explicitly > configured) for IOAM, a router MUST drop packets which contain extension > headers carrying IOAM data-fields." > > Putting these two statements together means that a router MUST drop packets > with a Destination Options header that carried IOAM data-fields regardless of > whether the packet is addressed to the router. If the intent is that the router > only drops for HBH then the requirement should read "...a router MUST drop > packets which contain a Hop-by-Hop extension header carrying IOAM data- > fields." ... point taken. We'll improve the language in the next revision to ensure that things cannot be misread - which is why the whole discussion started here in the first place. Thanks, Frank > > Tom > > > If you are an IOAM encap/decap node (host or tunnel endpoint), you'd deal > with DO and HbyH - and the text means: Ignore those on interfaces which aren't > enabled for IOAM. > > If you are an IOAM transit node, you'd deal with HbyH - and the text again > means: Ignore those on interfaces which aren't enabled for IOAM. > > > > > > > > > The conclusion from earlier discussions was to drop the packet - > > > > per the > > > current text. This leaves default processing of unknown option types > > > untouched > > > - i.e. processing would happen per RFC 8200. > > > > > > Yes, packet should be dropped at the domain edege, but that is a > > > firewall functionality not router functionality. If we start adding > > > requirements to routers to drop traffic on the basis of inspecting > > > content not normally required for routing, then this will create a > > > avalanche of router requirements for each type of limited domain. > > > > ...FB: Per what I said above, we don't ask the router to inspect anything that > the router would look at in any case. > > If you believe that the behavior of "explicitly enable an interface for IOAM" - > i.e. ask for explicit config - does not add any benefits, and others feel the same > way, we can drop that requirement from the spec again. It adds to configuration > complexity - so unless we feel it adds a benefit, we should get rid of it. The > earlier conversation we had on the topic concluded that it would add a benefit - > which is why the text is there. > > > > Cheers, Frank > > > > > Clearly packets with SRH need to be dropped at edge, as do packets > > > with private addresses, and there will no doubt be other cases. All > > > of these fall under the auspices of firewalls at the edge of the domain, not > routers within the domain. > > > Segement rouitng handles this properly as filtering packets with SRH > > > at edge is required. > > > > > > Tom > > > > > > > > > > > > > > Frank > > > > > > > > > > > > So trying to guarantee packets won't be forwarded > > > > > out of the domain at all edge routers may be a futile effort. An > > > > > alternative would be that the source SHOULD only use IOAM when > > > > > it knows the destination is in the domain, and a firewall MAY be > > > > > applied at the domain edge to drop packets with IOAM. > > > > > > > > > > Tom > > > > > > > > > > > > > > > > > > > > > > > Cheers, Frank > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: ippm <ippm-bounces@ietf.org> On Behalf Of > > > > > > xiao.min2@zte.com.cn > > > > > > Sent: Montag, 18. November 2019 13:18 > > > > > > To: ippm@ietf.org > > > > > > Subject: [ippm] Comment on > > > > > > draft-ietf-ippm-ioam-ipv6-options-00 > > > > > > > > > > > > > > > > > > > > > > > > Hi Frank, > > > > > > > > > > > > > > > > > > > > > > > > Repeat what I said on the mic this morning as below. > > > > > > > > > > > > > > > > > > > > > > > > In section 3 of draft-ietf-ippm-ioam-ipv6-options-00 it says: > > > > > > > > > > > > "Unless a particular interface is explicitly enabled (i.e. > > > > > > explicitly > > > configured) > > > > > for IOAM, a router MUST drop packets which contain extension > > > > > headers carrying IOAM data-fields." > > > > > > > > > > > > But in section 4.4 of draft-ietf-ippm-ioam-data-08 it says: > > > > > > > > > > > > "If not all nodes within a domain are IOAM capable, IOAM > > > > > > tracing information > > > > > (i.e., node data, see below) will only be collected on those > > > > > nodes which are IOAM capable. Nodes which are not IOAM capable > > > > > will forward the packet without any changes to the IOAM-Data-Fields." > > > > > > > > > > > > It seems they're not in alignment. > > > > > > > > > > > > > > > > > > > > > > > > Best Regards, > > > > > > > > > > > > Xiao Min > > > > > > > > > > > > _______________________________________________ > > > > > > ippm mailing list > > > > > > ippm@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/ippm
- [ippm] Comment on draft-ietf-ippm-ioam-ipv6-optio… xiao.min2
- Re: [ippm] Comment on draft-ietf-ippm-ioam-ipv6-o… Frank Brockners (fbrockne)
- Re: [ippm] Comment on draft-ietf-ippm-ioam-ipv6-o… Tom Herbert
- Re: [ippm] Comment on draft-ietf-ippm-ioam-ipv6-o… Frank Brockners (fbrockne)
- Re: [ippm] Comment on draft-ietf-ippm-ioam-ipv6-o… Tom Herbert
- Re: [ippm] Comment on draft-ietf-ippm-ioam-ipv6-o… Frank Brockners (fbrockne)
- Re: [ippm] Comment on draft-ietf-ippm-ioam-ipv6-o… Tom Herbert
- Re: [ippm] Comment on draft-ietf-ippm-ioam-ipv6-o… xiao.min2
- Re: [ippm] Comment on draft-ietf-ippm-ioam-ipv6-o… Frank Brockners (fbrockne)