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

From: Vero Zheng <[email-masked]>
Date: Tue, 2 Jul 2013 08:20:29 +0000

Yes/Support

This draft basically extent the mLDP over Target LDP Session. According to this draft, the Upstream LSR could either be a BGP next-hop or a RSVP-TE tunnel endpoint. No protocol extension needed.
I feel this is useful in operation networks.

Nits:
Both section 1.3 and section 2 has reference to section 1.3.1 which should be section 1.2.1

Cheers, Vero

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Loa
> Andersson
> 发送时间: 2013年6月25日 18:44
> 收件人: [email-masked]
> 抄送: [email-masked]; [email-masked]
> 主题: [mpls] working group lst call on draft-ietf-mpls-targeted-mldp
> 
> Working Groups,
> 
> PWE3 working group,
> Working Group,
> 
> this is to start a two week Working Group last call on
> draft-ietf-mpls-targeted-mldp-02.txt.
> 
> Please send your comments to the mpls working group
> mailing list ([email-masked]).
> 
> Please send both technical comments, and if you are happy
> with the document as is also indications of support.
> 
> There are no IPR claims against this draft.
> 
> The co-authors have earlier stated that they are not aware
> of any IPRs applicable to this draft.
> 
> If anyone else in the working group are aware of IPRs claims against
> this draft, the time to disclose that is now.
> 
> This working group last call will end on July 9, 2013.
> 
> /Loa
> for the wg co-chairs
> --
> 
> 
> Loa Andersson                        email: [email-masked]
> Senior MPLS Expert                          [email-masked]
> Huawei Technologies (consultant)     phone: +46 739 81 21 64
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Lizhenbin <[email-masked]>
Date: Wed, 3 Jul 2013 07:13:52 +0000

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, if node U has several downstream nodes, some downstream nodes choose 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.

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. 

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. 

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.

Regards,
Robin

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Loa Andersson
发送时间: 2013年6月25日 18:44
收件人: [email-masked]
抄送: [email-masked]; [email-masked]
主题: [mpls] working group lst call on draft-ietf-mpls-targeted-mldp

Working Groups,

PWE3 working group,
Working Group,

/Loa
for the wg co-chairs
--

---

From: Loa Andersson <[email-masked]>
Date: Wed, 10 Jul 2013 09:14:42 +0200

Working Group,

This working group last group call has been closed.

There has been comments, could the authors please address the
comments and re-post a new version of the draft as necessary.

/Loa
for the wg co-chairs

--

---

From: Eric Rosen <[email-masked]>
Date: Mon, 15 Jul 2013 10:28:50 -0400

Thanks for your comments.

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