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-00
Request | Review of | draft-tsaad-mpls-p2mp-loose-path-reopt |
---|---|---|
Requested revision | No specific revision (document currently at 03) | |
Type | Early Review | |
Team | Routing Area Directorate (rtgdir) | |
Deadline | 2014-08-26 | |
Requested | 2014-08-05 | |
Authors | Tarek Saad , Rakesh Gandhi , Zafar Ali , Robert H. Venator , Yuji Kamite | |
I-D last updated | 2014-08-26 | |
Completed reviews |
Rtgdir Early review of -03
by Papadimitriou Dimitri
|
|
Assignment | Reviewer | Papadimitriou Dimitri |
State | Completed Snapshot | |
Review |
review-tsaad-mpls-p2mp-loose-path-reopt-03-rtgdir-early-dimitri-2014-08-26
|
|
Posted at | https://datatracker.ietf.org/doc/review-tsaad-mpls-p2mp-loose-path-reopt-03-rtgdir-early-dimitri-2014-08-26/ | |
Reviewed revision | 03 | |
Result | Not ready | |
Completed | 2022-09-16 |
The information below is for an old version of the document.
review-tsaad-mpls-p2mp-loose-path-reopt-03-rtgdir-early-dimitri-2014-08-26-00
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.