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

[Tarek Saad <[e-mail]>]

Hey Jeffrey,

See inline..

On 4/10/19, 9:13 PM, "Jeffrey (Zhaohui) Zhang" <[e-mail]> wrote:

    Hi Tarek,
    
    Thanks for your review and comments. Please see my responses below.
    
        > -----Original Message-----
    > From: Tarek Saad <[e-mail]>
    > Sent: Wednesday, April 10, 2019 3:24 PM
    > To: [e-mail]
    > Cc: [e-mail]; [e-mail]
    > Subject: Re: MPLS-RT review of draft-zzhang-mpls-rmr-multicast
    > 
    > 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.
    
    It does not describe requirements. Rather, it points out that multicast can work as is, or can be optimized.
    
    > - 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.
    
    Second 2 describes at a high level how RSVP-TE P2MP tunnel can be optimized with RMR, but does refer to [I-D.zzhang-teas-rmr-rsvp-p2mp]. I could remove the majority of the text in section and simply point out that it could be optimized.
[TS]: OK, but would think you want to define those in the other draft.. otherwise, it's hard to keep the content in sync in 2 separate 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?
    
    Like in many other cases, a technology may be first specified only for unicast initially and then add multicast. In this case, we don't want to delay the unicast piece.
[TS]: OK, but given not introducing any new reqts and that signaling optimizations (if any) are deferred to other documents, still concerned? I'll leave it up to you/WG.
    
    > 
    > >>   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.
    
    Do you mean a "separate sub-LSP state still need to be maintained for each leaf"?
    I don't think that's needed to graft/prune a leaf - just compare to how mLDP works.

[TS]: classic P2MP RSVP-TE LSPs are ingress driven.. the provisioning/graft/prune is driven by the ingress LER (possibly triggered by overlay auto-discovery route learnt at ingress). I am not clear, in the case, how ingress can trigger the graft/prune operation on a single sub-LSP without impacting the others.

    > 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.
    
    The optimization here is that only a single sub-LSP is needed.
[TS]: still little confused. An S2L_SUB_LSP object identifies a particular S2L sub-LSP.  The  S2L_SUB_LSP object has a single destination address (the leaf).. Are you proposing configuring anycast address (per p2mp-te tree) in S2L_SUB_LSP to identify all the nodes of a ring? Please clarify.

    > 
    > 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.
    
    I did not include a figure, thinking that the (A,B,C,D) clockwise and (A,E,F,G,D)  anticlockwise text would be clear enough. I can either add a figure or remove most of the text as mentioned earlier.
[TS]: still helpful to be there.
    
    > 
    > >>   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.
    > 
    
    Think how mLDP works. Label mapping is sent from a leaf towards the root and a leaf knows it's leaf by other means (not through mLDP mechanisms). Want to apply the same here as an option.
[TS]: Yes, but one key difference between mLDP and RSVP-TE is that the latter is ingress driven while the former is prefix (e.g S,G) driven.. For classic P2MP RSVP-TE, the graft/prune is controlled by ingress. If you're planning to change this, I think it would be worth more highlighting/clarifying.
    
    > >> 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". 
    
    Let me quote the surrounding text here:
    
       In the event of a link failure between R2 and R3, R2 the Point of
       Local Repair (PLR) tunnels P2MP LSP traffic on a anti-clockwise ring
       LSP to R3 the Merge Point (MP).  Once the traffic is out of the ring
       LSP on R3, it uses the regular P2MP LSP to reach R4.  Similarly in
       the event of a node failure R3, R2 the PLR tunnels P2MP LSP traffic
       to R4 (the MP), which is also the leaf.
    
    The ring LSP to R3 used to tunnel traffic when R2->R3 link breaks is anti-clockwise not clockwise (CW).
[TS]: My bad, I read "CW" as counter clock-wise __ -- while you probably refer to it as AC (anti-clockwise). In either case, it's good to refer to it explicitly as the AC 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?
    
    A node needs to be able to determine if a failure is a link failure or node failure. Once it knows, it knows how to tunnel.
[TS]: yes, can imagine it's not quite straight forward to do so..

    > >> 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?
    
    I meant that an end to end tunnel can go through an arbitrary topology, part of which is a ring or multiple rings.
    RMR is not a form of tunnel. It's a special (sub-)topology.
    RMR does not introduce any new requirements, though you could optimize RSVP-TE P2MP tunnel over RMR, and optimize tunnel protection for both RSVP-TE and mLDP P2MP tunnels.
[TS]: good to know. I still believe if you're going to talk about (e.g.) RSVP-TE optimizartions, you're better off doing so in the RSVP-TE RMR draft. I'd expect RMR topology considerations on to P2MP or MP2MP LSP(s) to be discussed here.

Regards,
Tarek
    
    Jeffrey
    > 
    > 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]
    >