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