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

From: <[email-masked]>
Date: Wed, 10 Jan 2018 14:56:59 +0000

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 ([email-masked]<mailto:[email-masked]>).

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

https://datatracker.ietf.org/ipr/2580/

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

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Fri, 19 Jan 2018 11:15:38 -0500

I have reviewed the latest version of this document and believe this is
ready to progress to the next stage.

Regards,
-Pavan (as a contributor)

On Wed, Jan 10, 2018 at 9:56 AM, <[email-masked]> wrote:

> Please send your comments to the mpls wg mailing list ([email-masked]*
> <[email-masked]>).
>
> *https://datatracker.ietf.org/ipr/2580/*
> <https://datatracker.ietf.org/ipr/2580/>
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>
>

---

From: Chandrasekar Ramachandran <[email-masked]>
Date: Fri, 19 Jan 2018 17:11:49 +0000

I believe (as one of the authors) the latest version of the document is ready for publication.

Chandra.

From: mpls [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, January 10, 2018 8:27 PM
To: [email-masked]
Cc: [email-masked]
Subject: [mpls] WGLC for draft-ietf-mpls-ri-rsvp-frr-02

Working Group,

https://datatracker.ietf.org/ipr/2580/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_ipr_2580_&d=DwMFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=iEQmXlRGWdNbtvVr6ghcatwLYhZUbMF-u63wi_-VTtA&m=E9zful9fgsnx5bRoemEzVG1E53f4JCm-91NWlOLH-0Q&s=FF-57rXrpWl4jpfMIUik_S6QElXRy65x_OIfj8JBWtc&e=>

Regards

Nic

---

From: "Tarek Saad (tsaad)" <[email-masked]>
Date: Thu, 25 Jan 2018 15:01:10 +0000

I have reviewed this document and I believe it is ready for WG last call.

Regards,
Tarek (as co-author)

From: "[email-masked]" <[email-masked]>
Date: Wednesday, January 10, 2018 at 9:57 AM
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Tarek Saad <[email-masked]>
Subject: WGLC for draft-ietf-mpls-ri-rsvp-frr-02
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, Tarek Saad <[email-masked]>, <[email-masked]>, <[email-masked]>
Resent-Date: Wednesday, January 10, 2018 at 9:57 AM

Working Group,

Regards

Nic

---

From: "Mike Taillon (mtaillon)" <[email-masked]>
Date: Fri, 26 Jan 2018 17:04:15 +0000

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, [email-masked]<mailto:[email-masked]> wrote:

Working Group,

Regards

Nic

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

---

From: Alexander Okonnikov <[email-masked]>
Date: Sat, 27 Jan 2018 00:55:11 +0300

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) <[email-masked]> написал(а):
> 
>> On Jan 10, 2018, at 9:56 AM, [email-masked] <mailto:[email-masked]> wrote:
>> 
>> Working Group,
>>  
>> Please send your comments to the mpls wg mailing list ([email-masked] <mailto:[email-masked]>).
>>  
>> https://datatracker.ietf.org/ipr/2580/ <https://datatracker.ietf.org/ipr/2580/>
>>  
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/mpls <https://www.ietf.org/mailman/listinfo/mpls>

---

From: Ravi Torvi <[email-masked]>
Date: Sun, 28 Jan 2018 14:35:23 +0000

Support - I believe the document in its current state is ready to progress
to the next stage.

Ravi

---

From: Chandrasekar Ramachandran <[email-masked]>
Date: Mon, 29 Jan 2018 13:40:15 +0000

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 [mailto:[email-masked]] On Behalf Of Alexander Okonnikov
Sent: Saturday, January 27, 2018 3:25 AM
To: Mike Taillon (mtaillon) <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] WGLC for draft-ietf-mpls-ri-rsvp-frr-02

Hi,

Thank you.

26 янв. 2018 г., в 20:04, Mike Taillon (mtaillon) <[email-masked]<mailto:[email-masked]>> написал(а):

Working Group,

https://datatracker.ietf.org/ipr/2580/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_ipr_2580_&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=iEQmXlRGWdNbtvVr6ghcatwLYhZUbMF-u63wi_-VTtA&m=eW0CpjEzVwQYj4blOzVet21naP3yv894yzb0eNsfzVQ&s=7c5J69aODGQPWNcc2zevUqG2W0dlgUrPv5fFe-BbGl4&e=>

Regards

Nic

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mpls&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=iEQmXlRGWdNbtvVr6ghcatwLYhZUbMF-u63wi_-VTtA&m=eW0CpjEzVwQYj4blOzVet21naP3yv894yzb0eNsfzVQ&s=laVW7-nrUNOG8Uqb8hb1Rxi5cHgbR1OgHAf-ikU5DsU&e=>

---

From: Alexander Okonnikov <[email-masked]>
Date: Mon, 29 Jan 2018 17:00:57 +0300

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

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.

Section 4.5.2.1:

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.

Section 4.5.2.2:

"- 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 [mailto:[email-masked]] *On Behalf Of *Alexander 
> Okonnikov
> *Sent:* Saturday, January 27, 2018 3:25 AM
> *To:* Mike Taillon (mtaillon) <[email-masked]>
> *Cc:* [email-masked]; [email-masked]
> *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)
>     <[email-masked] <mailto:[email-masked]>> написал(а):
>
>     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)
>
>         <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_ipr_2580_&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=iEQmXlRGWdNbtvVr6ghcatwLYhZUbMF-u63wi_-VTtA&m=eW0CpjEzVwQYj4blOzVet21naP3yv894yzb0eNsfzVQ&s=7c5J69aODGQPWNcc2zevUqG2W0dlgUrPv5fFe-BbGl4&e=>
>
>         <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mpls&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=iEQmXlRGWdNbtvVr6ghcatwLYhZUbMF-u63wi_-VTtA&m=eW0CpjEzVwQYj4blOzVet21naP3yv894yzb0eNsfzVQ&s=laVW7-nrUNOG8Uqb8hb1Rxi5cHgbR1OgHAf-ikU5DsU&e=>
>