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

From: Chandrasekar Ramachandran <[email-masked]>
Date: Thu, 8 Feb 2018 18:49:00 +0000

Hi Alexander,
Please refer to my responses inline.

From: Alexander Okonnikov [mailto:[email-masked]]
Sent: Monday, January 29, 2018 7:31 PM
To: Chandrasekar Ramachandran <[email-masked]>; Mike Taillon (mtaillon) <[email-masked]>
Cc: [email-masked]; [email-masked]
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.

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.

[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 https://tools.ietf.org/html/draft-ietf-teas-rsvp-te-scaling-rec-02) 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.

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?

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

Thanks,

Chandra.

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]><mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[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)

On Jan 10, 2018, at 9:56 AM, [email-masked]<mailto:[email-masked]> 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 ([email-masked]<mailto:[email-masked]>).

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
[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=>

_______________________________________________
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=DwMDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=iEQmXlRGWdNbtvVr6ghcatwLYhZUbMF-u63wi_-VTtA&m=qOtXhu4o1urgFIp2tneOy0W2FUPVH1vUrMqjwASJuIU&s=QGooQgdSL_viQdGJavb9u63_lo5hVN_PuDNN40mRCsw&e=>

---

From: <[email-masked]>
Date: Fri, 9 Feb 2018 07:30:51 +0000

Hi,

The WGLC for draft-ietf-mpls-ri-rsvp-frr-02 is closed. I think we can move forward - there was support on the mailing list.
But there are also some comments which need to be taken into account.  Can the authors please address the comments
and post an updated version of the document.

Regards

Nic

Von: Leymann, Nicolai
Gesendet: Mittwoch, 10. Januar 2018 15:57
An: [email-masked]
Cc: [email-masked]; [email-masked]
Betreff: WGLC for draft-ietf-mpls-ri-rsvp-frr-02

Working Group,

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

Regards

Nic

---

From: Alexander Okonnikov <[email-masked]>
Date: Sat, 10 Feb 2018 21:33:17 +0300

Hi Chandra,

My comments inline.

> 8 февр. 2018 г., в 21:49, Chandrasekar Ramachandran <[email-masked]> написал(а):
> 
> Hi Alexander,
> From: Alexander Okonnikov [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Chandrasekar Ramachandran <[email-masked] <mailto:[email-masked]>>; Mike Taillon (mtaillon) <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
Here I said about not inclusion of NodeID by MP in RESV RRO, not by PLR.

Per RFC 4090, backup LSP cannot traverse protected node and/or link. In many cases link between protected node and MP will also be protected link (as part of protected node). Unless MP's phop link is LAN, and backup LSP's upstream hop is on the same LAN and different from protected node, backup LSP will be broken in case of node failure.

>     node on TED as the PLR’s address used for Hello messages of RSVP-TE
What about follow sentence? "Otherwise, the PLR's interface address in PATH RRO will be the remote neighbor address."

If the PLR has been established adjacency from its IP address that is present in PATH RRO (i.e. IP address of protected link), then after failure the adjacency will be broken. As a result, MP will remove normal and remote path state.

My point here is that PLR must not establish NodeID hello session using IP address of protected link.

> [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. 
I feel that I need to provide example here. R1 and R3 are in different areas, R2 and R4 are ABRs. R3 doesn't insert its NodeID in RESV RRO.

R1-----R2-----R3
 |      |     |
 +-----R4-----+

Before failure R1 receives RESV RRO that contains R3's R3->R2 address. Then link R2-R3 had been broken, and R2 has activated FRR and signaled backup LSP R2-R4-R3. As a result R1 now receives RESV RRO with R3's R3->R4 address. As soon as R3's R3->R2 address is not present in RESV RRO, R1 concludes that R3 is not present on LSP path anymore. Hence it sends remote PathTear to R3.

My point here is that PLR can use this procedure, unless NP-MP is in different area and doesn't insert its NodeID in RESV RRO. I.e. in this case PLR is not able to identify whether new and old NNhops are the same node or two different ones.
> 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 (seehttps://tools.ietf.org/html/draft-ietf-teas-rsvp-te-scaling-rec-02 <https://tools.ietf.org/html/draft-ietf-teas-rsvp-te-scaling-rec-02>) 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.
> 
> From: mpls [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Alexander Okonnikov
> To: Mike Taillon (mtaillon) <[email-masked]> <mailto:[email-masked]>
> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> 26 янв. 2018 г., в 20:04, Mike Taillon (mtaillon) <[email-masked] <mailto:[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://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=>
>  
> [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=>
>  
> [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=DwMDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=iEQmXlRGWdNbtvVr6ghcatwLYhZUbMF-u63wi_-VTtA&m=qOtXhu4o1urgFIp2tneOy0W2FUPVH1vUrMqjwASJuIU&s=QGooQgdSL_viQdGJavb9u63_lo5hVN_PuDNN40mRCsw&e=>
>  
>

---

From: Chandrasekar Ramachandran <[email-masked]>
Date: Mon, 26 Feb 2018 14:51:30 +0000

Hi Alexander,
Sorry about the delay in responding. Please see inline. If the proposed modifications are acceptable, then I will make the update in the next version soon.

Thanks,
Chandra.

From: Alexander Okonnikov [mailto:[email-masked]]
Sent: Sunday, February 11, 2018 12:03 AM
To: Chandrasekar Ramachandran <[email-masked]>
Cc: [email-masked]; [email-masked]; Vishnu Pavan Beeram <[email-masked]>
Subject: Re: [mpls] WGLC for draft-ietf-mpls-ri-rsvp-frr-02

Hi Chandra,

My comments inline.

8 февр. 2018 г., в 21:49, Chandrasekar Ramachandran <[email-masked]<mailto:[email-masked]>> написал(а):

Hi Alexander,

To: Chandrasekar Ramachandran <[email-masked]<mailto:[email-masked]>>; Mike Taillon (mtaillon) <[email-masked]<mailto:[email-masked]>>

Hi Chandra,

Merger -> Merge

Section 4.1.1:

[Chandra] How about changing the paragraph to the following?

    -  While selecting the destination address of the bypass LSP, the
     PLR SHOULD select the router ID of the NNhop or Nhop node set
      in the NodeID sub-object included in RRO of RESV. If the MP has
      not included NodeID sub-object in RESV RRO and if the PLR and
      the MP are in same area, then the PLR may utilize the TED to
      determine the router ID from the interface address in RRO. If the
      NP-MP in a different area has not included NodeID in RRO, then the
      PLR SHOULD NOT execute the procedures specified in this document
      because the PLR cannot reliably determine an MP address that does
      not share fate of the protected LSP.

The above text in effect recommends a router always include its NodeID sub-object in the RRO object carried in PATH as well as RESV message – as one of additional recommendations over RFC 4090 to support FRR with RI-RSVP. Please see next response.

Section 4.1.3:

    signaling adjacency.

[Chandra] Yes, I will remove that sentence. How about the following as the opening paragraphs under Section 4.1.3?

    With regard to the MP procedures that are specified in
    RFC 4090<https://tools.ietf.org/html/rfc4090>, this document specifies the following additional
    procedures.

    Each router supporting this document SHOULD also include its
    router ID in a NodeID sub-object in RRO object carried in the
    RESV message unless configured explicitly not to include NodeID.
    If the router does not include NodeID in RESV RRO and if the
    PLR is in a different IGP area, then the router SHOULD NOT
    execute the MP procedures specified in this document.

The above text is the counterpart for the proposed text for PLR procedures (in addition to RFC 4090 procedures) in the previous response above.
Section 4.4.2:

R1-----R2-----R3
 |      |     |
 +-----R4-----+

[Chandra] The backup LSP PATH is from a different Sender and is a logically separate state (though tied to the primary PATH). Hence R2 should not send remote PathTear to R3. You have made a good point because that is somewhat unclear in the draft. Would the following text in Section 4.4.2 clarify this?

    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. However, the change in RRO carried in backup LSP RESV message
    that a router detects during local repair actions must be handled as
    per RFC 4090.

[Chandra] The clarifying text above should address the confusion?

Section 4.5.2.1:

[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 (seehttps://tools.ietf.org/html/draft-ietf-teas-rsvp-te-scaling-rec-02<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dteas-2Drsvp-2Dte-2Dscaling-2Drec-2D02&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=iEQmXlRGWdNbtvVr6ghcatwLYhZUbMF-u63wi_-VTtA&m=wfWRjYko2S0Ze3RznOMyQDWN2koviAgzgwPJxbJ-Dp8&s=kDHxZ7eLH490Pyb0NhegZ97C6I3bL5hz2gAZIrqt3nU&e=>) 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.

Section 4.5.2.2:

Thanks,
Chandra.

Thank you.

Thanks,
Chandra.

Hi,

Thank you.

Working Group,

Regards

Nic

---

From: Alexander Okonnikov <[email-masked]>
Date: Wed, 28 Feb 2018 18:48:46 +0300

Hi Chandra,

Please, see inline.

Thank you.

26.02.2018 17:51, Chandrasekar Ramachandran пишет:
>
> Hi Alexander,
>
> Sorry about the delay in responding. Please see inline. If the 
> proposed modifications are acceptable, then I will make the update in 
> the next version soon.
>
> Thanks,
>
> Chandra.
>
> *From:*Alexander Okonnikov [mailto:[email-masked]]
> *Sent:* Sunday, February 11, 2018 12:03 AM
> *To:* Chandrasekar Ramachandran <[email-masked]>
> *Cc:* [email-masked]; [email-masked]; Vishnu Pavan Beeram 
> <[email-masked]>
> *Subject:* Re: [mpls] WGLC for draft-ietf-mpls-ri-rsvp-frr-02
>
> Hi Chandra,
>
> My comments inline.
>
>
>
>     8 февр. 2018 г., в 21:49, Chandrasekar Ramachandran
>     <[email-masked] <mailto:[email-masked]>> написал(а):
>
>     Hi Alexander,
>
>     *From:*Alexander Okonnikov [mailto:[email-masked]]
>     *Sent:*Monday, January 29, 2018 7:31 PM
>     *To:*Chandrasekar Ramachandran <[email-masked]
>     <mailto:[email-masked]>>; Mike Taillon (mtaillon)
>     <[email-masked] <mailto:[email-masked]>>
>     *Cc:[email-masked] <mailto:[email-masked]>;[email-masked]
>     <mailto:[email-masked]>
>     *Subject:*Re: [mpls] WGLC for draft-ietf-mpls-ri-rsvp-frr-02
>
>     Hi Chandra,
>
>     */[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."
>
>     */[Chandra] Inclusion of NodeID in RRO is a SHOULD clause in the
>     draft./*
>
>     */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./*
>
> Per RFC 4090, backup LSP cannot traverse protected node and/or link. 
> In many cases link between protected node and MP will also be 
> protected link (as part of protected node). Unless MP's phop link is 
> LAN, and backup LSP's upstream hop is on the same LAN and different 
> from protected node, backup LSP will be broken in case of node failure.
>
> */[Chandra] How about changing the paragraph to the following?/*
> *//*
>
> */The above text in effect recommends a router always include its 
> NodeID sub-object in the RRO object carried in PATH as well as RESV 
> message – as one of additional recommendations over RFC 4090 to 
> support FRR with RI-RSVP. Please see next response./*
I am OK with this change.
>
>
>     Section 4.1.3:
>
>     "In addition to the above procedures, the node SHOULD check the
>     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:/*
>
>     "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./*
>
>         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._*
>
> What about follow sentence? "Otherwise, the PLR's interface address in 
> PATH RRO will be the remote neighbor address."
>
> If the PLR has been established adjacency from its IP address that is 
> present in PATH RRO (i.e. IP address of protected link), then after 
> failure the adjacency will be broken. As a result, MP will remove 
> normal and remote path state.
>
> */[Chandra] Yes, I will remove that sentence. How about the following 
> as the opening paragraphs under Section 4.1.3?/*
>
> *//*
>
> RFC 4090 <https://tools.ietf.org/html/rfc4090>, this document 
> specifies the following additional
>
>     procedures.
>
> */The above text is the counterpart for the proposed text for PLR 
> procedures (in addition to RFC 4090 procedures) in the previous 
> response above./*
>
/*OK.*/
>
>     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./*
>
> I feel that I need to provide example here. R1 and R3 are in different 
> areas, R2 and R4 are ABRs. R3 doesn't insert its NodeID in RESV RRO.
>
> R1-----R2-----R3
>
>  |  |     |
>
>  +-----R4-----+
>
> Before failure R1 receives RESV RRO that contains R3's R3->R2 address. 
> Then link R2-R3 had been broken, and R2 has activated FRR and signaled 
> backup LSP R2-R4-R3. As a result R1 now receives RESV RRO with R3's 
> R3->R4 address. As soon as R3's R3->R2 address is not present in RESV 
> RRO, R1 concludes that R3 is not present on LSP path anymore. Hence it 
> sends remote PathTear to R3.
>
> */[Chandra] The backup LSP PATH is from a different Sender and is a 
> logically separate state (though tied to the primary PATH). Hence R2 
> should not send remote PathTear to R3. You have made a good point 
> because that is somewhat unclear in the draft. Would the following 
> text in Section 4.4.2 clarify this?/*
>
/*I was talking about sending remote PathTear by R1, not by R2. Before 
failure R1 is receiving Resv RRO as R3'-R2. After failure and signaling 
backup LSP by R2 it is receiving Resv RRO R3''-R4-R2. Here R3' is IP 
address of R3 on interface R3->R2 and R3'' is IP address of R3 on 
interface R3-R4. If R3 is not inserting NodeID in Resv RRO, R1 can't 
understand that R3' and R3'' are both the same node (R3).
*/
> *//*
> *//*
>     NP-MP. *_However, the change in RRO carried in backup LSP RESV 
> message_*
>
> *_    that a router detects during local repair actions must be 
> handled as_*
>
> *_    per RFC 4090._*
>
> *//*
>
> My point here is that PLR can use this procedure, unless NP-MP is in 
> different area and doesn't insert its NodeID in RESV RRO. I.e. in this 
> case PLR is not able to identify whether new and old NNhops are the 
> same node or two different ones.
>
> *//*
>
> */[Chandra] The clarifying text above should address the confusion? /*
>

/*Not specific to this section, but to the whole draft itself. May be it 
would be better near beginning of the draft to state as a prerequisite 
that all LSRs must include their NodeID into Path and Resv RROs, unless 
they could determine NodeID of each other by some other means. Otherwise 
the solution must not be utilized. Then in the body of the draft to omit 
cases when PLR and/or MP are not including their NodeID. Also, removing 
cases when remote adjacency is being established on non-NodeID addresses 
will avoid establishing of multiple remote adjacencies between a pair of 
LSRs.*/
>
> *//*
>
>
>     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.
>
>     */[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/**/https://tools.ietf.org/html/draft-ietf-teas-rsvp-te-scaling-rec-02/*
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dteas-2Drsvp-2Dte-2Dscaling-2Drec-2D02&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=iEQmXlRGWdNbtvVr6ghcatwLYhZUbMF-u63wi_-VTtA&m=wfWRjYko2S0Ze3RznOMyQDWN2koviAgzgwPJxbJ-Dp8&s=kDHxZ7eLH490Pyb0NhegZ97C6I3bL5hz2gAZIrqt3nU&e=>*/)
>     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./*
>
>
>     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."
>
>     */[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./*
>
>     *//*
>
>     */Thanks,/*
>
>     */Chandra./*
>
>
>     Thank you.
>
>         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]>
>         <mailto:[email-masked]>
>         *Cc:[email-masked] <mailto:[email-masked]>;[email-masked]
>         <mailto:[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)
>
>                 On Jan 10, 2018, at 9:56 AM,[email-masked]
>                 <mailto:[email-masked]>wrote:
>
>                 Working Group,
>
>                 <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://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=>
>
>             https://www.ietf.org/mailman/listinfo/mpls
>             <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mpls&d=DwMDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=iEQmXlRGWdNbtvVr6ghcatwLYhZUbMF-u63wi_-VTtA&m=qOtXhu4o1urgFIp2tneOy0W2FUPVH1vUrMqjwASJuIU&s=QGooQgdSL_viQdGJavb9u63_lo5hVN_PuDNN40mRCsw&e=>
>

---

From: Chandrasekar Ramachandran <[email-masked]>
Date: Wed, 28 Feb 2018 15:58:47 +0000

Hi Alexander,
Please see inline.

Thanks,
Chandra.

Sent: Wednesday, February 28, 2018 9:19 PM

Hi Chandra,

Please, see inline.

Thank you.

Thanks,
Chandra.

From: Alexander Okonnikov [mailto:[email-masked]]
Sent: Sunday, February 11, 2018 12:03 AM
To: Chandrasekar Ramachandran <[email-masked]><mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Vishnu Pavan Beeram <[email-masked]><mailto:[email-masked]>
Subject: Re: [mpls] WGLC for draft-ietf-mpls-ri-rsvp-frr-02

Hi Chandra,

My comments inline.

Hi Alexander,

Hi Chandra,

Merger -> Merge

Section 4.1.1:

Section 4.1.3:

    signaling adjacency.

    With regard to the MP procedures that are specified in
    RFC 4090<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc4090&d=DwMDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=iEQmXlRGWdNbtvVr6ghcatwLYhZUbMF-u63wi_-VTtA&m=T65i8EMHLU8ObCceVRWi_OwEWo5Wid3fKN72TAGgxB4&s=rdQWQ8nNflyxhpgEyo1EKwsXzg_ReOXi4f95x5FmkWs&e=>, this document specifies the following additional
    procedures.

OK.

Section 4.4.2:

R1-----R2-----R3
 |      |     |
 +-----R4-----+

[Chandra] The backup LSP PATH is from a different Sender and is a logically separate state (though tied to the primary PATH). Hence R2 should not send remote PathTear to R3. You have made a good point because that is somewhat unclear in the draft. Would the following text in Section 4.4.2 clarify this?
I was talking about sending remote PathTear by R1, not by R2. Before failure R1 is receiving Resv RRO as R3'-R2. After failure and signaling backup LSP by R2 it is receiving Resv RRO R3''-R4-R2. Here R3' is IP address of R3 on interface R3->R2 and R3'' is IP address of R3 on interface R3-R4. If R3 is not inserting NodeID in Resv RRO, R1 can't understand that R3' and R3'' are both the same node (R3).

[Chandra] Actually it is a typo – I wanted to mention “R1 should not send Remote PathTear to R3.” The text proposed below will make it explicit because backup LSP signaling during local repair in a way involves some change to Resv RRO. Please see my next response.

Not specific to this section, but to the whole draft itself. May be it would be better near beginning of the draft to state as a prerequisite that all LSRs must include their NodeID into Path and Resv RROs, unless they could determine NodeID of each other by some other means. Otherwise the solution must not be utilized. Then in the body of the draft to omit cases when PLR and/or MP are not including their NodeID. Also, removing cases when remote adjacency is being established on non-NodeID addresses will avoid establishing of multiple remote adjacencies between a pair of LSRs.

[Chandra] I’m okay with adding such text in Section 4.1.2 Remote Signaling Adjacency. I guess that should be fine with you too?
BTW, after the two proposed changes above, there will not be any text in the draft that mentions anything about “interface address” instead of node-id.

Section 4.5.2.1:

Section 4.5.2.2:

Thanks,
Chandra.

Thank you.

Thanks,
Chandra.

Hi,

Thank you.

Working Group,

Regards

Nic

---

From: Alexander Okonnikov <[email-masked]>
Date: Wed, 28 Feb 2018 20:08:47 +0300

Hi Chandra,

Inline.

28.02.2018 18:58, Chandrasekar Ramachandran пишет:
> *Sent:* Wednesday, February 28, 2018 9:19 PM
>     proposed modifications are acceptable, then I will make the update
>     in the next version soon.
>
>     Thanks,
>
>     Chandra.
>
>     <mailto:[email-masked]>
>     *Cc:* [email-masked] <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>; Vishnu Pavan Beeram
>     <[email-masked]> <mailto:[email-masked]>
>         I'm sorry. Yes, I mixed these two drafts. Follow is my
>         comments for draft-ietf-mpls-ri-rsvp-frr-02:
>
>         Section 2:
>
>         "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."
>
>         */[Chandra] Inclusion of NodeID in RRO is a SHOULD clause in
>         the draft./*
>
>         */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./*
>
>         */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./*
>
>     Per RFC 4090, backup LSP cannot traverse protected node and/or
>     link. In many cases link between protected node and MP will also
>     be protected link (as part of protected node). Unless MP's phop
>     link is LAN, and backup LSP's upstream hop is on the same LAN and
>     different from protected node, backup LSP will be broken in case
>     of node failure.
>
>     NodeID sub-object in the RRO object carried in PATH as well as
>     RESV message – as one of additional recommendations over RFC 4090
>     to support FRR with RI-RSVP. Please see next response./*
>
>         "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."
>
>         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./*
>
>             PATH RRO will be the remote neighbor address. *_In order
>         to enable_*
>
>         *_    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_*
>
>     What about follow sentence? "Otherwise, the PLR's interface
>     address in PATH RRO will be the remote neighbor address."
>
>     If the PLR has been established adjacency from its IP address that
>     is present in PATH RRO (i.e. IP address of protected link), then
>     after failure the adjacency will be broken. As a result, MP will
>     remove normal and remote path state.
>
>     */[Chandra] Yes, I will remove that sentence. How about the
>     following as the opening paragraphs under Section 4.1.3?/*
>
>     *//*
>
>     RFC 4090
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc4090&d=DwMDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=iEQmXlRGWdNbtvVr6ghcatwLYhZUbMF-u63wi_-VTtA&m=T65i8EMHLU8ObCceVRWi_OwEWo5Wid3fKN72TAGgxB4&s=rdQWQ8nNflyxhpgEyo1EKwsXzg_ReOXi4f95x5FmkWs&e=>,
>     this document specifies the following additional
>
>         procedures.
>
> */OK./*
>         "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./*
>
>     I feel that I need to provide example here. R1 and R3 are in
>     different areas, R2 and R4 are ABRs. R3 doesn't insert its NodeID
>     in RESV RRO.
>
>     R1-----R2-----R3
>
>      |      |     |
>
>      +-----R4-----+
>
>     Before failure R1 receives RESV RRO that contains R3's R3->R2
>     address. Then link R2-R3 had been broken, and R2 has activated FRR
>     and signaled backup LSP R2-R4-R3. As a result R1 now receives RESV
>     RRO with R3's R3->R4 address. As soon as R3's R3->R2 address is
>     not present in RESV RRO, R1 concludes that R3 is not present on
>     LSP path anymore. Hence it sends remote PathTear to R3.
>
>     */[Chandra] The backup LSP PATH is from a different Sender and is
>     a logically separate state (though tied to the primary PATH).
>     Hence R2 should not send remote PathTear to R3. You have made a
>     good point because that is somewhat unclear in the draft. Would
>     the following text in Section 4.4.2 clarify this?/*
>
> */I was talking about sending remote PathTear by R1, not by R2. Before 
> failure R1 is receiving Resv RRO as R3'-R2. After failure and 
> signaling backup LSP by R2 it is receiving Resv RRO R3''-R4-R2. Here 
> R3' is IP address of R3 on interface R3->R2 and R3'' is IP address of 
> R3 on interface R3-R4. If R3 is not inserting NodeID in Resv RRO, R1 
> can't understand that R3' and R3'' are both the same node (R3).
>
> /*
>
> */[Chandra] Actually it is a typo – I wanted to mention “R1 should not 
> send Remote PathTear to R3.” The text proposed below will make it 
> explicit because backup LSP signaling during local repair in a way 
> involves some change to Resv RRO. Please see my next response./*
>
/*I'm not sure that have understood you. What do you mean by saying that 
RRO of backup LSP must be handled as per RFC 4090. In RFC 4090 I can 
only see section 6.5 which describes handling of RRO by PLR. Several 
implementations of PLR update RRO being sent to upstream router by 
replacing RRO part of protected LSP from PLR to Tail-end by RRO from 
backup LSP.

In the example above R1 is PLR regarding NP-MP R3. Once R2 has signaled 
backup LSP (after R2-R3 link failure) to R3, R2 is sending updated RRO 
in Resv of protected LSP. Per section 4.4.2 of the draft, R1, as a PLR 
for NP-MP, is detecting absence of NP-MP in RRO and thus is sending 
remote PathTear to R3. R1 has not signaled backup LSP and has deal only 
with Resv RRO of protected LSP. I don't understand how RFC 4090 will 
help here.
*/
>     My point here is that PLR can use this procedure, unless NP-MP is
>     in different area and doesn't insert its NodeID in RESV RRO. I.e.
>     in this case PLR is not able to identify whether new and old
>     NNhops are the same node or two different ones.
>
>     *//*
>
> */Not specific to this section, but to the whole draft itself. May be 
> it would be better near beginning of the draft to state as a 
> prerequisite that all LSRs must include their NodeID into Path and 
> Resv RROs, unless they could determine NodeID of each other by some 
> other means. Otherwise the solution must not be utilized. Then in the 
> body of the draft to omit cases when PLR and/or MP are not including 
> their NodeID. Also, removing cases when remote adjacency is being 
> established on non-NodeID addresses will avoid establishing of 
> multiple remote adjacencies between a pair of LSRs./*
>
> */[Chandra] I’m okay with adding such text in Section 4.1.2 Remote 
> Signaling Adjacency. I guess that should be fine with you too?/*
>
> */BTW, after the two proposed changes above, there will not be any 
> text in the draft that mentions anything about “interface address” 
> instead of node-id./*
>
>
>         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.
>
>         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 semantically update the RI-RSVP
>         flag in the context of RFC 4090 facility FRR. IOW
>         support the RI-RSVP-FRR extensions, then the node SHOULD
>         reduce the "refresh period" in TIME_VALUES object carried in
>         PATH to default value."
>
>         modified to carry short refresh interval. This is illustrated
>         in the following portion of an LSP./*
>
>         *//*
>
>         */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./*
>
>         *//*
>
>         */Thanks,/*
>
>         */Chandra./*
>
>
>         Thank you.
>
>             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.
>
>             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.
>
>             *Cc:[email-masked]
>             <mailto:[email-masked]>;[email-masked]
>             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
>                 написал(а):
>                 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)
>
>                     Please send your comments to the mpls wg mailing
>                     list ([email-masked] <mailto:[email-masked]>).
>