From: Chandrasekar Ramachandran <csekar@juniper.net>
To: John Scudder <jgs@juniper.net>
Thread-Topic: John Scudder's Discuss on draft-ietf-mpls-ri-rsvp-frr-18: (with
 DISCUSS and COMMENT)
Thread-Index: AQHayL/buxQbo7klRUqBmqEzDRPvorH4Drbw
Date: Mon, 15 Jul 2024 16:30:22 +0000
Message-ID: 
 <SN4PR0501MB3870B45C2555E9AF3246FF4DD9A12@SN4PR0501MB3870.namprd05.prod.outlook.com>
References: <171694294575.2989.12240535542000524349@ietfa.amsl.com>
 <SN4PR0501MB3870925212C747EFB16DD3FFD9D62@SN4PR0501MB3870.namprd05.prod.outlook.com>
 <399629E6-4FCA-4DE1-AE9E-F218A5D501CA@juniper.net>
In-Reply-To: <399629E6-4FCA-4DE1-AE9E-F218A5D501CA@juniper.net>
Accept-Language: en-US
Content-Language: en-US
msip_labels: 
 MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=33bdf650-f96e-49ec-be84-3cbcad49875a;MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=0;MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true;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_SetDate=2024-07-15T16:00:25Z;MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: SN4PR0501MB3870:EE_|SJ0PR05MB9952:EE_
x-ms-office365-filtering-correlation-id: b520bd73-6b1b-4fef-624f-08dca4eb6c5a
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|38070700018;
x-microsoft-antispam-message-info: 
 =?utf-7?B?bHo2U0NPOVp0V1I2UnRPWWJDWDUySUZiRGVROENFZjA3dHA4UEtLWWIzSXhq?=
 =?utf-7?B?WGlqcmE1M3pmUmZwaDBIZDNBSEk1bE5TWThwRUVtQkhkTERwL24wbWNueHov?=
 =?utf-7?B?STlHRGxhSUplb1dhTExoZ0xYRjRiSWdBQkN1WFJhV1ZsSWp6UGpiVFVMWTdL?=
 =?utf-7?B?WHErLTlEQlczYU1vTFFnMEkzcDFkS3gyWVFQTEtibmtCejVqejcxWXpzVUxh?=
 =?utf-7?B?MmRwYmFobjhkcE5kdzR4RmpxVElCZjUxVlc4SDhVUzZBaWk5dWJIemMyYkl4?=
 =?utf-7?B?Nkt4N3FWSzN6L2pzTEJydW14dXc4cXd1UnN6OThkelRzbystTVRXYkFhQUdM?=
 =?utf-7?B?RVJoMlJjYS9ya1FabHdQL1hvSzVJL2V5bEdvLzQvVWM0bFluZXR6M016QWVi?=
 =?utf-7?B?NXNQeXZKZW9pQnJwY29SUU4rLXQ0ZTFjSlRNTVNCZUE5aHdRdzJkcmpQbist?=
 =?utf-7?B?ZDBmSXd4NzExVkkrLTAwYmpGRkU5Ky1jQzVId0cyWDRWemNFckZHQ1VEWUxY?=
 =?utf-7?B?VzZzazg0VkNXZlgxU1U4RHgzZnFCNGRIZFhoZlQ4Ti9zelRoWFplemxDTktw?=
 =?utf-7?B?WHZ5WDh5UHo4UnkxYmVJcWdob1NMcWFNbmJIbS9oaVU2ZTU5NlRBY0ZRM3BB?=
 =?utf-7?B?aFNGeXh2MGVpR0hWeEZhaVJ4WVlJaTVDVjBZZHVHL1hlUCstWmxGSmJVejdO?=
 =?utf-7?B?bXI5QUJSNzVVZFNXYmhzc3pGeVdhYWlSM1M5T3k0TlUzcDBRTSstYTdXbkQy?=
 =?utf-7?B?ajQ5Ym1LaGNZKy03YSstQTdTTUw4T00rLVR3dHB0RjZ5VHBha2JxQTdJSUM0?=
 =?utf-7?B?V2FGNWxaSGlJekh1cm9RQzZ1QmlWUG9ucUpQWmNsbExiMjk0a0NqSXV1aist?=
 =?utf-7?B?VXpBODNUekhPZVMyVVpaRTkvMVliUTFZRGRzKy0rLTZDWS91Ky05Mkovck1K?=
 =?utf-7?B?aUp5Y0xtOGJ4UW9wZVFJa05Ib2t1VEtzc09JMWYwZXlOY1o3ZnRWbzMvM0RG?=
 =?utf-7?B?ckxJRU1QTm5LUWpHOFVJajE3RU44SU51QzBCekRtcDNISFpocDY5UmlxVHI4?=
 =?utf-7?B?RlE1WTF2QXluS01EaC8yTUNmVVZEaHBoUEVPeDNESlZEV3Fpc1JORlFISmlv?=
 =?utf-7?B?dXBaYUxqcm14V0M1TistQXM2TGVHaG5RWlJtWmRxYUF4Ky1DazhuS00wWVBj?=
 =?utf-7?B?NnliQmhIWkRUcjZ2eHZyZkFWSmRLOSstRld4MystaXVIZEdQY09JN0FrcmNq?=
 =?utf-7?B?Rk90ODBOWWhDdm0vampURnFzdFFBMFlKVGNITysteXVWWDh2R0FGbzRNR0Fx?=
 =?utf-7?B?YmJPUk1qVTB6bEpRdkEwbW56Ky00STZZZVJpUS8rLUNCTDRDSk9YNzk2RXJp?=
 =?utf-7?B?Tk13b3dSS29WSFcxdWdUV2xEKy1va2s4ZCstdGpuRWhCMVRndFFYRnpGMU5C?=
 =?utf-7?B?cjhaNExKNGJSb2UvZURYRC9HemJvV0lXNmZESTRvOU9COGVrbXREUXZXVm5l?=
 =?utf-7?B?M29tUVN4dGlLV1lhYnhMa1BlbGdiYjBobWg1Ky1HYTE0TkdjM0VDaFYvSGh4?=
 =?utf-7?B?ZE43b0hDT3FDQjl5dEFWcHVnUG9PKy1WT1UySU02NVQzeFp1RHZVSU5HbTVR?=
 =?utf-7?B?ZS9hOTNBblpweVBtRm5HYllIdFM2ZlJBUjdKdko4N0JBVFFJOU5scXpKTDQw?=
 =?utf-7?B?MmJpOWlqdzBjbmlrR2dtTU5FSVhuYmw2ZzBYYWdXQVA1WW15N09JSmZkWGM4?=
 =?utf-7?B?bmZlZmFWbWMzRGZ2TEsyKy1mSnpJTWJxOFNwN0xWY2J5NTIzYmhNbzhqKy1H?=
 =?utf-7?B?bEdLN21vQ0dtKy0vSnNIUUlEY2lHZXIwcWRuZmVHQ1hoVjFEOHJheSstb1ZV?=
 =?utf-7?B?bDJzMTYveDN6b2puS0loekZBTHVXWStBRDAt?=
x-forefront-antispam-report: 
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SN4PR0501MB3870.namprd05.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(38070700018);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 
 =?utf-7?B?VXA5em9MR21Mb1ErLS8xZi9EZm1ZWVY5NnlueEFoSGVlZ3M0UTNhR3ZrRU9J?=
 =?utf-7?B?NTFUclQ0Wm40MlVwV0QzcW9vV2Rta2E2SEhWY0dFWnpneFpNKy1XUlU5SjhQ?=
 =?utf-7?B?OTgzQndPN3VtZGM1MzNoTXlKSkl6a25WYXlPMVd4ajRZdTNWR0hyVVBINTc=?=
 =?utf-7?B?Ky01SXBXRU9WVlNSYW8wcnZXeTh5ZFE0Z2IyM0Q0dk9VTGM1MistR1lVTUlN?=
 =?utf-7?B?aC94bDVseXJyYWZ5U3NlNndEYkpoQlFRaGMvTDBHSmtRRnJCY0IvSkJlYzl4?=
 =?utf-7?B?VzN5dHJtQTk4Smhkck5RdG0vQUF6MDZONS9MM3JBejhPNlFkdTcrLThFTE9T?=
 =?utf-7?B?TnQrLWRyeHFHT3ZrM1hYZmZvelphY2xYaEtEY0NETDhZckZKMXZLQ00zNHVF?=
 =?utf-7?B?U1lJMjBhMnNJS1NrTm9Ddm53VystQ3JsZnBXVjdrR2NyZlhRc3NzRjhlY1Nx?=
 =?utf-7?B?R1hLUGM2STdNNzcwSFd0VWxpTDFmSzlJcFFvc1BqZTI5Mk9Sb09USUFYRTZw?=
 =?utf-7?B?M3YrLXdtbENyT2VmNWtIcFY4QTUyL1dlTnVQdnFOQnZsSVFuRFVONlhNQWln?=
 =?utf-7?B?allBM3cwcmlJYlo0MGowUGUzdFBBVHdyZVJkeUtkOXQvU2p0TC9EUUlab2N4?=
 =?utf-7?B?L2dpTmdabHVBRW9sSFdiQjZHUHBuajFlb2VEeTNEbDl5aVZsVkQ3ckNvbGJ0?=
 =?utf-7?B?RW0yR2hTVzQ2ZGpzM2dpcEwwa0kvdXFQaDR4RWpiNUFlUWhpRnFyRWFhejZr?=
 =?utf-7?B?clJZYVBvbDN2dVFJSEd5azNNdUQ1MkdRVVBaTlRsdXBKd2h0SXVXSzdWanhP?=
 =?utf-7?B?WG9HSkZscXN3V3ZHMmpUM0N5YUhvUEJIVzE2eVJHaHp5TXcwOE1QTDIvWGtp?=
 =?utf-7?B?Y0hpdVlZU25GTEdLUjRjeE8rLVBuTDFTTUk3MUVHcSstdUpqQkh5MDRKNElP?=
 =?utf-7?B?dmMzdk1OYXZNZW1Cb1V3OGExMTRSWjZIQ3o5SGtJVGNJS2NUbGZ5eEhheHll?=
 =?utf-7?B?RWo0dDM1dFcxNXlTOTRsU0grLSstaEx2ckpuS25BanZxKy1ubEVzVHA5RFVm?=
 =?utf-7?B?MEl6SS91UXp0aUFRT3E0SktObHU2dzVoMUMzeHFrcFcyNDlVKy1yVkZZWHF5?=
 =?utf-7?B?RjNZclR1ZnIzVWc0SGx5Mk90Qm9iaE41U0JBTklHQXZERi9VUHZESmZVVnJD?=
 =?utf-7?B?dEcyYUJ1NGdyRXdTeGpjMDJhb1FONlRlMXgxbUJEeWRrS0JRY09qT3pPdWFJ?=
 =?utf-7?B?eW9Xd0hvdnVGRElKNEhONVpjVkhzL1ZQS2hZbTNZN3ZiOUNKRXFsbWg3NnRC?=
 =?utf-7?B?VkM3RlRFWWlrN2NMWWxUSkxNOVpleld1cmFDN0I0RFd2dll3TEc1THQ2RFdP?=
 =?utf-7?B?RENPb1ZvRjd6MVgwc1ZybUJDT25XeFJ6VGtjYTZoakFSeUlJdmhPdjIvKy14?=
 =?utf-7?B?Z0hZVjFrRHdGak9JclFkTXZBR0F0L2JRTWJLaEV2MFdvNDU1TnVUQXJIWjFM?=
 =?utf-7?B?UTMxSHpORlhJVU55VFVjblErLUIwSkRGdDZVNFBhODFxMzlRb25DeHlQSlZR?=
 =?utf-7?B?cUVSdnRVRXhZSkoyQVJqL0JmUUdGdHpFVXREV20vRTRmZ0E5NVJaaTVCcmpk?=
 =?utf-7?B?ZWJSeVlsU0hYZE8vWGIrLTdpWlRRL1pueUwyQVR6b21NYVlXWEVveS9wMVhQ?=
 =?utf-7?B?RWpZKy1zS3VwbEE3UGYyeTFUcWM4T1JjYlVjZ3drZmtQQVZtczRmUjZOTm94?=
 =?utf-7?B?aEFEd1Zoa21tNE10MjJYVXRFNUV4Ky00NkRXOS9XeWF6WlRmeXRVSkJQai9N?=
 =?utf-7?B?Z000LzBYems2TDMzaG5xVkJ2ak5rNzRaVkRacjZkTVBITHQzRkoyZHJXKy1i?=
 =?utf-7?B?WFp4T2pjcFpaSWx3dmNVZVVRRUhqMmpFNUp6TEMwdnlwSU5xdjlvOEpxdHUv?=
 =?utf-7?B?bCstSEtUazlkcllXVmwzU2czY3RZUE1OWlFBREhDLzZ5MFM0YW45OVhCT1Ev?=
 =?utf-7?B?NTZ2U1h1VFc1Y2xGVGEvblNrQXFpYWlYWHp2ZXFNc0JDY241bEVpNHlPZC9q?=
 =?utf-7?B?blJKMHVzQVFWdnFPdWZibU1lMmcwUkh2aHk4b0xSTHRWNklwMnZ6Rktpd2Vq?=
 =?utf-7?B?UWVCem1YaHEvNGhudnIzclRpMkJMT0NsaEZsaUNaZGUwVDYrLTVUcGd2SEVL?=
 =?utf-7?B?Ni9s?=
Content-Type: text/plain; charset="utf-7"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: 
 SN4PR0501MB3870.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 
 b520bd73-6b1b-4fef-624f-08dca4eb6c5a
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2024 16:30:22.1272
 (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: 
 OF4ZGJFAg/kmNDJd9M7k+GIUo5P89RHW1dNpOb6Cd1BheTeC17gOQbkBeE7tyqQp4h4WXrTogozZZq+S8v2/JQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR05MB9952
X-Proofpoint-ORIG-GUID: xT1woSW_G_xGUmCC29Z79oFzAsIQQTAh
X-Proofpoint-GUID: xT1woSW_G_xGUmCC29Z79oFzAsIQQTAh
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.680,FMLib:17.12.28.16
 definitions=2024-07-15_11,2024-07-11_01,2024-05-17_01
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam
 score=0 suspectscore=0
 adultscore=0 spamscore=0 lowpriorityscore=0 impostorscore=0 bulkscore=0
 mlxlogscore=999 phishscore=0 malwarescore=0 clxscore=1011
 priorityscore=1501 mlxscore=0 classifier=spam adjust=0 reason=mlx
 scancount=1 engine=8.19.0-2406140001 definitions=main-2407150130
Message-ID-Hash: C7GEHY7RCXDD47VOJBVLPQZ6UMY2HR5I
X-Message-ID-Hash: C7GEHY7RCXDD47VOJBVLPQZ6UMY2HR5I
X-MailFrom: csekar@juniper.net
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency;
 loop; banned-address; member-moderation; header-match-mpls.ietf.org-0;
 nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size;
 news-moderation; no-subject; digests; suspicious-header
CC: The IESG <iesg@ietf.org>,
 "draft-ietf-mpls-ri-rsvp-frr@ietf.org" <draft-ietf-mpls-ri-rsvp-frr@ietf.org>,
 "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>,
 "mpls@ietf.org" <mpls@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: =?utf-8?q?=5Bmpls=5D_Re=3A_John_Scudder=27s_Discuss_on_draft-ietf-mpls-ri-rs?=
 =?utf-8?q?vp-frr-18=3A_=28with_DISCUSS_and_COMMENT=29?=
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/mpls/zhpgnJr6gc5_g_WQOwc-lQSL7PA>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Owner: <mailto:mpls-owner@ietf.org>
List-Post: <mailto:mpls@ietf.org>
List-Subscribe: <mailto:mpls-join@ietf.org>
List-Unsubscribe: <mailto:mpls-leave@ietf.org>

Hi John,
Please see inline (prefixed +AFs-CR2+AF0-) for responses.


Juniper Business Use Only
+AD4- -----Original Message-----
+AD4- From: John Scudder +ADw-jgs+AEA-juniper.net+AD4-
+AD4- Sent: Thursday, June 27, 2024 11:59 PM
+AD4- To: Chandrasekar Ramachandran +ADw-csekar+AEA-juniper.net+AD4-
+AD4- Cc: The IESG +ADw-iesg+AEA-ietf.org+AD4AOw- draft-ietf-mpls-ri-rsvp-f=
rr+AEA-ietf.org+ADs- mpls-
+AD4- chairs+AEA-ietf.org+ADs- mpls+AEA-ietf.org+ADs- Nicolai Leymann +ADw-=
n.leymann+AEA-telekom.de+AD4-
+AD4- Subject: Re: John Scudder's Discuss on draft-ietf-mpls-ri-rsvp-frr-18=
: (with
+AD4- DISCUSS and COMMENT)
+AD4-
+AD4- Hi Chandra,
+AD4-
+AD4- Thanks for your reply. I hadn+IBk-t realized there was such a long hi=
story to the
+AD4- issue raised in my DISCUSS. Based on the fact I ended up DISCUSSing o=
n
+AD4- virtually the same issue Alvaro did in 2019, I have two immediate rea=
ctions:
+AD4-
+AD4- - I+IBk-ll clear the DISCUSS because even though I don+IBk-t love it,=
 this issue has been
+AD4- raised and considered already.
+AD4-
+AD4- - However, some additional (editorial level) work should be done to f=
urther
+AD4- clarify the document in these areas. See more in line below.
+AD4-
+AD4- +IBQ-John
+AD4-
+AD4- +AD4- On Jun 26, 2024, at 7:07+IC8-AM, Chandrasekar Ramachandran
+AD4- +ADw-csekar+AEA-juniper.net+AD4- wrote:
+AD4- +AD4-
+AD4- +AD4- Thanks for the detailed review. Please see inline (prefixed +AF=
s-CR+AF0-) for
+AD4- responses.
+AD4- +AD4-
+AD4- +AD4- Thanks,
+AD4- +AD4- Chandra.
+AD4- +AD4-
+AD4- +AD4-
+AD4- +AD4- Juniper Business Use Only
+AD4- +AD4APg- -----Original Message-----
+AD4- +AD4APg- From: John Scudder via Datatracker +ADw-noreply+AEA-ietf.org=
+AD4-
+AD4- +AD4APg- Sent: Wednesday, May 29, 2024 6:06 AM
+AD4- +AD4APg- To: The IESG +ADw-iesg+AEA-ietf.org+AD4-
+AD4- +AD4APg- Cc: draft-ietf-mpls-ri-rsvp-frr+AEA-ietf.org+ADs- mpls-chair=
s+AEA-ietf.org+ADs-
+AD4- +AD4APg- mpls+AEA-ietf.org+ADs- Nicolai Leymann +ADw-n.leymann+AEA-te=
lekom.de+AD4AOw-
+AD4- +AD4APg- n.leymann+AEA-telekom.de
+AD4- +AD4APg- Subject: John Scudder's Discuss on draft-ietf-mpls-ri-rsvp-f=
rr-18:
+AD4- +AD4APg- (with DISCUSS and COMMENT)
+AD4- +AD4APg-
+AD4- +AD4APg- +AFs-External Email. Be cautious of content+AF0-
+AD4- +AD4APg-
+AD4- +AD4APg-
+AD4- +AD4APg- John Scudder has entered the following ballot position for
+AD4- +AD4APg- draft-ietf-mpls-ri-rsvp-frr-18: Discuss
+AD4- +AD4APg-
+AD4- +AD4APg- When responding, please keep the subject line intact and rep=
ly to all
+AD4- +AD4APg- email addresses included in the To and CC lines. (Feel free =
to cut
+AD4- +AD4APg- this introductory paragraph, however.)
+AD4- +AD4APg-
+AD4- +AD4APg-
+AD4- +AD4APg- Please refer to
+AD4- +AD4APg- https://urldefense.com/v3/+AF8AXw-https://www.ietf.org/about=
/groups/iesg/st
+AD4- +AD4APg- atem
+AD4- +AD4APg- ents/handling-ballot-positions/+AF8AXwA7ACEAIQ-NEt6yMaO-gk+A=
CE-E-
+AD4- +AD4APg- wtrMVo1qpsxwkeOZLVQjhalO1sPdAEG-o4lpb0Wn4W-
+AD4- +AD4APg- lL70xoGf8s0cEIBtrEpTeWgFiMeSkm3cw+ACQ-
+AD4- +AD4APg- for more information about how to handle DISCUSS and COMMENT
+AD4- +AD4APg- positions.
+AD4- +AD4APg-
+AD4- +AD4APg-
+AD4- +AD4APg- The document, along with other ballot positions, can be foun=
d here:
+AD4- +AD4APg- https://urldefense.com/v3/+AF8AXw-https://datatracker.ietf.o=
rg/doc/draft-ie
+AD4- +AD4APg- tf-mpls-
+AD4- +AD4APg- ri-rsvp-frr/+AF8AXwA7ACEAIQ-NEt6yMaO-gk+ACE-E-wtrMVo1qpsxwke=
OZLVQjhalO1sPdAEG-
+AD4- +AD4APg- o4lpb0Wn4W-lL70xoGf8s0cEIBtrEpTeWgFiN5pzldoQ+ACQ-
+AD4- +AD4APg-
+AD4- +AD4APg-
+AD4- +AD4APg-
+AD4- +AD4APg- ------------------------------------------------------------=
---------
+AD4- +AD4APg- -
+AD4- +AD4APg- DISCUSS:
+AD4- +AD4APg- ------------------------------------------------------------=
---------
+AD4- +AD4APg- -
+AD4- +AD4APg-
+AD4- +AD4APg- +ACM- John Scudder, RTG AD, comments for draft-ietf-mpls-ri-=
rsvp-frr-18
+AD4- +AD4APg- CC +AEA-jgscudder
+AD4- +AD4APg-
+AD4- +AD4APg- Thanks for this document. It's a dense read for someone like=
 me who
+AD4- +AD4APg- is not an expert in RSVP, but it seems important, useful, an=
d
+AD4- +AD4APg- carefully done. I appreciate the precise and detailed work.
+AD4- +AD4APg-
+AD4- +AD4-
+AD4- +AD4- +AFs-CR+AF0- Thank you.
+AD4- +AD4-
+AD4- +AD4APg- I have one concern I've flagged as a DISCUSS point, which ma=
y turn
+AD4- +AD4APg- out not to be a big deal if I've just misunderstood some nua=
nce, but
+AD4- +AD4APg- in any case, we should talk through it. I also have some oth=
er
+AD4- +AD4APg- comments I hope might be helpful.
+AD4- +AD4APg-
+AD4- +AD4APg- +ACMAIw- DISCUSS
+AD4- +AD4APg-
+AD4- +AD4APg- +ACMAIwAj- Section 4.1
+AD4- +AD4APg-
+AD4- +AD4APg-   A node supporting facility backup protection +AFs-RFC4090+=
AF0- MUST set the
+AD4- +AD4APg-   RI-RSVP flag (I bit) that is defined in Section 3.1 of RSV=
P-TE
+AD4- +AD4APg-   Scaling Techniques +AFs-RFC8370+AF0- only if it supports a=
ll the extensions
+AD4- +AD4APg-   specified in the rest of this document.
+AD4- +AD4APg-
+AD4- +AD4APg- I have several concerns about this. At least some of them pr=
obably
+AD4- +AD4APg- relate to my limited expertise in the subject area, but mayb=
e I can
+AD4- +AD4APg- at least expose some areas where additional explanation migh=
t be helpful
+AD4- in the document.
+AD4- +AD4APg-
+AD4- +AD4-
+AD4- +AD4- +AFs-CR+AF0- Please also refer to the responses sent to Ketan
+AD4- (https://mailarchive.ietf.org/arch/msg/mpls/gMpvz7ez80a9AfOdPOvPSUZEc=
p
+AD4- M/).
+AD4- +AD4-
+AD4- +AD4APg- First and foremost, as written this sentence doesn't seem li=
ke it's
+AD4- +AD4APg- achievable in practice. Couldn't there be a legacy router in=
 the
+AD4- +AD4APg- field that supports both RFC
+AD4- +AD4APg- 4090 and RFC 8370? Wouldn't that router then advertise the I=
 bit, at
+AD4- +AD4APg- least in some circumstances?
+AD4- +AD4APg-
+AD4- +AD4-
+AD4- +AD4- +AFs-CR+AF0- As noted in the response to Ketan, the authors bel=
ieve that it is
+AD4- extremely unlikely that an MPLS RSVP-TE implementation that supports
+AD4- RFC4090 would implement only RI-RSVP and not RI-RSVP-FRR. So, we don'=
t
+AD4- envision there being a legacy MPLS router in the field that supports =
both RFC
+AD4- 4090 and RFC 8370. In the unlikely scenario where such an implementat=
ion
+AD4- choice was made, the requirements on the establishment of signaling
+AD4- handshake and the backwards compatibility procedures discussed in the
+AD4- document provide for sufficient cover.
+AD4- +AD4-
+AD4- +AD4APg- Second, this MUST seems to conflict with a SHOULD in section=
 4.6.1,
+AD4- +AD4APg- which says,
+AD4- +AD4APg-
+AD4- +AD4APg-   An implementation supporting RI-RSVP-FRR extensions SHOULD=
 set the
+AD4- +AD4APg-   flag +ACI-Refresh interval Independent RSVP+ACI- or RI-RSV=
P flag in the
+AD4- +AD4APg-   CAPABILITY object carried in Hello messages as specified i=
n RSVP-TE
+AD4- +AD4APg-   Scaling Techniques +AFs-RFC8370+AF0-.
+AD4- +AD4APg-
+AD4- +AD4-
+AD4- +AD4- +AFs-CR+AF0- We will update this to a +ACI-MUST+ACI-.
+AD4- +AD4-
+AD4- +AD4APg- It makes me wonder if the section 4.1 paragraph should be mo=
re like this.
+AD4- +AD4APg-
+AD4- +AD4APg- NEW:
+AD4- +AD4APg-   A node supporting facility backup protection +AFs-RFC4090+=
AF0- MUST NOT set
+AD4- the
+AD4- +AD4APg-   RI-RSVP flag (I bit) that is defined in Section 3.1 of RSV=
P-TE
+AD4- +AD4APg-   Scaling Techniques +AFs-RFC8370+AF0- unless it supports al=
l the extensions
+AD4- +AD4APg-   specified in the rest of this document.
+AD4- +AD4APg-
+AD4- +AD4-
+AD4- +AD4- +AFs-CR+AF0- Based on the three responses above, is this change=
 still necessary?
+AD4-
+AD4- I+IBk-m going to move to No Objection, which means that I think the d=
ocument
+AD4- +ACo-can+ACo- proceed without further changes if you and the responsi=
ble AD agree
+AD4- to it, but I still think you +ACo-should+ACo- make a change here. Let=
 me try again to
+AD4- explain my point. The current Section 4.1 text is,
+AD4-
+AD4- OLD:
+AD4-    A node supporting facility backup protection +AFs-RFC4090+AF0- MUS=
T set the
+AD4-    RI-RSVP flag (I bit) that is defined in Section 3.1 of RSVP-TE
+AD4-    Scaling Techniques +AFs-RFC8370+AF0- only if it supports all the e=
xtensions
+AD4-    specified in the rest of this document.
+AD4-
+AD4- IMO, the way you've chosen to express this makes the intent unclear. =
I had
+AD4- offered the rewrite,
+AD4-
+AD4- NEW:
+AD4-    A node supporting facility backup protection +AFs-RFC4090+AF0- MUS=
T NOT set
+AD4-    the RI-RSVP flag (I bit) that is defined in Section 3.1 of RSVP-TE
+AD4-    Scaling Techniques +AFs-RFC8370+AF0- unless it supports all the ex=
tensions
+AD4-    specified in the rest of this document.
+AD4-
+AD4- This is intended to simply be a rearrangement of the clauses in a way=
 that
+AD4- makes it easier for a reader to understand what your intent is. If yo=
u think I've
+AD4- changed your meaning vs. the original, please help me understand what=
 you
+AD4- think the difference is.

+AFs-CR2+AF0- The authors are fine with the proposed text. We will update t=
he text in the next version of the draft.

+AD4- +AD4APg- (Although even though that might be clearer, the first point=
 stands,
+AD4- +AD4APg- that it might not be achievable.)
+AD4- +AD4APg-
+AD4- +AD4-
+AD4- +AD4- +AFs-CR+AF0- As noted above, we don't envision there being a le=
gacy MPLS router in
+AD4- the field that supports both RFC 4090 and RFC 8370. There was some te=
xt in a
+AD4- draft version of RFC8370, that explicitly stated +ACI-use RI-RSVP-FRR=
 procedures if
+AD4- RFC4090 procedures are implemented+ACI- (see section 2.2 of
+AD4- https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-scaling-rec/=
02/), but it
+AD4- was removed in later stages based on WG feedback.
+AD4- +AD4-
+AD4- +AD4APg- Third, moving on to the end of the paragraph,
+AD4- +AD4APg-
+AD4- +AD4APg-   Procedures for backward compatibility (see Section 4.6.2.3=
 of this
+AD4- +AD4APg-   document) delves on this in detail.
+AD4- +AD4APg-
+AD4- +AD4APg- As far as I can tell, despite the title of Section 4.6.2, Su=
bsection
+AD4- +AD4APg- 4.6.2.3 isn't a procedure for backward compatibility, it's a=
 warning
+AD4- +AD4APg- about the terrible things that can happen if some node in th=
e network is
+AD4- incompatible.
+AD4- +AD4APg-
+AD4- +AD4-
+AD4- +AD4- +AFs-CR+AF0-  Subsection 4.6.2.3 was added based on the discuss=
ion in the
+AD4- +AD4- following thread (ask was to add some text describing the opera=
tional
+AD4- +AD4- considerations for this particular scenario):
+AD4- +AD4- https://mailarchive.ietf.org/arch/msg/mpls/KDRVWBAajl08pnXDkit0=
ykRyZDg
+AD4- +AD4- /
+AD4-
+AD4- OK. I accept this subsection was the negotiated settlement to the obj=
ection
+AD4- Alvaro raised, and then I later unknowingly re-raised. I think it sho=
uld be
+AD4- moved to a different section, however, since it is indeed not a proce=
dure for
+AD4- backward compatibility at all (right?). I suggest you retitle it,
+AD4-
+AD4- OLD:
+AD4-    Advertising RI-RSVP without RI-RSVP-FRR
+AD4-
+AD4- NEW:
+AD4-    Consequence of Advertising RI-RSVP without RI-RSVP-FRR
+AD4-
+AD4- And that you move it up a couple of levels, making it Section 4.7 for=
 instance.
+AD4-

+AFs-CR2+AF0- Agree it will be appropriate not to include under backward co=
mpatibility section but instead move it to a different section as suggested=
. We will move and change the title in the next version of the draft.

+AD4- Finally, I think you could make exactly what this section is doing mo=
re
+AD4- transparent with a small edit, viz,
+AD4-
+AD4- OLD:
+AD4-    If a node supporting facility backup protection +AFs-RFC4090+AF0- =
sets the
+AD4-    RI-RSVP capability (I bit) but does not support the RI-RSVP-FRR
+AD4-    extensions, then it leaves room for stale state to linger around f=
or
+AD4-    an inordinate period of time or disruption of normal FRR operation
+AD4-    (see Section 3 of this document).
+AD4-
+AD4- NEW:
+AD4-    If a node supporting facility backup protection +AFs-RFC4090+AF0- =
sets the
+AD4-    RI-RSVP capability (I bit) but does not support the RI-RSVP-FRR
+AD4-    extensions, for example because it is a legacy node, or due to an
+AD4-    implementation bug or configuration error, then it leaves room for
+AD4-    stale state to linger around for an inordinate period of time or
+AD4-    disruption of normal FRR operation (see Section 3 of this document=
).
+AD4-

+AFs-CR2+AF0- As pointed out in an earlier mail that the authors consider t=
hat it is extremely unlikely that an MPLS RSVP-TE implementation that suppo=
rts RFC4090 would implement only RI-RSVP and not RI-RSVP-FRR, we will adopt=
 the NEW text but only removing the phrase on legacy node.

NEW:
   If a node supporting facility backup protection +AFs-RFC4090+AF0- sets t=
he
   RI-RSVP capability (I bit) but does not support the RI-RSVP-FRR
   extensions, due to an implementation bug or configuration error,
   then it leaves room for stale state to linger around for an inordinate
   period of time or disruption of normal FRR operation (see Section 3
   of this document).

+AD4- +AD4-
+AD4- +AD4APg- Is all of this right? That there could be a legacy node in t=
he
+AD4- +AD4APg- network, with no way to detect that it doesn't comply with t=
he
+AD4- +AD4APg- present specification, and that terrible things such as 4.6.=
2.3 describes,
+AD4- could happen as a result?
+AD4- +AD4APg-
+AD4- +AD4-
+AD4- +AD4- +AFs-CR+AF0- Please refer to the previous response above.
+AD4- +AD4-
+AD4- +AD4APg- (I see Ketan Talaulikar raised a related concern in his RTGD=
IR
+AD4- +AD4APg- review.)
+AD4- +AD4APg-
+AD4- +AD4APg-
+AD4- +AD4APg- ------------------------------------------------------------=
---------
+AD4- +AD4APg- -
+AD4- +AD4APg- COMMENT:
+AD4- +AD4APg- ------------------------------------------------------------=
---------
+AD4- +AD4APg- -
+AD4- +AD4APg-
+AD4- +AD4APg- +ACMAIw- COMMENT
+AD4-
+AD4- Thanks for resolving my previous comments. I have one new comment,
+AD4- related to the changes made since my last review.
+AD4-
+AD4- +ACMAIwAj- Section 4.4.3, what other bits could there be?
+AD4-
+AD4- Version 21 has,
+AD4-
+AD4-       If no bit is set, then the PathTear message MUST be processed a=
s a
+AD4-       normal PathTear message for the LSP.
+AD4-
+AD4- I see this was introduced after my last review. I'm curious as to the=
 reason for
+AD4- the change (I suppose it was the result of somebody else's review). I=
 ask
+AD4- because, the previous text spoke specifically about +ACI-the M-bit+AC=
I- but now you
+AD4- speak generically about +ACI-no bit+ACI-, presumably to include the M=
-bit, but not
+AD4- exclusively. The problem is, I don't see any other bit flags in the o=
bject header,
+AD4- even potentially. The fields are Length, Class, C+IBM-type, a one-bit=
 field called M-
+AD4- bit, and a field 31 bits wide, called +ACI-Reserved+ACI-, but notably=
, not called +ACI-flags+ACI-
+AD4- or something like that.
+AD4-
+AD4- So, what is the difference between the old text, and the new? As far =
as I can
+AD4- tell the new text while correct, is less transparent than the old tex=
t without
+AD4- bringing any benefit.
+AD4-

+AFs-CR2+AF0- The above change was made to address the following questions =
from IANA:
+ACoAKg-
RFC 3936 says that new Class Types registries have 256 values. The current =
version of this document assigns value 1, but doesn't tell us what to do wi=
th value 0. Should it be reserved?

Can you confirm that the new CONDITIONS Objects Flags registry shouldn't ha=
ve a registration or reservation that has the value 0x000?
+ACoAKg-
Please also refer to the corresponding changes in the IANA Considerations S=
ection (Section 6.1).

This document defines just one bit flag, but our intent was to leave room f=
or other bit flags to be introduced in future documents. In case, some impl=
ementation includes the CONDITIONS object in a Tear message and does not se=
t any flag, then it should be treated like a regular unconditional Tear mes=
sage. That was the motivation behind saying +IBM- +IBw-If no bit is set..+I=
B0-.

Would the following changes address your concern?

In Section 4.4.3:
Class: TBA1
C-type: 1
Reserved bits: Reserved bits MUST be set to zero on transmission and MUST b=
e ignored on receipt.
Merge-point condition (M) bit: If the M bit is set to 1, then the PathTear =
message MUST be processed according to the receiver router role, i.e. if th=
e receiving router is an MP or not for the LSP.  If the M bit is set to 0, =
then the PathTear message MUST be processed as a normal PathTear message fo=
r the LSP.

In Section 6.1:
s/sub-registry for +ACI-CONDITIONS Object Flags+ACI-/sub-registry for +ACI-=
CONDITIONS Object Values+ACI-

thanks,
Chandra.