Subject: [mpls] FW: 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

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Sat, 6 Sep 2014 00:14:48 +0000

Hello,

I have been asked to do a preliminary review of this draft. Here below my comments for discussion:

From: Alia Atlas [mailto:[email-masked]]
Sent: Friday, September 05, 2014 8:12 PM
To: Papadimitriou, Dimitri (Dimitri)
Cc: BRUNGARD, DEBORAH A; Loa Andersson; [email-masked]; [email-masked]; VIGOUREUX, MARTIN (MARTIN); [email-masked]; Jonathan Hardwick ([email-masked])
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

Dmitri,

Thanks for doing the review!   Could you please send it to the MPLS mailing list for discussion?

Regards,
Alia

On Mon, Aug 25, 2014 at 8:45 AM, Papadimitriou, Dimitri (Dimitri) <[email-masked]<mailto:[email-masked]>> wrote:
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."

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 a "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.”

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.

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Sat, 6 Sep 2014 00:38:57 +0000

Hi WG,

Forwarding following reply from Tarek to the MPLS mailing list.

Thanks Tarek and Dimitri.

Regards,
Rakesh

From: "Tarek Saad (tsaad)" <[email-masked]<mailto:[email-masked]>>
Date: Friday, 5 September, 2014 1:42 PM
To: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]<mailto:[email-masked]>>, DEBORAH BRUNGARD <[email-masked]<mailto:[email-masked]>>, Loa Andersson <[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]>>, Martin Vigoureux <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "Jonathan Hardwick ([email-masked]<mailto:[email-masked]>)" <[email-masked]<mailto:[email-masked]>>
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)" <[email-masked]<mailto:[email-masked]>>
Date: Monday, August 25, 2014 at 8:45 AM
To: "BRUNGARD, DEBORAH A" <[email-masked]<mailto:[email-masked]>>, Loa Andersson <[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]>>, "VIGOUREUX, MARTIN (MARTIN)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "Jonathan Hardwick ([email-masked]<mailto:[email-masked]>)" <[email-masked]<mailto:[email-masked]>>
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,

   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.

   With:

       0                   1                   2                   3

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.

Regards,
Tarek

Many thanks,
-dimitri.