Re: [mpls] WGLC for draft-ietf-mpls-ri-rsvp-frr-02

Chandrasekar Ramachandran <> Thu, 08 February 2018 18:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 04677127023; Thu, 8 Feb 2018 10:49:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.7
X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id c-fUz3fuOrFQ; Thu, 8 Feb 2018 10:49:07 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 982831242F7; Thu, 8 Feb 2018 10:49:07 -0800 (PST)
Received: from pps.filterd ( []) by ( with SMTP id w18IksaZ008199; Thu, 8 Feb 2018 10:49:06 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=TnD2j/Fj5XMkmfacCRhZebQsX95dsJLDfhTbJxdpnJ0=; b=FEWoVpT1HpVpfOMkPG/4grp1uHOMbv0wkYUVDQtdkfBPpjvE4Sl9rrVWNsOPfWgk+DVU JOH9MqRxveXJ5v+lqq6ncQBy1Pf4NFO1gTcxuoQth9c/9x/0/JjvLDHggnbjpXa67YT3 o3mT1eob4Mh2rD5X5bcdluH2zoQIR3/UrWLxPeIZXUBwo9CtEkN3ZbWcrzZW3KXt4Rww NrnWZKy8be5n469924bS0M3rnRxuCYpSdazh/mHEAhO0oMJh+2rKPB1U4TTwUEfWIffj KE0h8TN6d39FbA2gNEUX/35Djo4qxsw7jxOcZBAL2UiQnVqPUlW0GJKNn5DIhYgKe9eg bQ==
Received: from ( []) by with ESMTP id 2g0uug81c1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 08 Feb 2018 10:49:04 -0800
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.3; Thu, 8 Feb 2018 18:49:01 +0000
Received: from ([]) by ([]) with mapi id 15.20.0485.009; Thu, 8 Feb 2018 18:49:00 +0000
From: Chandrasekar Ramachandran <>
To: Alexander Okonnikov <>
CC: "" <>, "" <>, Vishnu Pavan Beeram <>
Thread-Topic: [mpls] WGLC for draft-ietf-mpls-ri-rsvp-frr-02
Thread-Index: AQHTmQmgpsUnMx5Wo02x4Xjs/ODxr6OXYuOg
Date: Thu, 8 Feb 2018 18:49:00 +0000
Message-ID: <>
References: <FRXPR01MB040778B3FB1875A5130DF6B298110@FRXPR01MB0407.DEUPRD01.PROD.OUTLOOK.DE> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY1PR0501MB2124; 7:VmNRGMzwgbzZDG1CwHXaIo/KAj4L/0V5ruNYCtcAH/UpwRNazWAxx/ckXo2/akrW8apWo+0bFlx4wBw9NHy6L8nWyCa9Pd2DA7AFBz8/d24PXQCTARSqweoZjjWVidBr8b+kN4oeobHBznMbJaC3gwzZ4m60pIupaXvDtzOBZyTAT49VABYoLrqMD04oHnihxCLPLGlv+kgILawwJcen1ioDw8zPiNe2f6IOcWmNW2zhzRj/+xGHkDBiLex2Xtca
x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR;
x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(376002)(39860400002)(366004)(396003)(39380400002)(346002)(199004)(189003)(37854004)(229853002)(14454004)(53946003)(6306002)(9326002)(55016002)(102836004)(9686003)(76176011)(236005)(68736007)(7696005)(97736004)(99286004)(33656002)(81156014)(6436002)(25786009)(54896002)(2950100002)(5660300001)(26005)(8936002)(6916009)(81166006)(3280700002)(53546011)(3660700001)(8676002)(105586002)(316002)(93886005)(39060400002)(4326008)(2906002)(6506007)(77096007)(59450400001)(3846002)(966005)(790700001)(186003)(106356001)(6116002)(6246003)(54906003)(74316002)(107886003)(5890100001)(66066001)(7736002)(86362001)(53936002)(478600001)(606006)(2900100001)(42262002)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB2124;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: b009fc49-93ac-4608-f132-08d56f249e1e
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:CY1PR0501MB2124;
x-ms-traffictypediagnostic: CY1PR0501MB2124:
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(28532068793085)(10436049006162)(120809045254105)(138986009662008)(85827821059158)(260130700054247)(95692535739014)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3231101)(2400082)(944501161)(3002001)(6055026)(6041288)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(6072148)(201708071742011); SRVR:CY1PR0501MB2124; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB2124;
x-forefront-prvs: 0577AD41D6
received-spf: None ( does not designate permitted sender hosts)
x-microsoft-antispam-message-info: n0TbLRIZbhiW8CffyfdHCwr41i8C0Q04gDjYJHuJJw1Jkbd3RjfXBYxzTALKupMZ6mIpwtkVhFpHgegXU51Rcw==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY1PR0501MB138828A8AA7D0F14F2E3BF48D9F30CY1PR0501MB1388_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: b009fc49-93ac-4608-f132-08d56f249e1e
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Feb 2018 18:49:00.4501 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB2124
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-08_10:, , 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-1711220000 definitions=main-1802080216
Archived-At: <>
Subject: Re: [mpls] WGLC for draft-ietf-mpls-ri-rsvp-frr-02
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 08 Feb 2018 18:49:11 -0000

Hi Alexander,
Please refer to my responses inline.

From: Alexander Okonnikov []
Sent: Monday, January 29, 2018 7:31 PM
To: Chandrasekar Ramachandran <>et>; Mike Taillon (mtaillon) <>
Subject: Re: [mpls] WGLC for draft-ietf-mpls-ri-rsvp-frr-02

Hi Chandra,

I'm sorry. Yes, I mixed these two drafts. Follow is my comments for draft-ietf-mpls-ri-rsvp-frr-02:

Section 2:

"NP-MP node: Merger Point router at the tail of Node-protecting bypass tunnel."

Merger -> Merge

[Chandra] I will fix this in the next version of the draft.

Section 4.1.1:

"If the NP-MP in a different area has not included NodeID in RRO, then the PLR SHOULD use NP-MP's interface address present in the RRO."

It would cause for NodeID-based adjacency and bypass tunnel to be broken in case of Nhop node failure.

[Chandra] Inclusion of NodeID in RRO is a SHOULD clause in the draft.
    -  The PLR SHOULD also include its router ID in a NodeID sub-object
      in PATH RRO unless configured explicitly not to include NodeID.
      While including its router ID in the NodeID sub-object carried in
      the outgoing Path message, the PLR MUST include the NodeID sub-
      object after including its IPv4/IPv6 address or unnumbered
      interface ID sub-object.

So the condition you have pointed out is the case that may occur if the PLR is explicitly configured by policy not to include NodeID in the RRO. It should also be noted that even if PLR is configured not to include NodeID in RRO, the PLR can offer protection for the following failures.

1.       PLR nhop link failure

2.       Nhop node control plane failures that do not automatically result in LoS at the NP-MP

Hence, the draft does not specify inclusion of NodeID as a MUST condition.

Section 4.1.3:

"In addition to the above procedures, the node SHOULD check the presence of remote signaling adjacency with PLR. If a matching Bypass Summary FRR Extended Association object is found in the PATH and if the RSVP-TE signaling adjacency is also present, then the node concludes that the PLR will undertake refresh-interval independent FRR procedures specified in this document."

What if PLR implements Summary FRR, but doesn't support RI-RSVP and has established signaling adjacency for purpose other than RI-RSVP? Should not MP analyze I-bit in NodeID-based Hello message from PLR, like PLR does for NodeID Hello messages received from MP?

[Chandra] I will modify the first sentence as the one below:

    In addition to the above procedures, the node SHOULD check the

    presence of remote signaling adjacency with RI-RSVP capable [TE-SCALE-REC] PLR.

"If the PLR has included NodeID sub-object in PATH RRO, then that NodeID is the remote neighbor address. Otherwise, the PLR's interface address in PATH RRO will be the remote neighbor address."

Maybe it should be said: "Otherwise, the address from Bypass_Source_IPv4_Address field of Bypass Summary FRR Extended Association object will be the remote neighbor address"? If not then in this case PLR will use another address (different from its one in RRO) as source for its bypass tunnel such that MP will not be able to match two interface addresses (one for remote neighbor address from RRO and another for bypass source address) of PLR in order to perform matching of Bypass Summary FRR Extended Association to NodeID hello adjacency. Also, if MP will use PLR's interface address from RRO, NodeID session probably will be broken in case of Nhop link/node failure on PLR.

[Chandra] It should be noted that if the PLR and the MP are in the same IGP area, the Bypass_source_IPv4_address field B-SFRR extended association object may also be an interface address (Of course, the interface address that PLR uses as the source address of the bypass tunnel will be different from the protected interface address – otherwise basic FRR will itself break). In such a case, the MP may utilize the TED to determine whether the Bypass_source_IPv4_address corresponds to the same node as the content of the node-id sub-object included by the PLR. I will add the following text to this paragraph to clarify this.

    In addition to the above procedures, the node SHOULD check the

    presence of remote signaling adjacency with PLR. If a matching

    Bypass Summary FRR Extended Association object is found in the PATH

    and if the RSVP-TE signaling adjacency is also present, then the

    node concludes that the PLR will undertake refresh-interval

    independent FRR procedures specified in this document. If the PLR

    has included NodeID sub-object in PATH RRO, then that NodeID is the

    remote neighbor address. Otherwise, the PLR's interface address in

    PATH RRO will be the remote neighbor address. In order to enable

    the MP to match the bypass source address in B-SFRR Extended

    Association object with the RSVP-TE signaling adjacency with the

    PLR, the bypass source address in B-SFRR Extended Association object

    should either be (a) the same as the PLR’s address used for Hello

    messages of RSVP-TE signaling adjacency or, (b) attached on the same

    node on TED as the PLR’s address used for Hello messages of RSVP-TE

    signaling adjacency.

Section 4.4.2:

"When a router that has already made NP available detects a change in the RRO carried in RESV message, and if the RRO change indicates that the router's former NP-MP is no longer present in the LSP path, then the router SHOULD send "Remote" PathTear directly to its former NP-MP."

What if MP doesn't signal its NodeID in Resv RRO, and PLR and MP are in different areas? In this case it could be that "old" and "new" NNhops in fact are the same node.

[Chandra] This has already been discussed at length in Section 4.1.1 itself (on how to select the destination address for bypass LSP) and will only be a repetition in Section 4.4.2.


It is clear that if neighbor doesn't signal I-bit then it doesn't support RI-RSVP-FRR. But what if it signals I-bit? It could mean that it supports RI-RSVP, but not RI-RSVP-FRR. Particularly, it could be that downstream neighbor doesn't support Conditional PathTear, and thus will treat Conditional PathTear as normal one.

[Chandra] As explained in Section 3, there are gaps in introducing refresh-interval independence to RFC 4090 facility FRR. Hence, if an implementation has to support both RFC 4090 facility FRR and RI-RSVP, then this draft should also be supported. In other words, the RI-RSVP flag means both draft in the context RFC 4090 facility FRR.

Previously, draft-ietf-teas-rsvp-te-scaling-rec (RI-RSVP) used to have text in Section 3 that mandated the support of draft-ietf-mpls-ri-rsvp-frr (see in the context of RFC 4090 facility FRR. The authors have subsequently removed the line based on a comment that the TEAS draft should be technology independent.

You point is valid and we will address this by making draft-ietf-mpls-ri-rsvp-frr semantically update the RI-RSVP flag in the context of RFC 4090 facility FRR. IOW draft-ietf-mpls-ri-rsvp-frr updates draft-ietf-teas-rsvp-te-scaling-rec.


"- If node protection is requested and the Phop node does not support the RI-RSVP-FRR extensions, then the node SHOULD reduce the "refresh period" in TIME_VALUES object carried in PATH to default value."

Was it meant RESV in place of PATH?

[Chandra] TIME_VALUES object in both PATH and RESV should be modified to carry short refresh interval. This is illustrated in the following portion of an LSP.

… R11 ---- R12 --- R13 ---

R11 does not support RI-RSVP whereas R12 and R13 do. If R12 did not use short refresh interval for signaling PATH messages to R13, then on R13 there will be disparity between the refresh periods of primary PATH arriving from R12 and the backup LSP PATH arriving from R11 after any failure. The benefits of long refresh would anyway be lost once R11 signals backup PATH to R13. Hence, instead of requiring R13 to handle the switch from long to short refresh after a failure in the network, it is recommended to have the refresh periods consistent across failures.

In summary, if there is a router not supporting RI-RSVP in the network, then the “impact” radius will be (a) one in both upstream & downstream directions along with LSP path for LSPs requesting link protection, and (b) two in both upstream & downstream directions along with LSP path for LSPs requesting node protection.



Thank you.
29.01.2018 16:40, Chandrasekar Ramachandran пишет:
Hi Alexander,
RI-RSVP-FRR specification does not remove the backup LSP signaling but only uses B-SFRR association to enable the PLR to signal availability of local protection to the corresponding Merge Point (MP). The MP does not carry B-SFRR association back to the PLR for the actual FRR summarization. RI-RSVP-FRR aims to remove the dependencies that facility FRR has on a short refresh interval. So, with these extensions the LSP states on the Merge Point can remain long enough to ensure that PLR is not time constrained to schedule backup LSP signaling immediately.

Your comment/question though is relevant to the actual FRR summarization (i.e. summary-frr draft) where the PLR does not have to send the entire backup LSP Path message to the MP after the failure.


From: mpls [] On Behalf Of Alexander Okonnikov
Sent: Saturday, January 27, 2018 3:25 AM
To: Mike Taillon (mtaillon) <><>
Subject: Re: [mpls] WGLC for draft-ietf-mpls-ri-rsvp-frr-02


What about signaling of MTU, which in regular facility FRR is conveyed in ADSPEC within Path of backup LSP. Per my understanding with proposed solution this information is being lost. Maybe it could be done by signaling MTU in SUMMARY_FRR_BYPASS object and specifying procedure for MP regarding modifying ADSPEC objects of the protected LSPs.

Thank you.

26 янв. 2018 г., в 20:04, Mike Taillon (mtaillon) <<>> написал(а):

I have reviewed the latest version of this document and believe this is ready to progress to the next stage.
-Mike (as a contributor)

On Jan 10, 2018, at 9:56 AM,<> wrote:

Working Group,

This is to initiate a two week MPLS working group last call in on

Please send your comments to the mpls wg mailing list (<>).

Please note that there is already one IPR disclosed for the individual

All the authors and contributors have stated on the working group
mailing list that they are not aware of any other IPRs that relates to
this document.

As with any WGLC, working group participants are requested to read
the document and comment. If you feel that the document is ready
for publication, it is appropriate to respond to the WGLC with a short
and simple email indicating support.

This working group last call ends January 24th, 2018.



mpls mailing list<><>

mpls mailing list<><>