Re: [Teas] WG Last Call on draft-ietf-teas-p2mp-loose-path-reopt

["Rakesh Gandhi (rgandhi)" <[e-mail]>]

Hi Adrian,

Thank you for the thorough review of the document. Please see replies inline with <RG> ..


From: Teas <[e-mail]<mailto:[e-mail]>> on behalf of Adrian Farrel <[e-mail]<mailto:[e-mail]>>
Reply-To: Adrian Farrel <[e-mail]<mailto:[e-mail]>>
Date: Monday, October 17, 2016 at 10:28 PM
To: 'Vishnu Pavan Beeram' <[e-mail]<mailto:[e-mail]>>
Cc: 'TEAS WG Chairs' <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Teas] WG Last Call on draft-ietf-teas-p2mp-loose-path-reopt

Hi,

I review this document. I don't object to its publication although I am not enthusiastic.

I have done a review of the document (consistent with being your technical advisor :-). Here are a few comments that may be helpful to the WG.

Cheers,
Adrian

===

I wonder whether 6510 might be a useful additional reference.


<RG> Added.

---

I missed a reference to RFC 3473 even though you say

>  Traffic
>  Engineered (TE) Label Switched Paths (LSPs) [RFC4875] in a
>  Multi-Protocol Label Switching (MPLS) or Generalized MPLS (GMPLS)
>  network.


<RG> Added.
---

Abstract

>  This document defines Resource Reservation Protocol (RSVP) signaling
>  extensions to allow ... a mid-point node to notify to the ingress
>  node that a preferable tree exists for the entire P2MP-TE LSP.

It can't know that. It can only know about the part of the tree that
lies downstream of it. Maybe some rewording?

<RG> Updated the text.

---

I think your Terminology section comes quite late. This is probably
because Section 1 is too big. Perhaps a short introduction followed by
Section 2, followed by a new section "Overview".

<RG> Updated the document.

---

Section 3 is rich with SHOULDs and MAYs. No problem with that, but for each SHOULD I think you need to give a clue why it is not a MUST (i.e., why might you vary it?) and for each MAY you should hint at how an implementation could choose to do it.

<RG> Updated text.

---

3.1 has

> The sending of an RSVP PathErr Notify message "Preferable P2MP-TE
> Tree Exists" to the ingress node SHALL notify the ingress node of the
> existence of a preferable P2MP-TE LSP tree and upon receiving this
> PathErr, the ingress node MAY trigger re-optimization of the LSP
> using a different LSP-ID.

I don't think that's a "SHALL notify": rather "notifies".

<RG> Updated the text.

---

A little consistent terminology would be nice. I think the correct term is --a PathErr carrying the "Notify" error code.--   That's a bit of a mouthful, but you have it (or similar) in Section 1.  But you also have "notify PathErr" and "PathErr notification" and "Notify Error PathErr" and "RSVP PathErr Notify message." The last of these is most problematic because (of course) there is an RSVP Notify message (RFC 4373).

<RG> Updated the document.

---

It would be nice if TBA1 and TBA2 were mentioned in the body of the text.

<RG> Added.

---

It worries me that section 4.3 says that "The RSVP message may need to be fragmented". You need to be super clear that RSVP messages are not fragmented. Ever!

What you are talking about is called "semantic fragmentation" per RFC 4875 (cf. section 5.2.3 etc.).

<RG> Corrected the text.

---

Section 3.2 and 4.3

The "new S2L_SUB_LSP_FRAG Object" you write about isn't a new object is it? It's an S2L_SUB_LSP object with C-Type S2L_SUB_LSP_FRAG. You need to be very clear about this. [But see the point that follows.]

<RG> Corrected. More information below.

What happens when you run out of Fragment IDs? What if the Fragment ID is not one greater than the last one? What if a new Fragment ID is received before the last one is completed.

<RG> Text added for above cases.

What happens if the Fragments Total value changes in the series of messages that comprise a single set with a common Fragment ID?

<RG> Text added. Receiver should discard all fragment messages.

65535 fragments? Really?

<RG> Updated to 255 fragments. Does that work?

I'm confused :-)
4875 manages semantic fragmentation without the new S2L_SUB_LSP_FRAG Object. It isn't clear in this document why reoptimisation (which is not substantially different from LSP setup) needs this new function.

<RG> Request for this addition came from Papadimitriou, Dimitri (author for RFC4875), who reviewed this document. Please see the attached email thread.  It seems this was thought of during RFC4875 but left as future work.


Could you use the S2L_SUB_LSP_FRAG Object in a 4875 LSP setup message? You do say...

   The new object S2L_SUB_LSP_FRAG defined in this document has a wider
   applicability other than the P2MP-TE LSP re-optimization but it is
   outside the scope of this document.

... but 4875 and this document are pretty closely related.


<RG> Updated text to state that  S2L_SUB_LSP_FRAG can be used for LSP setup and other messages.

---

[Running on from the previous point about whether we're dealing with a new object]

A bit more confusion about the S2L_SUB_LSP Object. In 4875 each new object is identified with a new sub-LSP (with or without a preceding ERO or subsequent SERO), but now you are saying that an S2L_SUB_LSP may be followed by another S2L_SUB_LSP . There is nothing wrong with this per se, but it does change the semantic somewhat and reflects a change to 4875 processing.

Effectively 4875's
   <S2L sub-LSP descriptor> ::= <S2L_SUB_LSP>
                                [ <P2MP SECONDARY_EXPLICIT_ROUTE> ]
now reads
   <S2L sub-LSP descriptor> ::= [ <S2L_SUB_LSP> ]
                                 <S2L_SUB_LSP>
                                [ <P2MP SECONDARY_EXPLICIT_ROUTE> ]


<RG> Added proper message format.

But even that isn't clear because the specific instances have to have specific C-Types.

I can't help feeling it might be better to use a completely separate object (although I suspect Lou will try to conserve the code space).

Actually, re-reading the text and looking at section 5, I wonder whether you really didn't intend a different object.

<RG> Agreed, changed to a new Object. Chairs, please advise if there is a concern.

Thanks,
Rakesh (for all authors)

--- Begin Message ---

Hi,

 

Beside this gist, there is a point that would be worth discussing

 

message fragmentation is one possible cause of initiating re-signaling before the full list is being known to the root but this is decorrelated from loose or strict  ERO; in that case, the question of introducing a more general procedure with an EOL (end of list bit) could be more appropriate as it would solve two problems at once. 

 

+ including a compatibility section somewhere in this document would certainly help.

 

PS: in the longer term, I anticipate the need to collect practices and production of a BCP.

 

Thanks,

-dimitri.

 

From: Rakesh Gandhi (rgandhi) [mailto:[e-mail]] 
Sent: Friday, September 19, 2014 11:22 PM
To: Papadimitriou, Dimitri (Dimitri); Tarek Saad (tsaad); [e-mail]
Cc: [e-mail]
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

 

Hi Dimitri,

 

Thank you for your review comments.

 

Gist of your comments is that there is a way in RFC4875 to bulk the requests for queries via a path message and also add a list of S2Ls in a PathErr message. 

This method can be used for re-optimizing a group of S2Ls without incrementing the LSP-ID as Tarek mentioned.

 

As you hinted below, proposed draft provides a signalling extension to re-optimize entire P2MP LSP/tree similar to P2P [RFC4736] by incrementing the LSP-ID.

 

If you agree with above understanding, we can clarify in the draft accordingly.

 

Thanks,

Rakesh

 

 

 

From: <Papadimitriou>, "Dimitri (Dimitri)" <[e-mail]>
Date: Friday, 19 September, 2014 10:49 AM
To: Rakesh Gandhi <[e-mail]>, "Tarek Saad (tsaad)" <[e-mail]>, "[e-mail]"  <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

 

Hello Rakesh,

 

See below for my answers:

 

From: Rakesh Gandhi (rgandhi) [mailto:[e-mail]] 
Sent: Saturday, September 06, 2014 2:39 AM
To: Tarek Saad (tsaad); Papadimitriou, Dimitri (Dimitri); [e-mail]
Cc: [e-mail]
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

 

Hi WG,

 

Forwarding following reply from Tarek to the MPLS mailing list.

 

Thanks Tarek and Dimitri.

 

Regards,

Rakesh

 

 

From: "Tarek Saad (tsaad)" <[e-mail]>
Date: Friday, 5 September, 2014 1:42 PM
To: "Papadimitriou, Dimitri (Dimitri)" <[e-mail]>, DEBORAH BRUNGARD <[e-mail]>, Loa Andersson <[e-mail]>,  "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>,  Martin Vigoureux <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: "Jonathan Hardwick ([e-mail])" <[e-mail]>
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

 

Hi Dimitri,

 

Thanks much for reviewing the draft and for your feedback. Please see inline..

 

From: <Papadimitriou>, "Dimitri (Dimitri)" <[e-mail]>
Date: Monday, August 25, 2014 at 8:45 AM
To: "BRUNGARD, DEBORAH A" <[e-mail]>, Loa Andersson <[e-mail]>, "[e-mail]" <[e-mail]>,  "[e-mail]" <[e-mail]>, "VIGOUREUX, MARTIN (MARTIN)" <[e-mail]>,  "[e-mail]" <[e-mail]>
Cc: "Jonathan Hardwick ([e-mail])" <[e-mail]>
Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

Hello,

 

Here is my review of this document:

 

The statement "notification of preferred path exists for a single S2L sub-LSP only." and what comes in Section 3 of this document is questionable

 

i) there is a mode of operation already included in RFC 4875 which allows such reorganization by sub-group ID cf. Section 14.2. "Sub-Group-Based Re-Optimization."  It looks as an over-reading to state this method is limited on per-sub-LSP basis, that section states clearly

 

"14.2.  Sub-Group-Based Re-Optimization

 

   Any node may initiate re-optimization of a set of S2L sub-LSPs by

   using incremental state update and then, optionally, combining

   multiple path messages."

 

[TS]: the draft is in agreement of the above statement from rfc4875 and this is called out in the draft (below) with the shortcoming mentioned in section 14.2  for duplication of traffic in certain cases.

"The ingress LSR that receives (un)solicited PathErr notification(s)

   for individual S2L sub-LSP(s), may prematurely start re-optimizing

   the sub-set of S2L sub-LSPs.  However, as mentioned in [RFC4875]

   Section 14.2, such re-optimization procedure may result in data duplication

" 

The make-before-break reoptimization method as described in rfc4875 section 14.1 avoids the former duplication problem by resignaling all the S2L sub-LSPs with  a different LSP-ID. Currently, there’s no explicit way for a mid-LSR to notify the ingress to trigger this specific mode of reoptimization-- short of possibly re-using the PERR code/subcode for “preferable path exists” as defined in rfc4736 and including the *full* list of S2Ls in the S2L sub-LSPs descriptor in the PERR sent back to the ingress. However, as mentioned in rfc4875, an LSR may fragment such signalled messages (e.g. when a single message may not be large enough to fit all S2L sub-LSPs)..  In this case, the ingress LSR may receive multiple PERR(s) with sub-sets of S2L sub-LSPs in each and would require additional logic to infer all S2L sub-LSPs are to be resigned (e..g. using section 14.1 method) by (example) waiting for some time to aggregate  all possible PERR messages before taking action. 

We also believe having a sub-set of S2L sub-LSPs in the descriptor list in the PERR sent by a mid-LSR is useful to explicitly trigger the sub-group based reoptimization  mode described in section 14.2.

 

In other cases, a PATH message that is intended to carry the “path re-evaluation” flag — as defined defined in rfc4736—with a full list of S2L sub-LSPs in S2L  sub-LSPs descriptor list will be decomposed at branching LSRs, and only a subset of the S2L sub-LSPs that are routed over same next-hop will be propagated in the descriptor list of the PATH message propagated to downstream mid-LSRs.. Consequently, when a preferable  path exists at such mid-LSRs, the PERR can only include the sub-set of S2L sub-LSPs traversing it.. The ingress LSR in this case can unambiguously use it to distinguish which LSP mode of reoptimization to invoke.

 

[DP2] It is the requestor (initiator of the PathErr) which expands the ERO (right ?) and sequence their signaling (thus any remerging between old and new sub-LSP  follows the remerging (following Section 18), why would request to have such control taken by the root of the tree ?

 

The protocol format chain can be found here below to see possibility for generating such request via notification:

 

   <notify session list>       ::= [ <notify session list> ]

                                   <upstream notify session> |

                                   <downstream notify session>

 

   <upstream notify session>   ::= <SESSION> [ <ADMIN_STATUS> ]

                                   [<POLICY_DATA>...]

                                   <sender descriptor>

 

 

   <sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>

                                    [ <ADSPEC> ]

 

   With:

 

       0                   1                   2                   3

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |                   IPv4 tunnel sender address                  |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |       Reserved                |            LSP ID             |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |                   Sub-Group Originator ID                     |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |       Reserved                |            Sub-Group ID       |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

I read behind this draft that this new mode of operation (the fact subpaths "are loose or abstract hop expanded" doesn't change the general comment) means some  would prefer alignment with P2P re-optimization and operate outside incremental state update --introduced for scaling reasons. In any case, the justification/motivation for this mode of operation is missing in the document.

 

 

ii) with PathErr as defined in RFC 4875 it includes a [ <S2L sub-LSP descriptor list> ]

thus, it is even less clear why one would like to move with or more generally signaling it differently ("Request flags" instead of an "code") would prevent as  mentioned in [RFC4875] Section 14.2, that sub-Group-based re-optimization may result in transient data

duplication as the new Path messages for a set of S2L sub-LSPs may

transit one or more nodes with the old Path state for the same set of

S2L sub-LSPs.” 

[TS]: Please see reply above for the first one.

 

[DP2] I am not sure you have captured this comment, and would reformulate it as follows: under which conditions the number of sub-LSPs is so large that i) the  receiver triggers re-signalling without having received the full sequence of sub-LSP, ii) the initiator has no mean to sequence the resulting Path messages such as to avoid situation of Section 14.2, iii) assuming this would be the case, why the procedure  of Section 18 is not sufficient ? In more general terms why signal to the root a procedure than can be performed by the requestor itself ?

 

[DP2] On the other hand, there is a wide question, why do you consider only the case with loose ERO’s ? I mean the fragmentation problem is only one cause of occurrence  of duplication (which could happen from any transient event during establishment of P2MP LSP), in that case, the question of introducing a more general procedure with an EOL (end of list bit) would certainly be more appropriate as it would solve two problems  at once. 

 

 

Regards,

Tarek

 

The proposed draft doesn’t solve cases where this would occur, and on the other, the cases it covers are already by RFC 4875 (re-optimize a loose set from a single  branching point is already covered).

 

Many thanks,

-dimitri.

 

 

--- End Message ---