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

Alexander Okonnikov <> Mon, 29 January 2018 14:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0226912EB55; Mon, 29 Jan 2018 06:01:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.709
X-Spam-Status: No, score=-0.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, 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 78a9M6X5v7Um; Mon, 29 Jan 2018 06:01:02 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4FC0412D84A; Mon, 29 Jan 2018 06:01:01 -0800 (PST)
Received: by with SMTP id h92so10117436lfi.7; Mon, 29 Jan 2018 06:01:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=ztCUsrknR42klVamrCVqLuJiL4Yrl/izKsugZ5mJnXE=; b=lwAZ9Q/ctop/6rm7NdVQ2WnajC02e5jnYfWLF5UmxERqYLnCKQLcVWNQC2R2ewWzMV FcLI6p5mj6cI9hyxdGS0+6gK96RHksp9Sc3gKrtfsHVu/cHUbdVK66AtGPHRu9YNRCdy NXvXQy4sxKM8T6Xr2BVKQdcCgLt31Lwsi50rU+lVW2DWo/E2psWTPV1lYJz9Mn4HXUjT o6F9qX8egg1DV0NDzmqwkO0XhyPNla/u4cfxQXRdRFSEnghC+DzNftb24AUEtTLSvvtl 0g58XXDCjF31oZoXUgxSc4vo4Yveb2z3wTYFxzvMwbZS54gH1Q40txHG7lwWNQgZwrnw 5teg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=ztCUsrknR42klVamrCVqLuJiL4Yrl/izKsugZ5mJnXE=; b=PY5k+Rpk/bR09h3Um3qYZQek2+qps9T9w7UC3OL9imvsPqFqifrAgMIJphYD1mSNuX HV4pH0p6G98yVq1/EWRmEFCxFIt68GBLxyZX8qEsOqIgGD2ZD05Arq/CvagJegvXknJO v5UQ2VTmsKgC3641NOGQnbLJGF++fenaljw5V3miUjKy6M5rJzoJ/RVL0RDZUkC0CfIs 4yyeF1HGGlheAcLJ9SirX7YfM41chR2ovNswpo0mjTpR5BVcyPYmqYDC8fs4OCTKaNcf p5uB0zsj5G9QcdvLUkgBXbkRg6ll6FnWO8IlzJ6y44wGioauYZ/Ckg4/gyoLipy6IYig h23g==
X-Gm-Message-State: AKwxytekD5JoIXP0ztHt/WVRqRzbyypkaLTX/QgGSPUKEwYkCu/xVZl1 ul1Pm14diwrIa0dHHQ9v8SjzLQ==
X-Google-Smtp-Source: AH8x227wSwnWHQo21CgF/fN7xcKGBNhQqAEnxP3XjwnjCVfo5cJNm0MGkRLYDKLHxFQhDcJbvjhUFA==
X-Received: by with SMTP id g73mr13912146ljg.75.1517234459089; Mon, 29 Jan 2018 06:00:59 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id i65sm2937810lfb.11.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Jan 2018 06:00:57 -0800 (PST)
To: Chandrasekar Ramachandran <>, "Mike Taillon (mtaillon)" <>
Cc: "" <>, "" <>
References: <FRXPR01MB040778B3FB1875A5130DF6B298110@FRXPR01MB0407.DEUPRD01.PROD.OUTLOOK.DE> <> <> <>
From: Alexander Okonnikov <>
Message-ID: <>
Date: Mon, 29 Jan 2018 17:00:57 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------E23BAAAEEECB9E9CD7A8F92E"
Content-Language: en-US
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: Mon, 29 Jan 2018 14:01:10 -0000

Hi Chandra,

I'm sorry. Yes, I mixed these two drafts. Follow is my comments for 

Section 2:

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

Merger -> Merge

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.

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?

"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.

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.


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.


"- 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?

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.
> Thanks,
> Chandra.
> *From:*mpls [] *On Behalf Of *Alexander 
> Okonnikov
> *Sent:* Saturday, January 27, 2018 3:25 AM
> *To:* Mike Taillon (mtaillon) <>
> *Cc:*;
> *Subject:* Re: [mpls] WGLC for draft-ietf-mpls-ri-rsvp-frr-02
> Hi,
> 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.
>     Regards,
>     -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
>         draft-ietf-mpls-ri-rsvp-frr-02.
>         Please send your comments to the mpls wg mailing list
>         ( <>).
>         Please note that there is already one IPR disclosed for the
>         individual
>         document:
>         <>
>         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.
>         Regards
>         Nic
>         _______________________________________________
>         mpls mailing list
> <>
>         <>
>     _______________________________________________
>     mpls mailing list
> <>