Re: [mpls] RtgDir Review: draft-ietf-mpls-ri-rsvp-frr-05

Chandrasekar Ramachandran <csekar@juniper.net> Thu, 20 June 2019 13:42 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 07A96120045; Thu, 20 Jun 2019 06:42:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level:
X-Spam-Status: No, score=-2.71 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_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
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 khELz6GDw0g7; Thu, 20 Jun 2019 06:42:37 -0700 (PDT)
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 8C37F12004A; Thu, 20 Jun 2019 06:42:34 -0700 (PDT)
Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x5KDdeB1004644; Thu, 20 Jun 2019 06:42:31 -0700
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=k6xteE06Jfl7Tw71dDqKK8O3eDqiG8jRRiV4YVlSuAs=; b=bamiSnLOxC4yGAiWh23AtJUj2as9AJCiM1XyQCjcJQnUT/WQ6kfMVWwBxHm20juRrZ1I T5YbB1Ut1voPNv3ZOBBiHpYGcChvDhzuVoC+ofNOdqon477jS9Pgqolq1q9i+9ekI+2i YuQxiNtetrdU9/kjqLmgVMkPHGo0PsI8XVct56sloqQXfPZOrZ6z9SWMeWPXe12fkTlA CrMDv/F9+r6/NceTMZPsh/F51PGrqb/iZsVZ7AyNLHoyNZNRM0mtWLlzhIeQ4QSioBUw j9cw4Eg9zlTn/PkpDNnafSjo1SlNzRQnkURvUnCm3+9p+xvIDOqGsxdXeMMAP+6wI11l oA==
Received: from nam03-by2-obe.outbound.protection.outlook.com (mail-by2nam03lp2057.outbound.protection.outlook.com [104.47.42.57]) by mx0b-00273201.pphosted.com with ESMTP id 2t86mt8eyc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 20 Jun 2019 06:42:31 -0700
Received: from BYAPR05MB5477.namprd05.prod.outlook.com (20.177.185.202) by BYAPR05MB4967.namprd05.prod.outlook.com (20.177.229.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.12; Thu, 20 Jun 2019 13:42:29 +0000
Received: from BYAPR05MB5477.namprd05.prod.outlook.com ([fe80::d4fa:13a5:a614:a868]) by BYAPR05MB5477.namprd05.prod.outlook.com ([fe80::d4fa:13a5:a614:a868%4]) with mapi id 15.20.2008.007; Thu, 20 Jun 2019 13:42:29 +0000
From: Chandrasekar Ramachandran <csekar@juniper.net>
To: "julien.meuric@orange.com" <julien.meuric@orange.com>, "rtg-ads@ietf.org" <rtg-ads@ietf.org>
CC: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "draft-ietf-mpls-ri-rsvp-frr.all@ietf.org" <draft-ietf-mpls-ri-rsvp-frr.all@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>
Thread-Topic: RtgDir Review: draft-ietf-mpls-ri-rsvp-frr-05
Thread-Index: AQHU8IQvXLYlBNvRrkO4lVOabue9j6ak72NA
Content-Class:
Date: Thu, 20 Jun 2019 13:42:29 +0000
Message-ID: <BYAPR05MB547700FDE3B96DEF070438E6D9E40@BYAPR05MB5477.namprd05.prod.outlook.com>
References: <25527_1555000351_5CAF6C1F_25527_187_1_c344649c-bea5-5d0e-3b76-2bd28be6d226@orange.com>
In-Reply-To: <25527_1555000351_5CAF6C1F_25527_187_1_c344649c-bea5-5d0e-3b76-2bd28be6d226@orange.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.2.0.14
dlp-reaction: no-action
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=True; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Owner=csekar@juniper.net; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2019-06-20T13:42:23.6181087Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Internal; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Application=Microsoft Azure Information Protection; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=a58ce433-4919-42b1-ad05-e8bd4c5e7c6d; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Extended_MSFT_Method=Automatic
x-originating-ip: [117.192.22.138]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3104dcd1-de4c-45d8-fedb-08d6f5852373
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:BYAPR05MB4967;
x-ms-traffictypediagnostic: BYAPR05MB4967:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <BYAPR05MB4967603C1C25FAFDB2891F1AD9E40@BYAPR05MB4967.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:6108;
x-forefront-prvs: 0074BBE012
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(366004)(136003)(39860400002)(396003)(199004)(37854004)(189003)(13464003)(51444003)(66446008)(2906002)(4326008)(52536014)(8936002)(3846002)(6116002)(5660300002)(99286004)(102836004)(5024004)(73956011)(68736007)(478600001)(6436002)(55236004)(14444005)(53546011)(256004)(76176011)(7696005)(316002)(14454004)(33656002)(2501003)(6506007)(53936002)(81156014)(8676002)(71200400001)(71190400001)(7736002)(9686003)(53946003)(110136005)(54906003)(19627235002)(30864003)(74316002)(64756008)(11346002)(446003)(229853002)(6246003)(26005)(476003)(25786009)(486006)(66556008)(66574012)(66946007)(66476007)(76116006)(305945005)(186003)(81166006)(86362001)(66066001)(55016002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4967; H:BYAPR05MB5477.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: btYIZ6yhgq61ZDo/Xd0diPqAEC+GPEpzCRHO4A9Mb4RA6xZW/xKk18YcVvGAMD+ENcFaSxTAQI4La8unDS1aT22fpqzAfWD9HgMY4xjrrBPHCIHN0oldy95M+QQX6aQbbJpCmUp6OauKeIuZDJYOD22NwgCHlBkZuxZXFnC2ObrOBchcRvpkIWlZM9pjIQHm5mPs/efrKPIj27Wv+vs9Hehhz1m4AbS8BMiY1J5Olwi8YS3jffVrzbJzdaLPbf4HomLUM/G3oOmp2D9eabnoHTRjsT9THkIPzw6mtow4vufEiAz27l5C+yQmBD1rIJZh+x1Z8hqLYgfE3jhhVLjdvx7xFjAgpWpVWZF0Ma6x40o8f1afbZK9Xf05QSuDzlGgyiCzm+dKDuyywTQiDq+uOJ8ySZ1L7fBa3GFiBu6I9ug=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 3104dcd1-de4c-45d8-fedb-08d6f5852373
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jun 2019 13:42:29.1854 (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: csekar@juniper.net
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4967
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-06-20_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906200103
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/lxugefkJmXvWGE1K8ImnwZSAGVg>
Subject: Re: [mpls] RtgDir Review: draft-ietf-mpls-ri-rsvp-frr-05
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: Thu, 20 Jun 2019 13:42:41 -0000

Hi Julien,
Draft version 6 uploaded today addresses most of your comments.
Please refer to my detailed responses inline.

Thanks,
Chandra.


Juniper Internal

> -----Original Message-----
> From: julien.meuric@orange.com <julien.meuric@orange.com>;
> Sent: Thursday, April 11, 2019 10:03 PM
> To: rtg-ads@ietf.org
> Cc: rtg-dir@ietf.org; draft-ietf-mpls-ri-rsvp-frr.all@ietf.org; mpls@ietf.org
> Subject: RtgDir Review: draft-ietf-mpls-ri-rsvp-frr-05
> 
> Hello,
> 
> I have been selected as the Routing Directorate reviewer for this draft.
> The Routing Directorate seeks to review all routing or routing-related drafts
> as they pass through IETF last call and IESG review, and sometimes on
> special request. The purpose of the review is to provide assistance to the
> Routing ADs. For more information about the Routing Directorate, please
> see ​https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__trac.tools.ietf.org_area_rtg_trac_wiki_RtgDir&d=DwIDaQ&c=HAkYuh63
> rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=iEQmXlRGWdNbtvVr6ghcatwLYhZUbMF-u63wi_-
> VTtA&m=y53rabR7nvvG-
> 1gvqqZPbmO5lH7P9g4v_e1Yj8unbjg&s=fT9WTkI4LNFIV3mjukePVngq8cvop
> WoONP1JCE18yFg&e=
> 
> Although these comments are primarily for the use of the Routing ADs, it
> would be helpful if you could consider them along with any other IETF Last
> Call comments that you receive, and strive to resolve them through
> discussion or by updating the draft.
> 
> Document: draft-ietf-mpls-ri-rsvp-frr-05
> Reviewer: Julien Meuric
> Review Date: April 10, 2019
> Intended Status: Proposed Standard
> 
> *Summary:*
> I have some minor concerns about this document that I think should be
> resolved before publication.
> 
> *Comments:*
> The document is well written and self consistent. The clear problem
> statement and the solution's "spirit" description make the detailed behavior
> convenient to follow. The main issue is about the use of 2119
> language: only 4 MUSTs are used (2 of them being similar), far too many
> SHOULDs.

[Chandra] The motivation is to enable the implementations to seamlessly interoperate with implementations that do not support the draft during incremental deployment. We have converted a few more SHOULD to MUST keeping the above in consideration. That is, wherever we consider MUST will enable better interoperability, we have upgraded SHOULD to MUST.

> *Major Issues:*
> No major issues found.
> 
> *Minor Issues:*
> Unless I missed an assumption somewhere, I think that, for a Standards
> Track document, many of the existing SHOULDs should actually be MUSTs.
> It is a bit odd to read a document trying to be exhaustive about the possible
> situations and backward compatibility consideration (nice
> work!) while only requiring optional behaviors.

[Chandra] Yes, backward compatibility is an important consideration. You could refer to the latest version for the updates.

> *Nits:*
> ------
> Global
> ---
> - Two nits are repeated along the full document and need to be fixed:
>   * Most of the time, PATH and RESV messages are fully capitalized while
> PathErr, PathTear, ResvTear... are not. Replacing them by Path/Resv would
> bring consistency.
>   * When it comes to nodes or messages names, many definite/indefinite
> articles (the/a) are missing. I have spotted some of them but got lazy...

[Chandra] I have gone through the whole draft again and has fixed all sections. You could refer to the latest version.
 
> ------
> Header
> ---
> - Was RFC 8370 considered to be added to the updated document list? The
> specification is clearly about combining RFC 4090 and 8370.
> - s/Refresh Interval Independent/Refresh-Interval Independent/

[Chandra] Fixed.

> ------
> Abstract
> ---
> - s/LSP related states/LSP-related states/  [x2]
> - LSP is not expanded on 1st use (only in introduction), it may be worth to
> expand earlier.
> - s/fast reroute (FRR)/Fast ReRoute (FRR)/
> - s/Refresh-interval/Refresh-Interval/  [for consistency]

[Chandra] Fixed.

> ------
> 1. Introduction
> ---
> - s/label switched path (LSP)/Label Switched Path (LSP)/
> - s/Standard RSVP/Base RSVP/  [x2]
> - OLD
>    eliminate facility backup protection
>    dependency on refresh timeouts for stale state cleanup including the
>    cleanup for facility backup protection.
>   NEW
>    eliminate facility backup protection
>    dependency on refresh timeouts for stale state cleanup.

[Chandra] Fixed.

> ------
> 2. Terminology
> ---
> - The terms Nhop and NNhop, extensively used, are missing.
> - Adding "B-SFRR-Ready" may be considered.
> - The link between "Merge Point" and "MP" is only implicit: MP and PLR
> deserve to be added as defined terms.
> - s/Link-protecting/Link-Protecting/
> - s/Node-protecting/Node-Protecting/

[Chandra] Fixed.

> ------
> 3. Problem Description
> ---
> - s/Figure 1, consider/Figure 1, let us consider/
> - s/Also assume/Also let us assume/
> - s/A is the Point of Local Repair (PLR) and C is Node Protecting Merge Point
> (NP-MP)/A is the PLR and C is the NP-MP/
> - s/D is the Link Protecting Merge Point (LP-MP)/D is the LP-MP/
> - s/are refreshed has failed/are refreshed, has failed/
> - s/send tear down message/send a tear down message/
> - s/as a Merge Point/as an MP/
> - s/receive PathTear/receive a PathTear/
> - Sentences #2 and #3 in the bullet at the top of page 7 seem to duplicate
> the bullet at the bottom of page 6. This need to be skimmed (I personally
> prefer the wording of the 2nd bullet over the 1st one, including s/send
> PathTear/send a PathTear/).

[Chandra] Fixed.

> ------
> 4. Solution Aspects
> ---
> - s/send tear down message/send a tear down message/  [x2]
> ------
> 4.1.
> ---
> - s/RFC 4090/[RFC4090]/  [x4, excluding section title]
> ------
> 4.2.
> ---
> - s/RFC 4090/[RFC4090]/
> - OLD
>       a LP-bypass LSP to Nhop node avoiding only the link that
>       protected LSP takes to reach Nhop
>   NEW
>       an LP-bypass LSP to the Nhop node avoiding only the link that
>       the protected LSP takes to reach the Nhop.
> 
> - OLD
>       a LP-bypass LSP to Nhop node avoiding the link that
>       protected LSP takes to reach Nhop
>   NEW
>       an LP-bypass LSP to the Nhop node avoiding the link that
>       the protected LSP takes to reach the Nhop.
> 
> - s/RFC 8370/[RFC8370]/
> - OLD
>      included RRO object carried in RESV message.
>      If the MP has not included Node-ID sub-object in RESV RRO
>    NEW
>      included in the RRO object carried in the Resv message.
>      If the MP has not included a Node-ID sub-object in the Resv RRO
> 
> - s/PATH message/Path message/  [x2]
> - s/in CAPABILITY object/in the CAPABILITY object/  [x2]
> - OLD
>     then the PLR SHOULD include B-SFRR-Ready Extended Association object
> and triggers PATH message
>   NEW
>     then [I-D.ietf-mpls-summary-frr-rsvpte] applies: the PLR SHOULD include a
> B-SFRR-Ready Extended Association object and triggers a Path message
> 
> - s/PATH message/Path message/
> - s/ordering rules object/object ordering rules/
> - s/RFC 4090/[RFC4090]/
> - s/RFC 8370/[RFC8370]/
> - s/sub-object in the RRO object carried in the RESV message/sub-object of
> the RRO object carried in the Resv message/
> - s/included Node-ID sub-object in the RRO object carried in PATH
> message/included a Node-ID sub-object in the RRO object carried in the
> Path message/
> - s/The node should determine whether the incoming PATH messages
> contains B-SFRR-Ready/A node receiving Path messages should determine
> whether they contain a B-SFRR-Ready/
> - s/followed by implementations supporting/followed by the
> implementations supporting/
> - s/"Remote" state on MP/"Remote" State on MP/
> - OLD
>     The "remote" state is identical to the protected LSP path state except for
> the difference in RSVP_HOP object.
>   NEW
>     The only difference between the "remote" path state and the LSP path
> state is in the RSVP_HOP object.
> 
> - s/in "remote" Path state/in the "remote" path state/
> - s/MP.../The MP.../  [x4]
> - s/Node signaling/The node signaling/
> - s/a PATH with/a Path message with/
> - s/in PATH RRO/in the Path RRO/
> - s/receives PathTear/receives a PathTear message
> - s/on the Ingress or created from a PATH message from/on the ingress or
> created by a Path message from/
> - s/from PLR/from the PLR/
> - s/called "Remote PathTear"/called "Remote" PathTear/

[Chandra] Fixed.
> ------
> 4.3.
> ---
> - s/Immediate node failures/Node failures/
> - s/SHOULD send Conditional PathTear/SHOULD send a "Conditional
> PathTear" downstream/
> - s/Node-ID signaling/The Node-ID signaling/
> - s/MP receives normal or "Remote" PathTear for PSB/The MP receives a
> normal or "Remote" PathTear for its PSB/  [x3]
> - s/MP receives ResvTear RSB/The MP receives a ResvTear for its RSB/  [x3]
> - s/Remote Node-ID/The remote Node-ID/  [x2]
> - s/Receiving Conditional PathTear/Receiving a Conditional PathTear/
> - s/Figure 1, assume/Figure 1, we assume/
> - s/PATH/Path/  [x5]
> - s/MP receives normal or "Remote" PathTear for PSB/The MP receives a
> normal or "Remote" PathTear for its PSB/  [x2]
> - s/MP receives ResvTear RSB/The MP receives a ResvTear for its RSB/  [x2]

[Chandra] Fixed.

> ------
> 4.4.
> ---
> - s/Conditional Path Tear/Conditional PathTear/  [x3]
> - s/Ingress has/The ingress has/
> - s/and PathTear is not received/and no PathTear is received/
> - Section 4.4.2:
>   * need "a/the" before most (conditional/normal) PathTears
>   * s/included B-SFRR-Ready Extended Association/included the B-SFRR-
> Ready Extended Association/
>   * s/PATH/a Path message/
>   * should consider upgrading some SHOULDs into MUST.
> - s/CONDITIONS object/CONDITIONS Object/
> - s/called as "CONDITIONS" object that/called "CONDITIONS" object, that/
> - "Length, Class, C-type, M bit" would better be followed  by ":" and drop
> the trailing carriage return (like the Terminology section).
> - s/If M-bit is set/If the M bit is set/  [x2]
> - s/processed based on the condition if the receiver router is a Merge Point
> or not./processed according to the receiver router role, i.e. if it is an MP or
> not./
> - s/as normal PathTear message./as a normal PathTear message./

[Chandra] Fixed.

> - The M bit is newly defined: is there any reason not to specify it using
> MUSTs?

[Chandra] Please refer to the earlier comment on backward compatibility consideration.

> ------
> 4.5.
> ---
> - s/the Ingress wants/the ingress wants/
> - s/in "remote" PathTear message/in the "Remote" PathTear message/
> - s/Consider node C in example topology (Figure 1) has/Let us consider that
> node C, in the example topology (Figure 1), has/
> - s/sends normal PathTear/send a normal PathTear/
> - s/Assume B/Let us assume that B/
> - s/send "remote" PathTear/sends a "Remote" PathTear/
> - s/deletes PSB and RSB states/deletes the PSB and RSB states/
> - s/the remote PathTear and delete PSB and RSB states/the "Remote"
> PathTear and delete the PSB and RSB states/
> - s/a router that/a PLR that/
> - s/in RESV message, and if the RRO change indicates that/in the Resv
> message indicating that/
> - s/send "Remote" PathTear/send a "Remote" PathTear/
> - s/assume/let us assume/
> - s/NP-MP for A/NP-MP for PLR A/
> - s/trigger RESV/trigger a Resv/
> - s/in RESV/in the Resv/
> - s/the RESV with/the Resv with/
> - s/send "Remote" PathTear/send a "Remote" PathTear/
> - s/send normal PathTear/send a normal PathTear/
> - s/both PSB and RSB states corresponding/both the PSB and the RSB states
> corresponding/
> - s/Phop Link failure/Phop Link Failure/
> - s/send normal PathTear and delete both PSB and RSB states
> corresponding/send a normal PathTear and delete both the PSB and the RSB
> states corresponding/
> - s/send normal PathTear and delete PSB and RSB states corresponding/send
> a normal PathTear and delete the PSB and RSB states corresponding/
> - s/Consider B-C/Let us consider that B-C/
> - s/send PathErr or ResvTear/send a PathErr nor a ResvTear/
> - s/because backup LSP/because the backup LSP/
> - s/send normal PathTear/send a normal PathTear/
> - s/on receiving PathTear/when receiving a PathTear/
> - s/reject backup LSP PATH and send PathErr/reject the backup LSP Path and
> send a PathErr/

[Chandra] Fixed.

> ------
> 4.6.
> ---
> - s/have been proposed in/have been defined in/
> - s/and remote PathTear/and "Remote" PathTear/
> - s/should support/need to support/  [unless moving to 2119 language]
> - s/in CAPABILITY object/in the CAPABILITY object/
> - s/initiate remote Node-ID/initiate a remote Node-ID/
> - s/with NNhop/with its NNhop/
> - s/set RI-RSVP flag in CAPABILITY object/set the RI-RSVP flag in the
> CAPABILITY object/
> - s/that NNhop/that the NNhop/
> - s/PPhop/the PPhop/  [x3]
> - s/in PATH/in its Path messages/
> - s/set RI-RSVP flag in CAPABILITY object/set the RI-RSVP flag in the
> CAPABILITY object/
> - s/for backward compatibility/for Backward Compatibility/
> - s/in TIME_VALUES object carried in PATH to default short refresh default
> value/in the TIME_VALUES object carried in the Path message to a default
> short refresh value/
> - s/in TIME_VALUES object carried in PATH to a short refresh default
> value/in the TIME_VALUES object carried in the Path message to a default
> short refresh value/
> - s/send remote PathTear or/send any "Remote" PathTear nor/
> - s/trigger PATH/trigger a Path message./
> - s/send Conditional PathTear/send a Conditional PathTear/
> - s/in TIME_VALUES object carried in RESV to default short refresh default
> value/in the TIME_VALUES object carried in the Resv message to a default
> short refresh value/
> - s/in TIME_VALUES object carried in PATH to default value/in the
> TIME_VALUES object carried in the *Resv* message to a default value/
> - s/and PPhop node/and the PPhop node/
> - s/in TIME_VALUES object carried in RESV to default value/in the
> TIME_VALUES object carried in the Resv message to a default value/
> - To be consistent with 4.6.2.1, the last paragraph of section 4.6.2.2.
> should NOT start with a bullet.

[Chandra] Fixed.

Thanks,
Chandra.

> ------
> 
> Cheers,
> 
> Julien
> 
> 
> ______________________________________________________________
> ___________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites
> ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez
> le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les
> messages electroniques etant susceptibles d'alteration, Orange decline
> toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged
> information that may be protected by law; they should not be distributed,
> used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.