The MPLS WG Archive

[Rahul Aggarwal <rahul@juniper.net>]

Hi Adrian,

Some comments inline:


> > 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 the problem statement should cover both packet and non-packet
traffic. We can clarify this in the 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.
>

Ok.

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

This is getting into solution details. Leaf initiated join is one possible
way of adding receivers to a P2MP LSP. The problem statement was simply
trying to capture this requirement.

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

There is collaborative work in progress on a requirements document, that
in turn will drive the solutions. Its premature to place boundaries on the solutions before the
requirements are well spelled out. This is what the problem statement was
trying to capture.

Thanks,
rahul

> Cheers,
> Adrian
>
>