Re: [mpls] MPLS-RT review of draft-zzhang-mpls-rmr-multicast

[Tarek Saad <[e-mail]>]

Hi all,

I’ve been selected as an MPLS-RT reviewer for this draft that is undergoing WG adoption.
Below are my comments.

The document is intended to describe high-level requirements for multicast over RMR rings and document covers specifics that are not dependent on the signaling protocol used to setup the M/P2MP LSP rings.
- I still found, however, instances where it's trying to describe protocol specific signaling details
- IMO, this should be deferred to the other RMR protocol specific documents.
- Ideally, should consider incorporating this document as a section into the main RMR high-level document ID: draft-ietf-mpls-rmr. Was this considered?

>>   This leads to lots of redundant state on routers close to the ingress.
>>   With RMR, this can be optimized such
>>   that only a single LSP is signaled, with all the leaves listed in the PATH message.
[TS]: I think a single sub-LSP state still needs to be maintained, regardless if they are signaled in a single or multiple PATH messages. This is needed so a leaf can grafted or pruned without affecting existing leafs.
Note, RFC4875 already allows for signaling multiple sub-LSP(s) in a single PATH message (see rfc4875 section 5.2.2) - so not clear of the new optimizations mentioned here.

Section 2:
>> ingress A in clockwise direction (A,B,C,D) and four hops away in the....
I could not find the figure that shows those nodes? IMO, this high-level description can refrain from describing signaling protocol specific details.

>>   The PATH message does not need to list all leaves.  As long as a leaf somehow determines that it is a leaf, it can send RESV message when it receives the PATH message.
[TS]: With RSVP-TE, a P2MP node discovers it’s a leaf upon processing the PATH that contains a S2L_SUB_LSP with a matching local address. Since the PATH message is reaching the node, not clear on what is optimization in this case.

>> Once the traffic is out of the ring  LSP on R3,
[TS]: I think clearer as "Once traffic is out of the CW LSP to R3". Also, it is unclear if/how PLR(2) can distinguish whether to tunnel traffic over CW LSP to node R3 or to node R4 - i.e. case of R3 node failure?

>> Section 3: End to End Tunnels with Rings
[TS]: do you mean full mesh of tunnels between PEs? The summary I can draw from this small section is that RMR (as another form of P-tunnels) is not introducing any new requirements, right?

Regards,
Tarek


On 3/28/19, 5:19 AM, "Loa Andersson" <[e-mail]> wrote:

    Tarek, Andy, Huub and Rajiv,
    
    You have be selected as MPLS-RT reviewers for
    draft-zzhang-mpls-rmr-multicast-02.
    
    Note to authors: You have been CC'd on this email so that you can know
    that this review is going on. However, please do not review your own
    document.
    
    Reviews should comment on whether the document is coherent, is it
    useful (ie, is it likely to be actually useful in operational
    networks), and is the document technically sound?  We are interested
    in knowing whether the document is ready to be considered for WG
    adoption (ie, it doesn't have to be perfect at this point, but should be
    a good start).
    
    Reviews should be sent to the document authors, WG co-chairs and
    WG secretary, and CC'd to the MPLS WG email list. If necessary, comments
    may be sent privately to only the WG chairs.
    
    If you have technical comments you should try to be explicit about what
    *really* need to be resolved before adopting it as a working group
    document, and what can wait until the document is a working group
    document and the working group has the revision control.
    
    Are you able to review this draft by April 12, 2019? Please respond in a
    timely fashion.
    
    
    Thanks, Loa
    (as MPLS WG chair)
    -- 
    
    
    Loa Andersson                        email: [e-mail]
    Senior MPLS Expert
    Bronze Dragon Consulting             phone: [phone]