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

From: Toerless Eckert <[email-masked]>
Date: Wed, 8 Aug 2018 22:14:45 +0200

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

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.

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.

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

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.

  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.

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

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.

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.

Sorry for sounding like a Reichsbedenkentraeger (Royal Concern Officer),
but better to bring up these issues now than in IESG review.

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim

---

From: "Duncan, Ian" <[email-masked]>
Date: Fri, 10 Aug 2018 17:50:01 +0000

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" <[email-masked] on behalf of [email-masked]> wrote:

    
  
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. 

    a) Target status

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

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

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

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.

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.

    

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. 

    

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

    f) Best WG ?

   

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.

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

---

From: Michael McBride <[email-masked]>
Date: Fri, 10 Aug 2018 22:21:09 +0000

Hello Ian,

Indeed, thank you wg for the, mostly, thoughtful comments. Frank commentary should also occur with any of our wg adopted documents, no need to wait for IESG review. And just because we've agreed to work on a draft doesn't equate to agreeing to progressing a draft. We (IETF, PIM) should consider being a bit more liberal in what we accept (into a wg) and conservative in what we send (to the IESG). 

There's interest in this type of work so please keep working on this and perhaps involve Toerless, Eric and others in the next rev. We can then revisit with PIM, TEAS, etc as seems most appropriate.

As the draft currently stands, we've received enough feedback already to show no consensus to accept this work as a wg document.

Thanks,
mike

-----Original Message-----
From: Duncan, Ian [mailto:[email-masked]] 
Sent: Friday, August 10, 2018 10:50 AM
To: Toerless Eckert <[email-masked]>; Michael McBride <[email-masked]>
Cc: [email-masked]
Subject: Re: [**EXTERNAL**] Re: [pim] Call for adoption of sr-mpls-multicast-framework

Hello Toerless --

Best .. Ian

======

    

    
    a) Target status

    
    b) Text quality

    
    c) Framework scope

    

    

    

    

    

    f) Best WG ?

   

 
   
    Cheers
        Toerless