Re: [pim] [**EXTERNAL**] Re: Call for adoption of sr-mpls-multicast-framework

["Duncan, Ian" <[e-mail]>]

Hello Toerless --

Thanks for your thoughtful commentary on the draft. I'm pleased to hear you find its subject of interest. The document certainly would benefit from additional illustrative & explanatory content, and inevitably also editing for clarity. Work will begin on a new version once the feedback from IETF102 & this WG call is in. 

Additional handful of responses embedded below, identified by ID>>

Best .. Ian

======
On 2018-08-08, 16:15, "pim on behalf of Toerless Eckert" <[e-mail] on behalf of [e-mail]> wrote:

    I do find this area of work very interesting, but
    I would prefer if the WG would not adopt this document yet.
    
    I would be happy to help/contribute (time permitting) with
    work in this area, but primarily when we can direct this work to:
    
    -> allow to support different forwarding planes
    -> Allow to support different signaling mechanisms
    -> concentrate on good specs for the centralized
       calculation/algos (even if that is maybe untypical IETF).
  
ID>> It is an ambitious agenda you outline, and certainly well beyond any scope Dave, Jeff & I had set. Absent a team of experienced author-editors committed to the project I'm quite wary. That said, I believe we can perhaps finesse the form and content of this specific draft to accommodate additional companion works that others with the interest might create, filling out much if not all of your proposal. Note please though, there are key aspects of the presented solution that benefit from using what seem to us as unique concepts & constructs provided in SR-MPLS. 

    Here are some issues i have with the current doc version:
    
    a) Target status
    
       I do not think a framework could/should be a standards track document.
       I think usually they are informative.

ID>> We'd heard some similar critique during the sessions in Montreal, and had then agreed to replacing the word 'framework' in the title with something less expansive and rephrase necessary portions of the document to better reflect what is the true essence. The document does describe in detail various protocol mechanisms, and therefore seems to me to therefore necessarily needs to be standards track, or perhaps experimental.
    
    b) Text quality
    
    -  The document does not IMHO yet well enough explain the framework.
       It would help a lot to put some pictures into the document
       with topologies like what was presented at IETF102, and another
       with components and layers of the framework, and highlight
       the interactions better.

ID>> Generally agreed. We'll undertake for the next version to add illustrations and put in the text surrounding explains the interactions.

    -  For example, the benefits and distinctions from existing
       solutions are not well summarized/explained, e.g:
       - minimizing number of nodes on a tree because
         - nodes do not support the scheme (not sure if this is
           considered
         - nodes not needed to do replication
       - calculating other than shortest path trees.
         Eg: there is no clear definition what a minimum cost tree is
         in this doc. It doesn't seem to be minimum spanning tree
         because that ha its root not necessarily in a PE. And
         it must be different from shortest path tree ? And its
         not steiner tree... ?

ID>> In the distributed algorithm described in the draft the initial form is always shortest-path. Consider it as isomorphic to unicast except for the direction of forwarding. Then the algorithm for roles & pruning is applied. We will look at the text and see how best to better emphasize this. In the off node algorithmic case, which perhaps is of particular interest for you, algorithms could and most likely would be different.
    
    c) Framework scope
      
    - In general, i would try to separate out the design of this
      framework from a particular choosen forwarding plane. To
      me, all the described mechanisms are quite independent of
      SR-MPLS, equally applicable to SRv6, classical MPLS, or
      equally IP tunneling & replication.

ID>> Again, the choice of the word 'framework' has perhaps been misleading. Our relatively modest project is to enable multicast within the scope of SR-MPLS. We recognized a necessity to provide hooks to engineer within the overall and still evolving form of SR-MPLS.
    
      I would really hate to have IETF invest into all the
      calculation schemes defined and then have that work tied
      up to just one forwarding plane plus maybe its son (SRv6).
    
    d) Centralized vs. distributed
    - The document tries to imply through the term "computing agent"
      that it can equally be performed centralized or cdecentralized/
      distributed, but is quite vague about the details.

ID>> While potential for forms of centralized compute is discussed, it is far from main objectives of this document. As noted already the draft primarily seeks to explain use of the shortest-path with then pruning and roles applied as appropriate to building multicast trees. With the recognition that using conventions of SID stacking centralized engineering can also be applied. This seems to be analogous to the hooks exposed in the work done on unicast segment routing architecture, that are then left open for use with further documents of general or specific engineering methods.
    
    - We have a bit the standardization issue in the IETF that
      IETF has not looked strongly into the algos when they are centralized
      because that does not require interoperability in consistent
      decision making. On the other hand, we also have some
      good but frustrating experience with distributed new
      path calculations like MRT.
    
    - In general, i will not believe right now whether or to what
      degree the results of a centralized path calculation approach
      using the ideas presented will achieve the same results as
      the distributed approach. If i am not mistaken, the example of
      MRT for example shows that in that particular case, the
      centralized result is better.
    
    - Personally,  would prefer if a framework would first
      concentrate on being very specific to the centralized
      algorithms proposed to be used. Only when those are known
      can you IMHO well vet the option of a distributed
      version. Thats how it was done AFAIK on MRT (centralized
      algorithms known for decades?). Persistent loops
      or the like (disconnected trees ?). The document
      hints at some possible issues.
    
    - The frustrating experience from the MRT experience is of
      course also that vendors and industry do not seem to be
      willing or capable at this time to invest into intelligent
      distributed calculations. I blame the really bad and
      inagile software infrastructure in typical network equipment.
      Hence also the reccommendation to focus on the centralized
      specification approach first.
    
ID>> Apologies but it's hard for me to comment directly on experiences and results from the MRT project given my quite limited exposure. I'd defer to you and others on how best to interpret and learn from that effort. 

    e) Justification/comparisons  
    
    -"This approach is proposed as a solution for networks for which an
      implementation of an alternative data plane, such as BIER, offers
      technical or economic challenges."
    
      There needs to be more justification text to support the necessity
      to invest into a framework.
    
      I would also like to see comparisons re. RSVP-TE, e.g.: what
      challenges would exist with that (the only one coming to mind
      is automatic transit over non-RSVP-TE P2MP nodes, but it would
      probably be easier to add that feature instead of reinventing
      a new scheme).
    
    - The IETF102 slides say that the solution utilizes SR-MPLS data plane
      in ways mLDP can not... didn't see representation/explanation of this
      claim in doc.

 ID>> Thanks. We will look more carefully at these compare/contrast topics in the next revision.

   
    f) Best WG ?
    
    - As outlined above, i think the mayority of the core framework work
      should be on the way how to calculate these (if i may call them
      that way) overlay trees, plus a bit the signaling schemes.
    
      I really doubt that PIM is the best WG to do this work.
      When writing up a framework for BIER-TE, Alia (back then AD)
      asked me to go to TEAS, claiming that TEAS should be responsible
      for all TE archticture/framework work. At least i think they
      could consult on what interfaces to design.
   
      The actual tree caluclation pieces... good question. RTWG
      would give it definitely more exposure and review than PIM,
      and especially when we'd take out the tie to a specific forwarding
      plane, that would also be a good logical place.

ID>> We were steered by ADs & others in IETF leadership to bring this work to PIM. This made some sense given that in substance is entirely multicast. We did present in RTG-WG in Montreal, and given the differences in discussion between that session and PIM certainly seems to be worthwhile having the broader exposure. The advice to take any core work on TE aspects into TEAS makes perfect sense. Unclear where to draw that line versus the dealing with protocol primitives specific to the unique data-planes and IGPs.
    
    Sorry for sounding like a Reichsbedenkentraeger (Royal Concern Officer),
    but better to bring up these issues now than in IESG review.
 
ID>> Your feedback is welcomed and appreciated. Much prefer to get this direct and frank commentary in the moment, than wait for an IESG review. And extra thanks for sharing what for me is an interesting new word.
   
    Cheers
        Toerless
    
    On Mon, Aug 06, 2018 at 06:24:51PM +0000, Michael McBride wrote:
    > Hello good people,
    >
    > Today begins a two week call for adoption of draft-allan-pim-sr-mpls-multicast-framework-00 which was presented in Montreal. There was a good discussion in the meeting and now it's time to gauge interest in adoption on the list. Please respond and let us know what you think about adopting this draft..
    >
    > https://tools.ietf.org/id/draft-allan-pim-sr-mpls-multicast-framework-00.txt
    >
    > thanks,
    > mike
    
    > _______________________________________________
    > pim mailing list
    > [e-mail]
    > https://www.ietf.org/mailman/listinfo/pim
    
    _______________________________________________
    pim mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/pim