Subject: Re: [mpls] Working Group Last Call on draft-ietf-mpls-summary-frr-rsvpte

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Wed, 1 May 2019 12:26:25 +0000

Hi WG, Chairs,

I've reviewed this document and believe it is ready for publication.

Thanks,
Rakesh (as co-author)

From: "[email-masked]" <[email-masked]>
Date: Tuesday, April 30, 2019 at 4:34 AM
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Working Group Last Call on draft-ietf-mpls-summary-frr-rsvpte
Resent-From: <[email-masked]>
Resent-To: "=SMTP:mtaillon@cisco. com" <[email-masked]>, <[email-masked]>, "=SMTP:rgandhi@cisco. com" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Resent-Date: Tuesday, April 30, 2019 at 4:34 AM

Working Group,

This mail initiates the two weeks working group last call on draft-ietf-mpls-summary-frr-rsvpte which is considered mature and ready for a final working group review.

Please read this document if you haven't read the most recent version yet, and send your comments to the mpls wg mailing list ([email-masked]<mailto:[email-masked]>), not later than 17th of May.

There is one IPR disclosure against draft-ietf-mpls-summary-frr-rsvpte

This working group last call ends May 17th, 2019 (there is at least in some countries a public holiday this week, therefore the call is a bit longer than usual).

Best regards

Nic

---

From: Tarek Saad <[email-masked]>
Date: Mon, 6 May 2019 14:48:51 +0000

Hi WG,

I’ve reviewed this document and I think it is ready for publication.

Regards,
Tarek /as co-author

Working Group,

Best regards

Nic

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Mon, 6 May 2019 09:52:33 -0500

Nic,

I've reviewed (as a co-author) the current version of the document and I
believe it is ready to progress to the next stage.

Regards,
-Pavan

On Tue, Apr 30, 2019 at 3:34 AM <[email-masked]> wrote:

> Working Group,
>
>
>
> This mail initiates the two weeks working group last call on
> draft-ietf-mpls-summary-frr-rsvpte which is considered mature and ready
> for a final working group review.
>
>
>
> Please read this document if you haven't read the most recent version yet,
> and send your comments to the mpls wg mailing list ([email-masked]), not
> later than 17th of May.
>
>
>
> This working group last call ends May 17th, 2019 (there is at least in
> some countries a public holiday this week, therefore the call is a bit
> longer than usual).
>
>
>
> Best regards
>
>
>
> Nic
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: Abhishek Deshmukh <[email-masked]>
Date: Tue, 7 May 2019 20:27:51 +0000

Hi WG,

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

Thanks,
Abhishek (co-author)

Resent-To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, Markus Jork <[email-masked]>, "[email-masked]" <[email-masked]>

Working Group,

Best regards

Nic

---

From: "Mike Taillon (mtaillon)" <[email-masked]>
Date: Tue, 7 May 2019 20:32:52 +0000

Hi WG,

Regards,
Mike /as co-author

On Apr 30, 2019, at 4:33 AM, [email-masked]<mailto:[email-masked]> wrote:

Working Group,

Best regards

Nic

---

From: Markus Jork <[email-masked]>
Date: Tue, 7 May 2019 16:46:13 -0400

As a co-author,  I believe this document is ready for publication.
-Markus

> On Apr 30, 2019, at 4:33 AM, [email-masked] wrote:
>
> Working Group,
>

---

From: Alexander Okonnikov <[email-masked]>
Date: Tue, 7 May 2019 23:54:47 +0300

Hi authors,

As far as Summary FRR LSPs are not being signaled via Path messages over bypass tunnel after failure, information on head-ends about actual path MTU of protected LSPs can be corrupted. For example, path MTU of protected LSP is 1500 bytes (provided that ADSPEC is used), and path MTU of bypass tunnel is, for example, 1500 bytes. As far as Path messages for protected LSPs are not being sent over bypass tunnel, MP will use ADSPEC received in Path messages of those protected LSPs previoulsy (before they have been rerouted onto bypass tunnel), i.e. 1500 bytes in place of 1496 bytes. To avoid this problem PLR would have to signal path MTU of its bypass tunnel in B-SFRR-Active object (alternatively, MP could inherit this value from ADSPEC of PSB of the bypass tunnel), and 2) MP would have to choose minimal of MTU values from ADSPEC objects while merging Summary FRR protected LSP. But, even in this case MP will have to generate trigger Path messages (with updated ADSPEC) for protected LSPs and then, after receiving Resv messages with updated FLOWSPEC, send them to PLR. I.e. summary refresh in MP->PLR direction with high probability will be inapplicable, due to trigger messages.

Thanks.

> 7 мая 2019 г., в 23:46, Markus Jork <mjork=[email-masked]> написал(а):
> 
>> On Apr 30, 2019, at 4:33 AM, [email-masked] <mailto:[email-masked]> wrote:
>> 
>> Working Group,
>>  
>> Please read this document if you haven't read the most recent version yet, and send your comments to the mpls wg mailing list ([email-masked] <mailto:[email-masked]>), not later than 17th of May.
>>

---

From: "Mike Taillon (mtaillon)" <[email-masked]>
Date: Thu, 9 May 2019 12:28:40 +0000

Hi Alexander,

I beleive MTU handling post FRR is not covered in base RFC4090 and is therefore an existing gap.
It kinda defeats the purpose if headend needs to adjust MTU after FRR to prevent drops… and would presume most deployments assume that backup MTU can accomandate MTU of primary LSP (plus any added MP labels).

Issue deserves discussion, but think its out of scope from this document.

-mike

On May 7, 2019, at 4:54 PM, Alexander Okonnikov <[email-masked]<mailto:[email-masked]>> wrote:

Hi authors,

Thanks.

7 мая 2019 г., в 23:46, Markus Jork <mjork=[email-masked]<mailto:mjork=[email-masked]>> написал(а):

Working Group,

Best regards

Nic

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

---

From: Alexander Okonnikov <[email-masked]>
Date: Mon, 13 May 2019 18:31:33 +0300

Hi Mike,

Do you mean the gap in merging of Path messages by MP in part of choosing ADSPEC of protected LSP rather than merging ADSPECs (choosing minimal MTU, particularly)? Oh, agree. Though if we would assume that MP did perform merging of ADSPEC (and probably other objects where applicable), there would be problem with signaling backup LSP MTU to MP after failure.

I agree that guaranting enough MTU size on all links in the network is good practice, but in reality it not always could be provided, or could be provided with significant penalty on manageability.

Per my understanding, reliable solution would be for head-end:

1) to specify minimum LSP MTU as a constraint (like resource affinities, BW, etc.) for CSPF and take link MTUs from TEDB into consideration, and

2) to signal to downstream LSRs minimum LSP MTU (by virtue of SENDER_TSPEC, like BW), such that PLRs would be able to make decision about availability of bypass tunnels, which can accomodate requested MTU.

Thank you!

> 9 мая 2019 г., в 15:28, Mike Taillon (mtaillon) <[email-masked]> написал(а):
> 
> 
> Hi Alexander,
> 
>> On May 7, 2019, at 4:54 PM, Alexander Okonnikov <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi authors,
>> 
>>> 7 мая 2019 г., в 23:46, Markus Jork <mjork=[email-masked] <mailto:mjork=[email-masked]>> написал(а):
>>> 
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/mpls <https://www.ietf.org/mailman/listinfo/mpls>
>> 
>

---

From: "Mike Taillon (mtaillon)" <[email-masked]>
Date: Mon, 13 May 2019 17:38:25 +0000

Hi Alexander

By gap, I mean its not mentioned/covered at all.

To give alternate perspective, I disagree with trying to merge state of primary and backup LSP.
And would think it unncessary for either the MP or the headend to be aware, or make any MTU changes post FRR.

I do agree with your last statement where PLR should ensure the MTU of backup can accomdate the primary LSP MTU (plus any encap added to transport over the backup LSP).
And surely most implementations are already doing this, or FRR wouldn’t be that successful...

Do you not agree this issue/gap is out of scope of (ie. not specific to ) this document ?

-mike

On May 13, 2019, at 11:31 AM, Alexander Okonnikov <[email-masked]<mailto:[email-masked]>> wrote:

Hi Mike,

Thank you!

9 мая 2019 г., в 15:28, Mike Taillon (mtaillon) <[email-masked]<mailto:[email-masked]>> написал(а):

Hi Alexander,

-mike

Hi authors,

Thanks.

Working Group,

Best regards

Nic

---

From: Alexander Okonnikov <[email-masked]>
Date: Tue, 14 May 2019 15:21:27 +0300

Hi Mike,

If we don't talk about gap in procedure of Path messages merging by MP, then I don't see other gaps in RFC 4090. But I see that gap with MTU adjusting appears with introduction of Summary FRR.

Current behavior is follow:

1) PLR sends backup LSP Path to MP with actual MTU in ADSPEC;
2) MP sends backup LSP Resv to PLR with actual MTU in FLOWSPEC (derived from ADSPEC);
3) PLR merges FLOWSPECs of protected and backup Resv messages (according to RFC 2210) and sends Resv upstream with actual MTU in FLOWSPEC.

New behavior with Summary FRR:

1) PLR sends SFRR-Active Path to MP;
2) MP does summary refresh for backup LSPs;
3) PLR sends Resv with unchanged MTU of protected LSP upstream, as before failure. This is because FLOWSPEC for backup LSP has not been updated, and resulting FLOWSPEC thus has not been updated.

I cannot agree that head-end not need to be aware about path MTU changes. If head-end is irrespective to actual path MTU, it could cause blackholing of packets that are larger than actual path MTU. Also, I'm not aware about implementations of PLR that take into account MTU in SENDER_TSPEC of protected LSPs and choose bypass tunnels accordingly. My knowledge that many of them agnostic to this.

Thank you.

> 13 мая 2019 г., в 20:38, Mike Taillon (mtaillon) <[email-masked]> написал(а):
> 
> Hi Alexander
> 
>> On May 13, 2019, at 11:31 AM, Alexander Okonnikov <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Mike,
>> 
>>> 9 мая 2019 г., в 15:28, Mike Taillon (mtaillon) <[email-masked] <mailto:[email-masked]>> написал(а):
>>> 
>>> 
>>> Hi Alexander,
>>>

---

From: Tarek Saad <[email-masked]>
Date: Tue, 14 May 2019 15:16:04 +0000

Hi Alexander,

Thanks for your suggestions and comments. We discussed this further amongst authors. We think the PLR has to do a proactive check of the MTU on the bypass tunnel for proper FRR to work correctly at all times.
We will introduce an addition in section 3.3.1 of the I-D to describe this:

“When using procedures defined in this document, the PLR MUST ensure bypass tunnel assignment can satisfy the protected LSP MTU requirements post FRR. This is to avoid any packets from getting dropped due to exceeding the MTU size of the bypass tunnel after FRR.”

Let us know if this addresses your concerns.

Regards,
Tarek

From: Alexander Okonnikov <[email-masked]>
Date: Tuesday, May 14, 2019 at 8:21 AM
To: "Mike Taillon (mtaillon)" <[email-masked]>
Cc: Markus Jork <mjork=[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [mpls] Working Group Last Call on draft-ietf-mpls-summary-frr-rsvpte
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, Tarek Saad <[email-masked]>, Rakesh Gandhi <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Resent-Date: Tuesday, May 14, 2019 at 8:21 AM

Hi Mike,

Thank you.

13 мая 2019 г., в 20:38, Mike Taillon (mtaillon) <[email-masked]<mailto:[email-masked]>> написал(а):

Hi Alexander

-mike

Hi Mike,

Thank you!

Hi Alexander,

-mike

Hi authors,

Thanks.

Working Group,

Best 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=Kd6NW5ctLWr7GB646PVmMByvi8wQxPILpKhHvGQeRHY&m=8ugk0fj6GyOtsYCkrvM6x1jpwt7T7bGkBhQ9Le-SI6k&s=0zgSQxWhO9k94N9On89so_wtqNQ0mXruYDy6Dka6-Lc&e=>

---

From: Alexander Okonnikov <[email-masked]>
Date: Thu, 16 May 2019 14:43:44 +0300

Hi Tarek,

Thank you for answer. Yes, I'm fine with proposed update.

I have some comments regarding choosing address for RSVP_HOP and SENDER_TEMPLATE on PLR and MP.

1) The draft doesn't say that PLR should choose the same Sender address for SENDER_TEMPLATE of backup LSPs as chosen one for corresponding bypass tunnel. Hence it could be that two will be different. It will cause to use different sender address for SENDER_TEMPLATE by PLR and MP.

2) The draft doesn't say that address in RSVP_HOP for backup LSPs and address in SENDER_TEMPLATE for corresponding bypass tunnel should be different. Hence, it could be that addresses in RSVP_HOP of SFRR-Active and in SENDER_TEMPLATE of bypass tunnel are the same. In case when PLR is head-end, it could pose problem for MP in part of choosing sender address for SENDER_TEMPLATE of backup LSP. It could be presumed that address for RSVP_HOP in SFRR-Active is taken from egress transit interface for originated bypass tunnel, and address for SENDER_TEMPLATE of bypass tunnel is loopback address of PLR, and thus they will be different. But in case of unnumbered interface on PLR, that is used as egress by bypass tunnel, election of address for RSVP_HOP is not so straightforward. It could be well possible that for RSVP_HOP of backup LSPs the same loopback address of PLR will be chosen as for SENDER_TEMPLATE of bypass tunnel. Also, RFC 4090 doesn't prescribe how PLR chooses address for RSVP_HOP.

3) The draft says that all protected LSPs, that share the same egress link and are protected by the same bypass tunnel, are assigned to the same bypass group. It is not a problem, if mentioned above inconsitencies will be addressed. Otherwise, there could be problem, because, based on current text, all backup LSPs of the same group should share SENDER_TEMPLATE (i.e. Sender Address in SENDER_TEMPLATE). Though on MP there will be two groups of backup LSPs in the same bypass group: that take address for SENDER_TEMPLATE from SENDER_TEMPLATE of bypass tunnel (transit protected LSP), and that take address for SENDER_TEMPLATE from RSVP_HOP of SFRR-Active (for protected LSPs originated on PLR). For the latter SENDER_TEMPLATE on PLR and MP will be different.

4) The draft says that RSVP_HOP and SENDER_TEMPLATE for backup LSPs of the same bypass group should be the same. I guess that it should say that Sender Address in SENDER_TEMPLATE should be common, rather than SENDER_TEMPLATE itself. SENDER_TEMPLATE will be different for each backup LSP due to different LSP_IDs.

Hence, I would like to see details of choosing addresses for RSVP_HOP and SENDER_TEMPLATE of backup LSPs to be cleaned. Also, I think that it would be better to signal Sender Address for backup LSPs in SFRR-Active explicitly, rather than derive it by MP indirectly from SENDER_TEMPLATE of bypass tunnel.

Thank you.

> 14 мая 2019 г., в 18:16, Tarek Saad <[email-masked]> написал(а):
> 
> Hi Alexander,
>  
> From: Alexander Okonnikov <[email-masked] <mailto:[email-masked]>>
> To: "Mike Taillon (mtaillon)" <[email-masked] <mailto:[email-masked]>>
> Cc: Markus Jork <mjork=[email-masked] <mailto:mjork=[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> Resent-From: <[email-masked] <mailto:[email-masked]>>
> Resent-To: <[email-masked] <mailto:[email-masked]>>, Tarek Saad <[email-masked] <mailto:[email-masked]>>, Rakesh Gandhi <[email-masked] <mailto:[email-masked]>>, <[email-masked] <mailto:[email-masked]>>, <[email-masked] <mailto:[email-masked]>>, <[email-masked] <mailto:[email-masked]>>
>> 13 мая 2019 г., в 20:38, Mike Taillon (mtaillon) <[email-masked] <mailto:[email-masked]>> написал(а):
>>  
>> Hi Alexander 
>>  
>>>>>> 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=Kd6NW5ctLWr7GB646PVmMByvi8wQxPILpKhHvGQeRHY&m=8ugk0fj6GyOtsYCkrvM6x1jpwt7T7bGkBhQ9Le-SI6k&s=0zgSQxWhO9k94N9On89so_wtqNQ0mXruYDy6Dka6-Lc&e=>

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 18 May 2019 18:37:57 -0400

Hi WG,

I have reviewed and believe the draft is ready for publication.

Gyan S. Mishra
IT Network Engineering & Technology 
Verizon Communications Inc. (VZ)
13101 Columbia Pike FDC1 3rd Floor
Silver Spring, MD 20904
www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT
Phone: 301 502-1347
Email: [email-masked]

Sent from my iPhone

> On May 16, 2019, at 7:43 AM, Alexander Okonnikov <[email-masked]> wrote:
> 
> Hi Tarek,
> 
>>>> On May 13, 2019, at 11:31 AM, Alexander Okonnikov <[email-masked]> wrote:
>>>>  
>>>> Hi Mike,
>>>>  
>>>>>> On May 7, 2019, at 4:54 PM, Alexander Okonnikov <[email-masked]> wrote:
>>>>>>  
>>>>>> Hi authors,
>>>>>>  
>>>>>>>>> Please read this document if you haven't read the most recent version yet, and send your comments to the mpls wg mailing list ([email-masked]), not later than 17th of May.
>>>>>>>>>

---

From: Tarek Saad <[email-masked]>
Date: Wed, 22 May 2019 21:56:40 +0000

Hi Alexander,

Thanks much for your inputs and comments. We have uploaded a new revision of the draft at: https://tools.ietf.org/html/draft-ietf-mpls-summary-frr-rsvpte-04 which addresses the points you raise below.
The diffs are https://tools.ietf.org/rfcdiff?url2=draft-ietf-mpls-summary-frr-rsvpte-04.txt

Please have a look, and let us know if you have further comments.

The updates include

  *   Added explicit tunnel sender address in the B-SFRR-Active ASSOCIATION ID and its respective handling by the MP
  *   Added IPv4 and IPv6 versions of the B-SFRR-Active ASSOCIATION ID
  *   Some minor edits

Regards,
Tarek

From: Alexander Okonnikov <[email-masked]>
Date: Thursday, May 16, 2019 at 7:43 AM
To: Tarek Saad <[email-masked]>
Cc: "Mike Taillon (mtaillon)" <[email-masked]>, Markus Jork <mjork=[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [mpls] Working Group Last Call on draft-ietf-mpls-summary-frr-rsvpte

Hi Tarek,

Thank you.

14 мая 2019 г., в 18:16, Tarek Saad <[email-masked]<mailto:[email-masked]>> написал(а):

Hi Alexander,

Regards,
Tarek

From: Alexander Okonnikov <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, May 14, 2019 at 8:21 AM
To: "Mike Taillon (mtaillon)" <[email-masked]<mailto:[email-masked]>>
Cc: Markus Jork <mjork=[email-masked]<mailto:mjork=[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [mpls] Working Group Last Call on draft-ietf-mpls-summary-frr-rsvpte
Resent-From: <[email-masked]<mailto:[email-masked]>>
Resent-To: <[email-masked]<mailto:[email-masked]>>, Tarek Saad <[email-masked]<mailto:[email-masked]>>, Rakesh Gandhi <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>
Resent-Date: Tuesday, May 14, 2019 at 8:21 AM

Hi Mike,

Thank you.

Hi Alexander

-mike

Hi Mike,

Thank you!

Hi Alexander,

-mike

Hi authors,

Thanks.

Working Group,

Best regards

Nic