Re: Invitation to discuss: "P2MP problem statement"

> I would like to have your response on
>
> 1. the content of the problem statement
> 2. whether the mpls working group should ask the ADs
>     that a new milestone om p2mp mpls should be added
>     to our charter
>
> If there is support we plan to take this as an separate item
> (not include it in the more general charter update) to the
> ADs. Again this is a question for which I would like boths
> the pros and cons to speak up. Silence will not be interpreted
> (one way or another).

Loa,

I consider point-to-mutlitpoint services to be important in MPLS and GMPLS 
networks and
believe that they should receive attention from the IETF.

My question for you (or perhaps for the ADs) is whether this is MPLS or CCAMP 
work. This
is a distinction which is repeatedly fudged and I don't see any clear division 
of labor
between the two WGs.

Note that the problem as stated, and the applicability of the solutions is as 
useful in
optical or TDM networks as it is in packet-based MPLS networks.

The problem statement is well written and convincing (IMHO) although it only 
talks about
packet traffic. It would be useful if it either distinguished between packet and
non-packet traffic (aknowledging that GMPLS signaling may use similar mechnisms 
in the
future) or brought the two together in one problem statement.

I think it would be a good idea if the problem statement made an explicit 
non-goal the
computation of p2mp paths and the determination of split points.

While the problem statement describes the need to allow the addition of 
receivers to a
p2mp LSP it does not discuss 'leaf initiated join'. I believe this was a 
feature that was
considered useful in ATM and should either be included here or explicitly 
excluded with a
reason.

I wonder about the sense of the milestone that says "to produce a small number 
of solution
draft(s)" unless the objective is to produce several for the WG to choose 
between. We
would be well advised to avoid developing alternate solutions that go forward 
to RFC. Can
we not nip this in the bud by puting all the interested parties in a design 
team together
and having them come up with just one solution?

Cheers,
Adrian