Re: [mpls] Alvaro Retana's Discuss on draft-ietf-mpls-ri-rsvp-frr-07: (with DISCUSS and COMMENT)

Chandrasekar Ramachandran <csekar@juniper.net> Mon, 23 November 2020 05:20 UTC

Return-Path: <csekar@juniper.net>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52DCE3A0F41; Sun, 22 Nov 2020 21:20:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.2
X-Spam-Level:
X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=ysNbgILT; dkim=pass (1024-bit key) header.d=juniper.net header.b=Ww7zRNYl
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 kI-R_ac_1Jgl; Sun, 22 Nov 2020 21:20:45 -0800 (PST)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE9FE3A0F44; Sun, 22 Nov 2020 21:20:44 -0800 (PST)
Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 0AN5KRT2017536; Sun, 22 Nov 2020 21:20:43 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=lxdhutfZsHvp0gxIRKtouqJ2N+b6ZuiKwS8mpjN0TxY=; b=ysNbgILTRAnlszYjyywh7jLEYNaYBYXw4qjSpdbsMxCB/MYE8Anrl/uSuk8s7wSj8fo3 Otfer9cNJaKIfx+I/0aOeN/w5zgIQgGbx2QDg9i08v4nXqbdcFdyZZFPQCoqZqIUFn1w eDcQXqtouY3sFvafMQU7e+818zeXyYBmiIXS0U7mFmLXFHxGeN3Ki5ekGRmRIvfxxNUV PVj9UIFBLskeeVQPAi11rsglf4iZfetaRhBhwcswbzcpTGXjzIcLQBTk/2B4BAo5ZXjY e8XrmNV5f8wUWO4bwqZnhxXwpj5eLLL3Vmx9AY8UDe0PJisZdrWLukuljC3KnSvozzki qQ==
Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2102.outbound.protection.outlook.com [104.47.70.102]) by mx0b-00273201.pphosted.com with ESMTP id 34y1pmhp1e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 22 Nov 2020 21:20:43 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YK5NfsGggTX/9AMFOMMqS0pg8dcL5u0Dm6saI85gvAGiQ0X2nNELeLAcu2+cFqxbd2rS5eSzK+GjMQ1JXBorvG/dgxVNXEUH6S2ZSNWZS2ijmGSQcgEu/F6AP0ChFP0gYxHf7dAH/NlFK76PjiKyuKfx6vxggGbGsnF4w3zodXzFqP8gJHU3AgWhzi30Am2KMmkcXwltR+Ylu1SN8Ue0pUdizw85BcSaYlPqHGmgiR9JwAJXEwC72LRHpiXzHRFWXaVUhAVWUhVpFB9ujLWbx9hgzC3k9KqAr/4/yYHRvE3rwdTUJQAoE1evYJHSMLEIHYYmC088XXg7lO+aFXcGKg==
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=lxdhutfZsHvp0gxIRKtouqJ2N+b6ZuiKwS8mpjN0TxY=; b=Mjk0zIpfeseixzB6E5kCL7W9OYIk8hYfyzKycITvFFOyrq9Ye0KGPcB51p4uJHK/kiU7OHMZvMLRfVFf+TneWN4kBZ5pCb6WGTbYxY5kkwlW2cg54f+/Ma1ZEu3jh4dzkFB9wu+X/av/L16t8AImXYvXhahUCamGRHcTonVrs5jHDTS/Ohzg2NSK/yeF7EoO/S1qjtgh7NABzZ9u9V5J7lL5AO51SmV331RpdImvHuRHMcVoQqtdt3/XB+RyRKupBd9PXtdJt1f9n8w76Uxau2vd4Bgf8TfrnQbib92pqsZ0yBD39NXEQIDEc1Hz6Mbk0WfX3kxjFT8dOfrfKnhEag==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lxdhutfZsHvp0gxIRKtouqJ2N+b6ZuiKwS8mpjN0TxY=; b=Ww7zRNYlbWsIikCtoRQ1XH7SMTgzT6/I9tvN66uoA8hxGV+QW8hq5eWu7M4fCUZKv5ruh1xoW9Lbe8dcLP3pQKvO0ucOZ5xT78NgBFGNJ+gx0WWsWEwiE810JzhmDbNL4gocr3FSsDGVP2WTry7n2loJFxNgb8NwMVUBrqSbAgc=
Received: from DM6PR05MB5129.namprd05.prod.outlook.com (2603:10b6:5:7c::30) by DM6PR05MB5434.namprd05.prod.outlook.com (2603:10b6:5:d::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.14; Mon, 23 Nov 2020 05:20:39 +0000
Received: from DM6PR05MB5129.namprd05.prod.outlook.com ([fe80::d9f4:79e6:8e7:aa30]) by DM6PR05MB5129.namprd05.prod.outlook.com ([fe80::d9f4:79e6:8e7:aa30%3]) with mapi id 15.20.3611.020; Mon, 23 Nov 2020 05:20:39 +0000
From: Chandrasekar Ramachandran <csekar@juniper.net>
To: Benjamin Kaduk <kaduk@mit.edu>, Alvaro Retana <aretana.ietf@gmail.com>
CC: The IESG <iesg@ietf.org>, "draft-ietf-mpls-ri-rsvp-frr@ietf.org" <draft-ietf-mpls-ri-rsvp-frr@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, Nicolai Leymann <n.leymann@telekom.de>
Thread-Topic: Alvaro Retana's Discuss on draft-ietf-mpls-ri-rsvp-frr-07: (with DISCUSS and COMMENT)
Thread-Index: AQHVqvWrtsg/6/RiYUiuHFBqqwSTY6eq4MYAgACvR5A=
Date: Mon, 23 Nov 2020 05:20:38 +0000
Message-ID: <DM6PR05MB5129DA25EC1057B8CD3D40BAD9FC0@DM6PR05MB5129.namprd05.prod.outlook.com>
References: <157532380379.1952.9823190776406362368.idtracker@ietfa.amsl.com> <MN2PR05MB61746F4DCF7D06BC7BF73055D95D0@MN2PR05MB6174.namprd05.prod.outlook.com> <CAMMESsx4oUrGbhD4OiHMNxA32NAmqFyZV_00BA_MBWW0kyojKw@mail.gmail.com> <20191205032322.GD13890@kduck.mit.edu>
In-Reply-To: <20191205032322.GD13890@kduck.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.5.0.60
dlp-reaction: no-action
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-11-23T05:20:35Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=f3ce1f22-479c-4ad7-8d14-ccc312e64c36; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2
authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [49.207.142.24]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: ae2f0198-f77d-4b86-9896-08d88f6f83f3
x-ms-traffictypediagnostic: DM6PR05MB5434:
x-microsoft-antispam-prvs: <DM6PR05MB543489BAD0CF5127DA4E7FFDD9FC0@DM6PR05MB5434.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: JKjlMzJo2lbJlLr7zRZZ4hbMKkFEyPFm+LQIVKIdNgHnf3olgLQi+ehmX57cUPQPDXA96jCSfljeuf4f2FJz3ygnCaTrZ6H76GTNbsVkWRW2LyMxYHF8+R1uhfe66JDE0IwO2sNXKOK1tPd5wxoQKIGCZCXjHpL3tEHqDhvydd5YdQ6Cnnr9HamGJ2IXyAz60G/xw2k5LWUbhcW7MpHYqmMUng8P3U6Dx1PRcc0pXGeDj102i5UxBOqdYT59AM1ZOCvnb2kQkTnY1gI2Wnb4Ml2QiGSQ2uYeVf+Jg/+JSk1XUJgKNvFR0rkqpxvUcx5z54yZy3R3qMcmXO7+eySSnZ+WL396Arut71TAq7MeDFS9VxtzcpIAnluE48K5NpVF/n5ZPuIhYtCyNZvHiOG2jg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR05MB5129.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(376002)(39860400002)(366004)(346002)(136003)(5660300002)(8676002)(478600001)(83380400001)(7696005)(2906002)(9686003)(86362001)(55016002)(316002)(52536014)(110136005)(71200400001)(54906003)(33656002)(4326008)(76116006)(186003)(26005)(66446008)(66556008)(66476007)(64756008)(66946007)(6506007)(53546011)(8936002)(55236004); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: 7beuFpVuugYz3Td9NXTTr4frOz+wZ9Ad6wA62nJXK4Wc9r7LqTcnAwAOK2IaVx7qOGqRejwk0WI+R4joZbTwMGI8EsyS/xI00h2CbhGghVCfQu028ga7fJn17G1vhZTJsJ/UJb3a/ite5+M+52xStuRIaff7HwPdUzs8Iqns94mjr2Dp51DpmZ8a40G+lqjx83qibZI4wWfkuBHaV1LhP6nSWo7xdFFrU1bJZ0HyNrXAhdSoo43mcF7z03ZvpxLRrn4FMyvpUlr/+A3j1VbWNPOUNkz0MwS4s24gcvyHUUBa+Al7pBqutkCbqIbxut6yEg9y7XHGoD7ezhkHGI6pc5gNW8GgkY1IKQUZCZjVhEaR0TIqrvS3OrtFCa6FK5IUGTbaFAJ5ng1MUh4+I8N3NqUBK46aItFc3grrYR5o2M/Pw7n7BC0j+F9SiqoObliFbMuwR/tZRjAIRU6BT/FWs0Oq24l6v9BQXQMZ1HidmcUsWytgXQbF0xl0UVDRVUX/ibhjULb+GdWg3nfe/ztAyt6XE8Y8SURUneH1IrpD+IRBu4UmAQQxQzau3hG7gknCXGGzMczNwbbuF5yzpY7nZQv54s4vDmhU//QOyIkGr+SmscUUEtBEUhmHp0KBqkV5N+i4s8iL2TtqN2RXl5jaFQV+oc37Qzoo72JEoxsRRwnhqCDk5OnEFds5d1o6IJeZB10pJOPs5lfab2NoTIUo58o3j5NDZZt1++TmXXxd8iCc0Bi4fOWmpouzitbhHnnbGC1sj0VYLpvRPTxNHS0fZkyABkR08NfTR2TJ/bcdpWz473TUuQr/3okFfoDyFn1iaegH5IXLiDS1LKqw+BBgY85yoTK1JCS/jEJPqquT+9bRtlGxEobxGZKe/QgEYfx4Qo+GtChyo7dDyzDdrFqPFaPU6oxH/kLkKjmfERwbiyGDz04MflCRzMhd20QSx9KTHLsR8TcA10HYhQZDAcQlyLe9fIeXOLpzUaF4RCd1XnE=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM6PR05MB5129.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ae2f0198-f77d-4b86-9896-08d88f6f83f3
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2020 05:20:38.9357 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Yis4OZITPy9Wd7CaKlEELJWpMeuIw9uUTKOcm39mCEwR6HfVr3WyHwbSCetzQb5nGbGXPllgII+NlU9bE8hh/Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB5434
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-23_01:2020-11-20, 2020-11-23 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 suspectscore=0 bulkscore=0 phishscore=0 adultscore=0 mlxscore=0 malwarescore=0 clxscore=1015 lowpriorityscore=0 spamscore=0 priorityscore=1501 mlxlogscore=999 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011230037
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/sRl5ZSF7kOJl9aM5d2zHjIodQXU>
Subject: Re: [mpls] Alvaro Retana's Discuss on draft-ietf-mpls-ri-rsvp-frr-07: (with DISCUSS and COMMENT)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Nov 2020 05:20:46 -0000

Hi Benjamin,
Please refer inline for your question on the I-bit.

Thanks,
Chandra.


Juniper Business Use Only

> -----Original Message-----
> From: Benjamin Kaduk <kaduk@mit.edu>
> Sent: Thursday, December 5, 2019 8:53 AM
> To: Alvaro Retana <aretana.ietf@gmail.com>
> Cc: Chandrasekar Ramachandran <csekar@juniper.net>; The IESG
> <iesg@ietf.org>; draft-ietf-mpls-ri-rsvp-frr@ietf.org; mpls@ietf.org; mpls-
> chairs@ietf.org; Nicolai Leymann <n.leymann@telekom.de>
> Subject: Re: Alvaro Retana's Discuss on draft-ietf-mpls-ri-rsvp-frr-07: (with
> DISCUSS and COMMENT)
> 
> On Wed, Dec 04, 2019 at 02:53:40PM -0800, Alvaro Retana wrote:
> > On December 4, 2019 at 1:50:12 PM, Chandrasekar Ramachandran wrote:
> >
> > Chandra:
> >
> > Hi!
> >
> >
> > > > -----Original Message-----
> > > > From: Alvaro Retana via Datatracker
> > ....
> > > > ------------------------------------------------------------------
> > > > ----
> > > > DISCUSS:
> > > > ------------------------------------------------------------------
> > > > ----
> > > >
> > > > §4.1 (Requirement on RFC 4090 Capable Node to advertise RI-RSVP
> > > > Capability)
> > > > says:
> > > >
> > > > A node supporting [RFC4090] facility protection FRR MAY set the
> > > > RI- RSVP capability (I bit) defined in Section 3 of RSVP-TE
> > > > Scaling Techniques [RFC8370] only if it supports all the
> > > > extensions specified in the rest of this document. A node
> > > > supporting [RFC4090] facility bypass FRR but not supporting the
> > > > extensions specified in this document MUST reset the RI-RSVP
> > > > capability (I bit) in the outgoing Node-ID based Hello messages.
> > > > Hence, this document updates [RFC4090] by defining extensions and
> > > > additional procedures over facility protection FRR defined in
> > > > [RFC4090] in order to advertise RI-RSVP capability [RFC8370].
> > > >
> > > > I understand the intent: advertise the I bit if this specification
> > > > is supported, and don't if it is not. However, the second sentence
> > > > cannot be normative ("MUST reset the RI-RSVP capability") because,
> > > > by definition, a node that doesn't support this specification
> > > > won't implement anything in it. IOW, this document can't mandate a
> > > > behavior for nodes that may not be aware of it.
> > > >
> > > > The conditions for supporting RI-RSVP from rfc8370/§3 don't
> > > > contemplate this specification (obviously!), which means that
> > > > nodes that conform to
> > > > rfc8370 may advertise the capability without supporting this
> > > > document. Note that rfc8370 doesn't even mention rfc4090, so the
> > > > setting of the I bit seems independent to it too.
> > > >
> > > > I am balloting DISCUSS because the correct setting of the RI-RSVP
> > > > capability is essential to the operation described in this document.
> > > >
> > >
> > > [Chandra] I agree that what you have pointed out requires some
> > > changes to the text. Would the following changes to the document
> > > address your concerns adequately?
> > ....
> > > (3) Change the only paragraph in Section 4.1 from "A node supporting
> > > [RFC4090] facility protection FRR MAY set the RI-RSVP capability (I
> > > bit) defined in Section 3 of RSVP-TE Scaling Techniques [RFC8370]
> > > only if it supports all the extensions specified in the rest of this
> > > document. A node supporting [RFC4090] facility bypass FRR but not
> > > supporting the extensions specified in this document MUST reset the
> > > RI-RSVP capability (I bit) in the outgoing Node-ID based Hello
> > > messages. Hence, this document updates [RFC4090] by defining
> > > extensions and additional procedures over facility protection FRR
> > > defined in [RFC4090] in order to advertise RI-RSVP capability [RFC8370]."
> > > To
> > > "A node supporting [RFC4090] facility protection FRR MUST set the
> > > RI- RSVP capability (I bit) defined in Section 3 of RSVP-TE Scaling
> > > Techniques [RFC8370] only if it supports all the extensions
> > > specified in the rest of this document. Hence, this document updates
> > > [RFC4090] and [RFC8370] by defining extensions and additional
> > > procedures over facility protection FRR defined in [RFC4090] in order to
> advertise RI-RSVP capability [RFC8370]."
> >
> > This new text removes the Normative specification for nodes that don't
> > support this document, which is good.
> >
> > But what about implementations of rfc8370 that may still set the I bit
> > -- before taking the Update into account.  The draft talks about
> > backwards compatibility (when some nodes don't support the new
> > functionality), but it doesn't cover the transition period when some
> > nodes might set the I bit independent of whether they support this
> > document or not.  I would like to see in the text operational
> > considerations of the potential impact of setting the I bit even if
> > the new functionality is not supported (a paragraph or two should be
> > enough); take a look at rfc5706/§2.3.
> 
> Let me ask the dumb/obvious question: why do we have to overload the I
> bit for this purpose?  Can't we allocate a new bit that has precisely the
> semantics we want for the new document, without changing the semantics
> of an existing bit?

[Chandra] Reproducing the response sent to Alvaro:
---
draft-ietf-teas-rsvp-te-scaling-rec (which went on to become RFC8370) and draft-ietf-mpls-ri-rsvp-frr started off as companion documents. Early WG draft versions of RFC8370 (https://tools.ietf.org/html/draft-ietf-teas-rsvp-te-scaling-rec-02, Sec 2.2) had explicit text saying that if an RFC4090 bypass implementation opts to support RI-RSVP, then it must also implement procedures specified in draft-ietf-mpls-ri-rsvp-frr (RI-RSVP-FRR). But based on WG feedback (rightly so), it was decided that draft-ietf-teas-rsvp-te-scaling-rec should be kept fairly generic (applicable to all data-plane technologies) and shouldn't include any MPLS specific implementation recommendations. 

If an RFC4090 bypass implementation adds support for just RI-RSVP [RFC8370] and does not add support for RI-RSVP-FRR, it leaves room for stale state to linger around for a long time (given the long refresh-interval) after a failover event. Section 3 "Problem Description" of RI-RSVP-FRR draft delves on this in detail. Hence, RI-RSVP-FRR updates RFC4090 bypass FRR procedures and makes them refresh interval independent, i.e. plugs the gap in applying RI-RSVP [RFC8370] technique to RFC4090 bypass procedures. So, the recommendation for RFC4090 bypass implementations is to not turn on RI-RSVP if RI-RSVP-FRR is not supported.
---

I have also reworded the text in Section 4.1 to spell out the requirements on setting or not setting the I-bit by implementations that support RFC 4090 and RFC 8370. I have also included a new Section 4.6.2.3 "Advertising RI-RSVP without RI-RSVP-FRR" describing the impact of ignoring the requirements for setting the I-bit. Could you go through the latest 09 version of the draft and respond if the changes address your comment?

Thanks,
Chandra.