Re: [mpls] 答复: working group lst call on draft-ietf-mpls-targeted-mldp

[Eric Rosen <[e-mail]>]

Thanks for your comments.

> We think the targeted mldp scenario is necessary. After review, follow
> comments are proposed:

> 1. Since using unicast or multicast tunnel is decided by downstream node,
> unicast and others choose multicast, then what is U's choice? Maybe it can
> treat the multicast tunnel as one branch with other unicast tunnel or can
> use one new capability to negotiate this before MP-LSP setting up.

Actually, we presupposed that the tunneling technique would be predetermined
by the Service Provider, and that the provisioning process would ensure that
all nodes know in advance what kind of tunneling is to be used.  I see now
that this presupposition is not clearly stated in the draft; I'll add some
text to make it clear.

It is conceivable that one might want to choose the tunneling type based on
some characteristic of the data flow.  E.g., perhaps one would want to use
unicast tunneling for flows of low bandwidth (or low fanout), but use an
RSVP-TE P2MP tunnel for other flows.  However, that choice would need to be
made by the upstream node.

I don't think we need to support that scenario in this draft, but if any
Service Provider shows interest in that scenario, additional procedures could
be devised and a followup draft written.

> 2. Maybe the procedure for the unsymmetrical network can be improved. For
> example, the next hop interface from D to the root is a physical interface
> but from U to D is an RSVP-TE tunnel , so D send one label mapping but
> maybe U is waiting for one upstream label request.

Section 1.3.1 describes two ways of determining the upstream LSR, and allows
for other methods.  (Section 1.4 seems to disallow other methods; that's a
mistake.) The intention is to specify two possible methods, but not to rule
out other methods that might make sense in a particular Service Provider's
environment.

We do presume that the method of determining the upstream LSR is known a
priori, rather than determined dynamically.  It is true that we have not
specified a method that applies to the sort of asymmetric network you
describe.

I'll add some text to make it clear that while alternative methods of
determining the LSR may be needed in some environments, specification of
those alternative methods is outside the scope of the current document.

> 3. In section 3(Targeted mLDP with Multicast Tunneling), if U choose using
> different multicast tunnel for different MP-LSPs, maybe it can try other
> methods to avoid upstream label allocation. For example, using one
> 'Recursive Opaque TLV' in RFC6512, we can redirect the root to the U, and
> trigger one multicast tunnel setup between U and D. Even we can avoid
> tunneling since node D knows the in-label should map to which MP-LSP.

If you want mLDP-created P2MP LSPs in the core, and don't want to aggregate,
then the use of Targeted mLDP is not the best solution.

> 4. The unicast tunneling method is still unsatisfactory since it may cause
> traffic congestion if some of the unicast tunnels shares one link and this
> is a very possible case under current backbone network deployment.

Certainly multicast tunneling provides a more optimal use of bandwidth than
unicast tunneling.  However, some Service Providers regard the sub-optimal
use of bandwidth as a good trade-off for the elimination of multicast state
and control plane load in the "intermediate nodes" along the path of the
unicast tunnel.  This draft provides procedures for both tunneling
techniques, but intentionally does not make any judgments about which
technique is better in which circumstances.