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

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:mpls-bounces@ietf.org] *On Behalf Of *Alexander 
> Okonnikov
> *Sent:* Saturday, January 27, 2018 3:25 AM
> *To:* Mike Taillon (mtaillon) <mtaillon@cisco.com>
> *Cc:* mpls@ietf.org; mpls-chairs@ietf.org
> *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)
>     <mtaillon@cisco.com <mailto:mtaillon@cisco.com>> написал(а):
>
>     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, N.Leymann@telekom.de
>         <mailto:N.Leymann@telekom.de> 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
>         (mpls@ietf.org <mailto:mpls@ietf.org>).
>
>         Please note that there is already one IPR disclosed for the
>         individual
>
>         document:
>
>         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=>
>
>         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@ietf.org <mailto:mpls@ietf.org>
>         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=>
>
>     _______________________________________________
>     mpls mailing list
>     mpls@ietf.org <mailto:mpls@ietf.org>
>     https://www.ietf.org/mailman/listinfo/mpls
>