Subject: [Teas] <draft-ietf-teas-p2mp-loose-path-reopt-04>: Review

From: Vishnu Pavan Beeram <[email-masked]>
Date: Sat, 5 Mar 2016 07:18:41 -0500

Authors, WG, Hi!

I've reviewed the current version of
<draft-ietf-teas-p2mp-loose-path-reopt>. There are a couple of high-level
issues (one process related, the other technical) that would need to get
sorted out before the draft progresses to the next stage.

(1) Issue with "Normative Reference": RFC-4736 is an informational RFC that
discusses mechanisms (/protocol extensions) for re-optimization of loosely
routed TE LSPs. <draft-ietf-teas-p2mp-loose-path-reopt> applies these
mechanisms (/protocol extensions) discussed in RFC-4736 to "re-optimization
of loosely routed P2MP TE LSPs", identifies some gaps in doing that and
fills those gaps by proposing some new extensions. As you would all agree,
RFC-4736 is correctly added as a normative reference in this draft.
However, adding this normative reference is causing an issue with ID-NITs.
There are two options for resolving this -
(a) Make the draft <informational> and keep the normative reference to
[RFC4736]
(b) Keep the draft in "standards track", keep the normative reference to
[RFC4736] and request an exception entry to be added in the DOWNREF
registry.
I'm currently leaning towards proposing (b). Please weigh in with your
thoughts/comments if you have any concerns with choosing (b) over (a).

(2) Markers for S2L sub-LSP Descriptor: This document defines markers to
indicate beginning and end of an S2L sub-LSP descriptor list when the RSVP
message needs to be fragmented due to large number of S2L sub-LSPs in the
message when performing sub-group based re-optimization. My concern with
the mechanism proposed in the document is that it assumes the ingress
receives the fragmented messages in the same order in which they were sent
out by the downstream node which fragmented the S2L sub-LSP Descriptor.
With RSVP, we don't typically assume message ordering to be in tact for
these messages that traverse through various hops (and we don't typically
add extensions that make this assumption). If we are to propose a mechanism
for marking these fragments, it would be useful/safer (IMHO) to add more
information to the marker and make it part of each fragment -- add enough
info to say that this is fragment "n" in a  set of "m" fragments belonging
to fragment-set ID "X". I would really like to see the WG discuss this
mechanism thoroughly as it clearly has generic applicability beyond the
scope of this document.

I do have a few other minor editorial suggestions/corrections to make as
well -- but those can wait until we reach some consensus on (2).

Thoughts/Opinions?

Regards,
-Pavan (Document Shepherd)

References:
https://tools.ietf.org/html/draft-ietf-teas-p2mp-loose-path-reopt-04
https://tools.ietf.org/html/rfc4736

---

From: "Tarek Saad (tsaad)" <[email-masked]>
Date: Tue, 8 Mar 2016 02:59:22 +0000

Thank you Pavan for the review and the comments. We discussed them amongst the co-authors, and please see inline for responses.

From: Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>
Date: Saturday, March 5, 2016 at 7:18 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: TEAS WG Chairs <[email-masked]<mailto:[email-masked]>>, "BRUNGARD, DEBORAH A (ATTLABS)" <[email-masked]<mailto:[email-masked]>>
Subject: <draft-ietf-teas-p2mp-loose-path-reopt-04>: Review

Authors, WG, Hi!

I've reviewed the current version of <draft-ietf-teas-p2mp-loose-path-reopt>. There are a couple of high-level issues (one process related, the other technical) that would need to get sorted out before the draft progresses to the next stage.

(1) Issue with "Normative Reference": RFC-4736 is an informational RFC that discusses mechanisms (/protocol extensions) for re-optimization of loosely routed TE LSPs. <draft-ietf-teas-p2mp-loose-path-reopt> applies these mechanisms (/protocol extensions) discussed in RFC-4736 to "re-optimization of loosely routed P2MP TE LSPs", identifies some gaps in doing that and fills those gaps by proposing some new extensions. As you would all agree, RFC-4736 is correctly added as a normative reference in this draft. However, adding this normative reference is causing an issue with ID-NITs. There are two options for resolving this -
(a) Make the draft <informational> and keep the normative reference to [RFC4736]
(b) Keep the draft in "standards track", keep the normative reference to [RFC4736] and request an exception entry to be added in the DOWNREF registry.
I'm currently leaning towards proposing (b). Please weigh in with your thoughts/comments if you have any concerns with choosing (b) over (a).
[TS]: yes, our preference is option (b) too.

(2) Markers for S2L sub-LSP Descriptor: This document defines markers to indicate beginning and end of an S2L sub-LSP descriptor list when the RSVP message needs to be fragmented due to large number of S2L sub-LSPs in the message when performing sub-group based re-optimization. My concern with the mechanism proposed in the document is that it assumes the ingress receives the fragmented messages in the same order in which they were sent out by the downstream node which fragmented the S2L sub-LSP Descriptor. With RSVP, we don't typically assume message ordering to be in tact for these messages that traverse through various hops (and we don't typically add extensions that make this assumption). If we are to propose a mechanism for marking these fragments, it would be useful/safer (IMHO) to add more information to the marker and make it part of each fragment -- add enough info to say that this is fragment "n" in a  set of "m" fragments belonging to fragment-set ID "X". I would really like to see the WG discuss this mechanism thoroughly as it clearly has generic applicability beyond the scope of this document.

[TS]: we see the point with regards to the re-ordering of RSVP message fragments. RFC2205 and RFC4875 disallow IP message fragmentation, and instead suggest the use of "semantic fragmentation"- quoted from rfc2205...  "breaking the path or reservation state being transmitted into multiple self-contained messages, each of an acceptable size." We agree, in this case, a method to preserve the RSVP message fragments order on reception will be useful. However, we feel this can be tackled on its own in a separate draft. Let us know if you concur?
Irrespectively, we think that the use of BEGIN/END markers as (S2L sub-LSP set) delimiters still serves its purpose to define the a set. For example, the receiver of the RSVP message that has S2L sub-LSP descriptor list and that also includes both the BEGIN and END markers can unambiguously identify the full list of S2L sub-LSPs to be acted on.

Regards,
Tarek/co-authors

I do have a few other minor editorial suggestions/corrections to make as well -- but those can wait until we reach some consensus on (2).

Thoughts/Opinions?

Regards,

References:

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Mon, 7 Mar 2016 23:06:58 -0500

Tarek (and other authors), Hi!

Thanks for discussing this amongst yourselves and sharing your thoughts
here. Please see inline for responses (prefixed [VPB]).

Regards,
-Pavan

On Mon, Mar 7, 2016 at 9:59 PM, Tarek Saad (tsaad) <[email-masked]> wrote:

> Thank you Pavan for the review and the comments. We discussed them amongst
> the co-authors, and please see inline for responses.
>
>
> From: Vishnu Pavan Beeram <[email-masked]>
> To: "[email-masked]" <
> [email-masked]>, "[email-masked]" <
> [email-masked]>
> Cc: TEAS WG Chairs <[email-masked]>, "BRUNGARD, DEBORAH A
> (ATTLABS)" <[email-masked]>
> (1) Issue with "Normative Reference": RFC-4736 is an informational RFC
> that discusses mechanisms (/protocol extensions) for re-optimization of
> loosely routed TE LSPs. <draft-ietf-teas-p2mp-loose-path-reopt> applies
> these mechanisms (/protocol extensions) discussed in RFC-4736 to
> "re-optimization of loosely routed P2MP TE LSPs", identifies some gaps in
> doing that and fills those gaps by proposing some new extensions. As you
> would all agree, RFC-4736 is correctly added as a normative reference in
> this draft. However, adding this normative reference is causing an issue
> with ID-NITs. There are two options for resolving this -
> *[TS]: yes, our preference is option (b) too.*
>
>
> *[TS]: we see the point with regards to the re-ordering of RSVP message
> fragments. RFC2205 and RFC4875 disallow IP message fragmentation, and
> instead suggest the use of "semantic fragmentation”— quoted from
> rfc2205…  "breaking the path or reservation state being transmitted into
> multiple self-contained messages, each of an acceptable size.” We agree, in
> this case, a method to preserve the RSVP message fragments order on
> reception will be useful. However, we feel this can be tackled on its own
> in a separate draft. **Let us know if you concur?*
>

[VPB] The order in which the (semantically) fragmented messages come in
doesn’t matter as long as the receiver can process each received message
independently (without having to wait for all fragments to show up). This
draft is introducing procedures which require the receiver to receive all
the fragments before attempting to take some action. So, I would like to
think that it is imperative to resolve this issue as part of this draft.

> *Irrespectively, we think that the use of BEGIN/END markers as (S2L
> sub-LSP set) delimiters **still serves its purpose to define the a set**.
> For example, the receiver of the RSVP message that has** S2L sub-LSP
> descriptor list and that also includes both the BEGIN and END markers can **unambiguously
> identify the full list of S2L sub-LSPs to be acted on.*
>
>
[VPB] Can you elaborate on that with an example?

[VPB] My concern is the following -- Consider a scenario where a given node
splits the S2L sub-LSP set into 3 fragments and sends out Fragment-1 with
the BEGIN marker, Fragment-2 with no marker and Fragment-3 with the END
marker. The procedures outlined in this draft would work well only if these
3 fragments are received by the node of interest in the same order. If
Fragment-2 comes in <before Fragment-1> or <after Fragment-3>, then the
procedures discussed in this document wouldn't produce the desired results.
All I'm trying to say here is that this "ordering" cant be guaranteed by
RSVP and it would be good if the draft proposes extensions that would work
even when the messages don't reach the intended recipient in the desired
order.

> *Regards,*
> *Tarek/co-authors*

---

From: "Tarek Saad (tsaad)" <[email-masked]>
Date: Tue, 8 Mar 2016 21:10:01 +0000

Thanks Pavan. We discussed further amongst the co-authors, and we will make the needed changes to address this and upload the new version of the draft.

Regards,
Tarek

From: Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>
Date: Monday, March 7, 2016 at 11:06 PM
To: Tarek Saad <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, TEAS WG Chairs <[email-masked]<mailto:[email-masked]>>, "BRUNGARD, DEBORAH A (ATTLABS)" <[email-masked]<mailto:[email-masked]>>
Subject: Re: <draft-ietf-teas-p2mp-loose-path-reopt-04>: Review

Thanks for discussing this amongst yourselves and sharing your thoughts here. Please see inline for responses (prefixed [VPB]).

Regards,
-Pavan

On Mon, Mar 7, 2016 at 9:59 PM, Tarek Saad (tsaad) <[email-masked]<mailto:[email-masked]>> wrote:
Thank you Pavan for the review and the comments. We discussed them amongst the co-authors, and please see inline for responses.

Authors, WG, Hi!

[VPB] The order in which the (semantically) fragmented messages come in doesn't matter as long as the receiver can process each received message independently (without having to wait for all fragments to show up). This draft is introducing procedures which require the receiver to receive all the fragments before attempting to take some action. So, I would like to think that it is imperative to resolve this issue as part of this draft.

[VPB] My concern is the following -- Consider a scenario where a given node splits the S2L sub-LSP set into 3 fragments and sends out Fragment-1 with the BEGIN marker, Fragment-2 with no marker and Fragment-3 with the END marker. The procedures outlined in this draft would work well only if these 3 fragments are received by the node of interest in the same order. If Fragment-2 comes in <before Fragment-1> or <after Fragment-3>, then the procedures discussed in this document wouldn't produce the desired results. All I'm trying to say here is that this "ordering" cant be guaranteed by RSVP and it would be good if the draft proposes extensions that would work even when the messages don't reach the intended recipient in the desired order.

Regards,
Tarek/co-authors

Thoughts/Opinions?

Regards,

References:

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Tue, 8 Mar 2016 16:26:17 -0500

Tarek -- Thanks!

@WG -- Please do let Tarek and the other authors know if you have any
comments on these 2 items.

Regards,
-Pavan

On Tue, Mar 8, 2016 at 4:10 PM, Tarek Saad (tsaad) <[email-masked]> wrote:

> Thanks Pavan. We discussed further amongst the co-authors, and we will
> make the needed changes to address this and upload the new version of the
> draft.
>
> Regards,
> Tarek
>
> To: Tarek Saad <[email-masked]>
> Cc: "[email-masked]" <
> [email-masked]>, TEAS WG Chairs <[email-masked]>, "BRUNGARD, DEBORAH
> A (ATTLABS)" <[email-masked]>
>> Thank you Pavan for the review and the comments. We discussed them
>> amongst the co-authors, and please see inline for responses.
>>
>>
> [VPB] My concern is the following -- Consider a scenario where a given
> node splits the S2L sub-LSP set into 3 fragments and sends out Fragment-1
> with the BEGIN marker, Fragment-2 with no marker and Fragment-3 with the
> END marker. The procedures outlined in this draft would work well only if
> these 3 fragments are received by the node of interest in the same order.
> If Fragment-2 comes in <before Fragment-1> or <after Fragment-3>, then the

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Thu, 10 Mar 2016 12:45:30 +0000

Hi Pavan, WG,

We are planning to update the draft by defining following message.  Please let us know if you have any review comments.

Also, Pavan, you said, you have a few other minor editorial suggestions/corrections. If you share it, may be we can address at the same time.

S2L_SUB_LSP_FRAG:

         Class-Num 50, C-Type TBA by IANA

   +-----------------+---------------+--------------------------+
   | Length(12 bytes)| Class_Num 50  |     S2L_SUB_LSP_FRAG     |

   +-----------------+---------------+--------------------------+
   |      Reserved                   |     Fragment ID          |
   +-----------------+---------------+--------------------------+

| Fragments Total | Fragment Number | +-----------------+---------------+--------------------------+

Fragment ID:               16-bit value, range is 1 to 65535
Fragments Total:        16-bit value, range is 1 to 65535
Fragment Number:    16-bit value range is 1 to 65535

Thanks,
Rakesh (and co-authors)

---------- Forwarded message ----------
From: Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>
Date: Tue, Mar 8, 2016 at 4:26 PM
Subject: Re: [Teas] <draft-ietf-teas-p2mp-loose-path-reopt-04>: Review
To: "Tarek Saad (tsaad)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, TEAS WG Chairs <[email-masked]<mailto:[email-masked]>>, "BRUNGARD, DEBORAH A (ATTLABS)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Tarek -- Thanks!

@WG -- Please do let Tarek and the other authors know if you have any comments on these 2 items.

Regards,
-Pavan

On Tue, Mar 8, 2016 at 4:10 PM, Tarek Saad (tsaad) <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Pavan. We discussed further amongst the co-authors, and we will make the needed changes to address this and upload the new version of the draft.

Regards,
Tarek

Regards,
-Pavan

Authors, WG, Hi!

[TS]: we see the point with regards to the re-ordering of RSVP message fragments. RFC2205 and RFC4875 disallow IP message fragmentation, and instead suggest the use of "semantic fragmentation”— quoted from rfc2205…  "breaking the path or reservation state being transmitted into multiple self-contained messages, each of an acceptable size.” We agree, in this case, a method to preserve the RSVP message fragments order on reception will be useful. However, we feel this can be tackled on its own in a separate draft. Let us know if you concur?

[VPB] The order in which the (semantically) fragmented messages come in doesn’t matter as long as the receiver can process each received message independently (without having to wait for all fragments to show up). This draft is introducing procedures which require the receiver to receive all the fragments before attempting to take some action. So, I would like to think that it is imperative to resolve this issue as part of this draft.

Regards,
Tarek/co-authors

Thoughts/Opinions?

Regards,

References:

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

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Thu, 10 Mar 2016 11:30:34 -0500

Rakesh, Hi!

The proposed format for S2L_SUB_LSP_FRAG looks good to me (Thanks for
putting this together). I'm assuming that you'll get rid of the discussion
on start and end S2L markers from the draft and replace it with this new
construct. Is that assumption correct?

If the WG is ok with this, please do go ahead and publish the new version.
I'll recompile the list of editorial nits on the updated version of the
document.

Regards,
-Pavan

On Thu, Mar 10, 2016 at 7:45 AM, Rakesh Gandhi (rgandhi) <[email-masked]>
wrote:

> Hi Pavan, WG,
>
> We are planning to update the draft by defining following message.  Please
> let us know if you have any review comments.
>
> Also, Pavan, you said, you have a few other minor editorial
> suggestions/corrections. If you share it, may be we can address at the same
> time.
>
> S2L_SUB_LSP_FRAG:
>
> | Fragments Total | Fragment Number |
> To: "Tarek Saad (tsaad)" <[email-masked]>
> [email-masked]>, TEAS WG Chairs <
> [email-masked]>, "BRUNGARD, DEBORAH A (ATTLABS)" <[email-masked]>, "
> [email-masked]" <[email-masked]>
>
>
> Tarek -- Thanks!
>
>> [email-masked]>, TEAS WG Chairs <[email-masked]>, "BRUNGARD,
>> DEBORAH A (ATTLABS)" <[email-masked]>
> [email-masked]

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Thu, 10 Mar 2016 16:38:06 +0000

Hi Pavan,

Yes, we will remove the BEGIN/END markers.

Thanks for the review.

Regards,
Rakesh (and co-authors)

From: Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>
Date: Thursday, 10 March, 2016 11:30 AM
To: Rakesh Gandhi <[email-masked]<mailto:[email-masked]>>
Cc: "Tarek Saad (tsaad)" <[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]>>, DEBORAH BRUNGARD <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas] <draft-ietf-teas-p2mp-loose-path-reopt-04>: Review

Rakesh, Hi!

The proposed format for S2L_SUB_LSP_FRAG looks good to me (Thanks for putting this together). I'm assuming that you'll get rid of the discussion on start and end S2L markers from the draft and replace it with this new construct. Is that assumption correct?

If the WG is ok with this, please do go ahead and publish the new version. I'll recompile the list of editorial nits on the updated version of the document.

Regards,
-Pavan

On Thu, Mar 10, 2016 at 7:45 AM, Rakesh Gandhi (rgandhi) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Pavan, WG,

S2L_SUB_LSP_FRAG:

Thanks,
Rakesh (and co-authors)

---------- Forwarded message ----------
From: Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>
Date: Tue, Mar 8, 2016 at 4:26 PM
Subject: Re: [Teas] <draft-ietf-teas-p2mp-loose-path-reopt-04>: Review
To: "Tarek Saad (tsaad)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, TEAS WG Chairs <[email-masked]<mailto:[email-masked]>>, "BRUNGARD, DEBORAH A (ATTLABS)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Tarek -- Thanks!

Regards,
-Pavan

Regards,
Tarek

Regards,
-Pavan

Authors, WG, Hi!

Regards,
Tarek/co-authors

Thoughts/Opinions?

Regards,

References:

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Fri, 11 Mar 2016 16:00:14 +0000

Hi WG, Pavan,

We have posted a new revision that addresses the comments from Pavan on
the out of order RSVP packets.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-teas-p2mp-loose-path-reopt/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-teas-p2mp-loose-path-reopt-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-p2mp-loose-path-reopt-05

Welcome review comments and suggestions on the draft.

Thanks,
Rakesh (and co-authors)

On 2016-03-10 11:38 AM, "Rakesh Gandhi (rgandhi)" <[email-masked]>
wrote:

>From: Vishnu Pavan Beeram
><[email-masked]<mailto:[email-masked]>>
>Cc: "Tarek Saad (tsaad)" <[email-masked]<mailto:[email-masked]>>,
>"[email-masked]<mailto:draft-ietf-teas-p2m
>[email-masked]>"
><[email-masked]<mailto:draft-ietf-teas-p2m
>[email-masked]>>,
>"[email-masked]<mailto:[email-masked]>"
><[email-masked]<mailto:[email-masked]>>, DEBORAH BRUNGARD
><[email-masked]<mailto:[email-masked]>>,
>"[email-masked]<mailto:[email-masked]>"
><[email-masked]<mailto:[email-masked]>>
>putting this together). I'm assuming that you'll get rid of the
>discussion on start and end S2L markers from the draft and replace it
>with this new construct. Is that assumption correct?
>
>If the WG is ok with this, please do go ahead and publish the new
>version. I'll recompile the list of editorial nits on the updated version
>of the document.
>
>Regards,
>-Pavan
>
>On Thu, Mar 10, 2016 at 7:45 AM, Rakesh Gandhi (rgandhi)
><[email-masked]<mailto:[email-masked]>> wrote:
>Hi Pavan, WG,
>
>We are planning to update the draft by defining following message.
>Please let us know if you have any review comments.
>
>suggestions/corrections. If you share it, may be we can address at the
>same time.
>
>S2L_SUB_LSP_FRAG:
>
>
>From: Vishnu Pavan Beeram
><[email-masked]<mailto:[email-masked]>>
>Cc: 
>"[email-masked]<mailto:draft-ietf-teas-p2m
>[email-masked]>"
><[email-masked]<mailto:draft-ietf-teas-p2m
>[email-masked]>>, TEAS WG Chairs
><[email-masked]<mailto:[email-masked]>>, "BRUNGARD, DEBORAH A
>(ATTLABS)" <[email-masked]<mailto:[email-masked]>>,
>"[email-masked]<mailto:[email-masked]>"
><[email-masked]<mailto:[email-masked]>>
>
>
>Tarek -- Thanks!
>
>On Tue, Mar 8, 2016 at 4:10 PM, Tarek Saad (tsaad)
><[email-masked]<mailto:[email-masked]>> wrote:
>draft