Re: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifit-04.txt (11/1/2020 to 11/16/2020)

"Ketan Talaulikar (ketant)" <ketant@cisco.com> Mon, 16 November 2020 07:39 UTC

Return-Path: <ketant@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D776C3A14F4; Sun, 15 Nov 2020 23:39:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.597
X-Spam-Level:
X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=UsUp1skY; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=bFtDIyBu
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 Biqhc4Kx5wAZ; Sun, 15 Nov 2020 23:39:13 -0800 (PST)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 564433A0816; Sun, 15 Nov 2020 23:39:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28616; q=dns/txt; s=iport; t=1605512353; x=1606721953; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=wodjsNmFuTX8QiLkEdqNh2R81igUNVZUgEYEqqo/dHs=; b=UsUp1skYc66DQC+Q9ZxEewbHEYT/714PHaSH+jXMEwXq0uzJUa2+vGjF 8RjsmsYwc1dNqtSmMUA6imSG7XEU/uqXxRQ1g4q7n8s/+W2GCQ9ru69Fx 63ayG9OQWUz58lgxyYLfzv5pucwMjQGQ/fvBCadpvddFH87wP9dxE91YR Q=;
X-IPAS-Result: A0AhBQCDKrJffYgNJK1iHAEBAQEBAQcBARIBAQQEAQFAgU+BIy8jLntZLy6IBQONV4EFl36BQoERA1QLAQEBDQEBJQgCBAEBhEoCgh4CJTgTAgMBAQEDAgMBAQEBBQEBAQIBBgQUAQGGPAyFcgEBAQEDEgsQEwEBKQ4BDwIBCBEEAQEhAwQHMhQJCAEBBAENBQgagwWBflcDLgEOoS0CgTyIaHSBNIMEAQEFgUdBgnoYghADBoE4gnOKTRuBQT+BEUOBUUkHLj6BBIFZAQECAQGBITwrCYMUgiyQLw+KSIwOkR4Kgm2JD4Zki0SDGYoWlEqHXIt2in2SboJoAgQCBAUCDgEBBYFrIYFZcBWDJFAXAg2OHwwXFIM6hRSFRHQ3AgYKAQEDCXyLCC2CFwEB
IronPort-PHdr: 9a23:X6l/Jx9cScTC/f9uRHGN82YQeigqvan1NQcJ650hzqhDabmn44+7ZRKN5ehkk1LIG47c7qEMh+nXtvXmXmoNqdaEvWsZeZNBHxkClY0NngMmDcLEbC+zLPPjYyEgWsgXUlhj8iK7LEFKFce4bFrX8TW+6DcIEUD5Mgx4bu3+Bo/ViZGx0Oa/s53eaglFnnyze7R3eR63tg7W8MIRhNhv
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.77,481,1596499200"; d="scan'208,217";a="590923293"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 Nov 2020 07:39:12 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AG7dBpQ008083 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 16 Nov 2020 07:39:12 GMT
Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 16 Nov 2020 01:39:11 -0600
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 16 Nov 2020 01:39:11 -0600
Received: from NAM11-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 16 Nov 2020 01:39:11 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XjcBjKRmflG/qUP/0MQVguOKUug6ydzYmeKD7AM7AWp7R32NxuN7azw+QB8oQRGTmCOBvG7S1ZTdSYM/k88x2ZWZipOk9JKFlyh/4sDrXVuxnK45MInIyMWQ7uEE5vf5lzKyRTRi2JtXBeF0gKsfr87BPdi6EVyRZmdN9Ecrv6jEJFFM4MgQYQbDOPJHJLFlibU9uXYV55BwIREEEXTVTnwkGO2Ijxa3wKNoR2sty3XCuuQqbs1k3bzzNpnMXwvPMWx0TqofNYZPu3VgXjJs9FRfeVDGyjzv6ScpN9pCtly4WE/4IFIyW/fGIadn8yv4etTuFbvF6HhQpPBoJ0E/9g==
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=VYFsXYd6fGxIt0CO4xLn+ca3s2TRASXfCEadqeXqjao=; b=NgBV9nQRWkd2Yek3W67/qD5ivfun4cvMXlP7AynYyIF9dYLBZ5Q+9eiRS52Gv8YlAb2Tabzcu1PJ/yfjO/JpUlAIMtLF8CKwQbYJhTva+pPt1Jg+hUQkSWCNx0X+gOjbv9ncugSnwQUMaN7ENSOHqSCy1c6llAcbAcAjmnQti1VeMdRSemKEtBYLoXuAjgWQHZLG8aVbIDpRY/s9G6SG5DvIOmq6+0utNPxLptu71DpQr6GvwH0gXt+8WJ87BXcdp4ghvkzoDN7E1RqCwxljZnh77K08cwIKGZ16Hq+VzRZO7HbElgARqUZ3pVXQHDM9x6BEcs9ZOPQpZeQKQJd7gA==
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=VYFsXYd6fGxIt0CO4xLn+ca3s2TRASXfCEadqeXqjao=; b=bFtDIyBu1nFUzQR3Z1dT//ulFZbPKWR/+lnwdn3SY/gD+b6nq5X9tSBe+jB3/fgh3vJ2zOdiyN50z+6h/zi5JMCKWL0xZrX51ishsMYr/sOQtx6Phu8XwK+FjPRGgu/sBfVkdq73UoA3fnL/MEytVFj66Do0rzCJ6ZjuxpQi6aQ=
Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MWHPR11MB1406.namprd11.prod.outlook.com (2603:10b6:300:23::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3564.28; Mon, 16 Nov 2020 07:39:10 +0000
Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::d4d5:97f0:17b5:2f77]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::d4d5:97f0:17b5:2f77%5]) with mapi id 15.20.3564.028; Mon, 16 Nov 2020 07:39:09 +0000
From: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
To: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>, Susan Hares <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>
CC: "spring@ietf.org" <spring@ietf.org>, "spring-chairs@ietf.org" <spring-chairs@ietf.org>
Thread-Topic: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifit-04.txt (11/1/2020 to 11/16/2020)
Thread-Index: Adaw2PtgBctpKEXkRb++HOEf6MFzKAAXn49QAhq0TSAAkCn8MAABrv4Q
Date: Mon, 16 Nov 2020 07:39:09 +0000
Message-ID: <MW3PR11MB457061E12701246675DBD374C1E30@MW3PR11MB4570.namprd11.prod.outlook.com>
References: <055301d6b0dc$f84da4a0$e8e8ede0$@ndzh.com> <1057d25807be466c97af61844fddfa35@huawei.com> <MW3PR11MB4570F61EF1B19F636AFD671DC1E60@MW3PR11MB4570.namprd11.prod.outlook.com> <832cd20c50a941e19d06e41b339a6c8c@huawei.com>
In-Reply-To: <832cd20c50a941e19d06e41b339a6c8c@huawei.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2405:201:1006:a85b:5da7:1662:f466:12e3]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 87e4c56e-2620-499e-2475-08d88a02b4bd
x-ms-traffictypediagnostic: MWHPR11MB1406:
x-microsoft-antispam-prvs: <MWHPR11MB14061FCB6B35229823B3A632C1E30@MWHPR11MB1406.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 3CGAWxEP0Z/zVsUM1i936lCRVQIyDcFVHVLO3Iq7bMZLazRzBp7ddMZq2r/MbDRiW62eYw5Jr+5Gm5gxW8Llp8SG4qGWNqRo+SK8ebjxzlTGo1GvcDyO19MEGJPVut4T12kPLPaEL6II6CLF9aPoRczLBMaQp9ImpYmTWdhRK1ct8+JNoh22wqMb5Tcs0vIwkaLx9hHgASIANRIEdTbduw/uHV5950vYFhGvyhbQa48l9HL585pOejawXhyzxAgGKhNUeIIcU2sNbMNjwW23Rr0gYouT8dqOO7IP+d9sBLENjNgGeB/lfbLDKOmr6EzV0sbC12Yz+fHqddI/GcgIr+gFqUIUlfg7lo0IQj0yZn4Df8vRwVUh24hNWe8Li7uX+9KHM+P/ejjK7T1c6Jn/bg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(136003)(366004)(376002)(396003)(346002)(166002)(52536014)(83380400001)(86362001)(55016002)(8676002)(5660300002)(6506007)(53546011)(110136005)(9686003)(316002)(7696005)(54906003)(186003)(64756008)(66476007)(66556008)(71200400001)(66946007)(76116006)(66446008)(2906002)(33656002)(966005)(8936002)(4326008)(478600001)(9326002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: etVDHxjk5yQxqNjJ65ICtmbGJz7tGPdM6Q83BKq3MXpEn2U0dwZPxnrLmCd79CaXPwhx2uDIm1jRIQJLmqjx+RBiIRH95NcDoEXvJB0XBywB6UIL7asw3QTIV1eIbTbVFR+6+xaHvIUBdR0PugFUALVPKyBG5lCiuzET1qhkehWmt6aamvoICPOn+VxoEDeg8VoxOgaZt00cSu5pXvyzL+ZXe+VFiKIK3PSpIafMCOACVqUZVweOC+x61HywK1Y/TaNBzmtipw7W+1mye1piOT9sIIgVojK6iZyIV1CqLe4n3MykRCkq4vhxybbTCTJpct/Eg2rGNNhe7/DDN9gDqDXkudk5QNgKGr3mwxEfNhAqW6h8JPgmIs/pJwD6Kd+WTos0x/rxSGPsRojh3CM0DBR9VcwzWwOWXlCT4eTCmXOVypjTTH6aorGR97Gkgw9fBoGPcV1KvFShUHRZvs8AyIY09Gz5/hGu0bUMQo7REtdZMQrZoA20glODYYb+CxUFYJwZTuNaPrcbepN7EoMKhs9mpi3pgjHhXF0J5G85tuzlJlSosrqTq61kimB2WDbfT2f+5yEhQ91YIYsEBQiONt3tBijTbGk3M66igPUdVIksnOJZmO0/3XcT4BAaK+qr2i1zOEdaTYeUW7Va01HvHx9/aZeseJPmXD9AltnDftOGRSWyHgaCmQ4TxeUVrBTt4/XV9JTAZ690dxkIM/Z7G2MjvceAtJAqJdA7sqjurzoWF3+MWcQPiD+0Kb5ThSdDCHRpMsz0ovA5kCI3xUMqJlTs412MXDsXUbAAjogNot2eBPt119fl0dkiBXkzJ4YbaKbjaF3h1bwPVENGW44lEXAJJ2c3lKGDHdMEbeLStcYvn/f2ZvzTjF66rQatNDY8vyW7f/1+apjOUGf+XmENUtXeuZ2N8dutqcB85TSUsy2XOv5JaX7Qs3c7ObjMM1r7LospnIHDCW0T/VrYX9LMqw==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MW3PR11MB457061E12701246675DBD374C1E30MW3PR11MB4570namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MW3PR11MB4570.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 87e4c56e-2620-499e-2475-08d88a02b4bd
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2020 07:39:09.8632 (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: 0MfiHNU/6OQxQaE9ACiHj/4lzJ2uBdcUpdFIkqLfGBVG48d64rlLwAZt5NM4hI1Qlh4hMGERhTl855DQQpzGlA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1406
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com
X-Outbound-Node: alln-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/wOZJEq5W7gwlXK1KyS0TQR4XpAM>
Subject: Re: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifit-04.txt (11/1/2020 to 11/16/2020)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Nov 2020 07:39:17 -0000

Hi Giuseppe,

Thanks for your response. Perhaps my point was not clear and so let me please clarify.

I am seeing the IFIT signalling related drafts for BGP and PCEP (it was also there in LSR?) in their individual protocol working groups. While what these protocols are doing is only "carrying" (in case of BGP somewhat opaquely) the information and conveying it to the SR Policy Module (SRPM). The following may clarify the picture better : https://tools.ietf.org/html/draft-filsfils-spring-sr-policy-considerations-06#section-2

The key part of how this is handled by the SRPM, the related procedures and setup in the forwarding plane along with their applicability and any other considerations should be (IMHO) done in a Spring document. This is my suggestion and request to the authors - not to add all of this into an IDR document since that is not where you will find the right expertise to review these aspects.

Without that, it might seem like an uncoordinated protocol development effort for those of us who are not intimately aware of all the IFIT internals/details.

Rest, I will leave it up to the chairs of the WGs involved.

Thanks,
Ketan

From: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
Sent: 16 November 2020 12:42
To: Ketan Talaulikar (ketant) <ketant@cisco.com>; Susan Hares <shares@ndzh.com>; idr@ietf.org
Cc: spring@ietf.org
Subject: RE: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifit-04.txt (11/1/2020 to 11/16/2020)

Hi Ketan,
Thanks a lot for your revision.
My answers inline tagged as [GF]

Regards,

Giuseppe

From: Ketan Talaulikar (ketant) [mailto:ketant@cisco.com]
Sent: Friday, November 13, 2020 12:12 PM
To: Giuseppe Fioccola <giuseppe.fioccola@huawei.com<mailto:giuseppe.fioccola@huawei.com>>; Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>>; idr@ietf.org<mailto:idr@ietf.org>
Cc: spring@ietf.org<mailto:spring@ietf.org>
Subject: RE: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifit-04.txt (11/1/2020 to 11/16/2020)

Hi Giuseppe,

First of all, thanks for making the updates to the document to clarify the objective and applicability of IFIT and this draft extensions specifically to the SR Policy signalled by BGP. A good part of the puzzle is at least clearer to me now.

Sec 3 says (and I am trying to paraphrase here - so please correct me), that these IFIT attributes (new TLVs) are signalled via BGP along with the SR Policy Candidate Path to "enable IOAM and Alternate Marking" mechanisms for that SR Policy. This way all traffic steered over that SR Policy with have the IOAM and Alt Marking headers inserted on them.

[GF]: Yes, this is correct.

Is there a Spring WG document that describes the implications of actually how this would get applied to the SR Policy forwarding planes (SR-MPLS and SRv6) and what types of Steering would be possible to be used for such SR Policies (ref https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-09#section-8) ? E.g. if a packet is arriving at the headend with a stack of labels and gets steered via BSID into such an SR Policy where "IFIT is applied", how does that work?

[GF]: Good point, in the next revision we can add some considerations on the Steering into an SR Policy. This can be useful also for the data plane drafts. Regarding SRv6, the relevant documents are already adopted: draft-ietf-ippm-ioam-ipv6-options for IOAM and draft-ietf-6man-ipv6-alt-mark for AltMark. These Options are defined for IPv6 and can be used with any Routing Header (including SRH). For SR-MPLS the relevant documents (e.g. draft-gandhi-spring-ioam-sr-mpls) are still individual.


Sec 6 (SR Policy operations with IFIT Attributes) says the following:

The validation of the individual fields of the IFIT
   Attributes sub-TLVs are handled by the SRPM (SR Policy Module).

However, I am still missing a document that describes how these are actually "handled" by the SRPM?

[GF]: draft-ietf-idr-segment-routing-te-policy also mentions some high-level functionality of SRPM. I think we need to include more details in draft-qin-idr-sr-policy-ifit in order to describe the functionalities that are specific for IFIT (IOAM and AltMark).

I understand that there is a similar draft in PCE WG as well, but it is also missing this information.

[GF]: I can address this comment in both drafts.

My concern is that we have documents for the protocol signaling mechanisms for IFIT but I am not able to locate a document that describes how exactly this information is going to get used/applied by SRPM.

[GF]: Some details about the SRPM operation for IFIT could be added in this draft.

Please do point/clarify if I am missing something here.

Thanks,
Ketan

From: Idr <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>> On Behalf Of Giuseppe Fioccola
Sent: 02 November 2020 22:28
To: Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>>; idr@ietf.org<mailto:idr@ietf.org>
Subject: Re: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifit-04.txt (11/1/2020 to 11/16/2020)

Dear Susan, All,
I'm not aware of any IPR related to this draft. I also support its adoption as coauthor.

Best Regards,

Giuseppe


From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Monday, November 2, 2020 6:57 AM
To: idr@ietf.org<mailto:idr@ietf.org>
Subject: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifit-04.txt (11/1/2020 to 11/16/2020)

This begins a 2 week WG adoption call for draft-qin-idr-sr-policy-ifit-04.txt (11/2/2020 to 11/16/2020).

The draft can be accessed at:
https://datatracker.ietf.org/doc/draft-zhu-idr-bgp-ls-path-mtu/

The authors should provide IPR statements by 11/5/2020 so the IDR WG can consider the IPR status in their
decision.

This draft adds the IFIT sub-TLV to the BGP Tunnel Encaps attribute for the SR policy tunnel type. This sub-TLV is only valid for SR Policy tunnel types.  Within the IFIT  sub-TLV value field, 5 sub-TLVs may be included (4 for IOAM and 1 for Enhanced Alternate Marking).

The IDR co-chairs thank the authors for their patience.  The WG adoption call for this draft has been delayed by the process of switching shepherds for BGP Tunnel Encaps draft.  Many BESS and IDR drafts currently refer to the BGP tunnel encapsulation drafts.

In your review of this draft, please differentiate between the following:

  *   Support/rejection of In-situ Flow Telemetry (IFIT) as a IP routing technology,
  *   Support/rejection of alternate marking as a IP routing technology,
  *   Support/rejection of adding new sub-TLVS for SR Policy tunnel type of BGP Tunnel Encap Attribute, and
  *   Specific issues with the descriptions of these features in the draft.

Cheers, Susan Hares