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

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
> pim@ietf.org
> https://www.ietf.org/mailman/listinfo/pim