Early Review of draft-tsaad-mpls-p2mp-loose-path-reopt-03
review-tsaad-mpls-p2mp-loose-path-reopt-03-rtgdir-early-dimitri-2014-08-26-01

Hello,



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



From:

 Alia Atlas [mailto:akatlas at gmail.com]

Sent:

 Friday, September 05, 2014 8:12 PM

To:

 Papadimitriou, Dimitri (Dimitri)

Cc:

 BRUNGARD, DEBORAH A; Loa Andersson; rtg-ads at tools.ietf.org; mpls-chairs at
 tools.ietf.org; VIGOUREUX, MARTIN (MARTIN);
 draft-tsaad-mpls-p2mp-loose-path-reopt at tools.ietf.org; Jonathan Hardwick
 (Jonathan.Hardwick at metaswitch.com)

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) <

dimitri.papadimitriou at alcatel-lucent.com

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