The MPLS WG Archive

[Jean Philippe Vasseur <jvasseur@cisco.com>]

Hi,

At 12:19 AM 8/18/2003 +0100, Adrian Farrel wrote:
> > I would like to have your response on
> >
> > 1. the content of the problem statement

clear and well written - just some additional comments in line,

> > 2. whether the mpls working group should ask the ADs
> >     that a new milestone om p2mp mpls should be added
> >     to our charter
> >

Personally in favor of adding this item to the 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.

Altough some of the solutions will be applicable to both, I'm not sure that 
they should be combined in the same statement. Requirements for p2mp packet 
based LSPs are identified, this is less clear for non packet based networks.

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

I would rather say that p2mp path computation should be a non explicit goal 
... instead of an explicit non-goal. Indeed, the algos do not have to be 
included in the solutions of course but each solution may have direct 
implications on p2mp path computation (in term of efficiency, ...) : as 
such, this aspect should not be excluded from the list of criteria to 
evaluate the respective possible solutions.

JP.

>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