Subject: Re: Aggregation problem for I-PMSI in MVPN

From: Rahul Aggarwal <[email-masked]>
Date: Mon, 2 Aug 2010 15:41:22 -0700

Hi Lin,

Please see below:

On Fri, 30 Jul 2010, Lizhong Jin wrote:

> Hi Rahul, Ben,
> What I mentioned at the session has been discussed on list before, but not
> ended. Before moving forward the status of
> draft-ietf-l3vpn-2547bis-mcast-bgp-08, I strongly suggest to resolve this
> technical issue.
>

What is the technical issue that you are referring to?

> The draft-jin-mpls-mldp-leaf-discovery-01 does not intend to solve above
> aggregation problem. The leaf discovery mechanism is intent to allow L3VPN
> Multicast to aggregate mLDP based P2MP LSP which is setup by other
> applications, e.g, static or mLDP inband signaling.
>

draft-ietf-l3vpn-2547bis-mcast and draft-ietf-l3vpn-2547bis-mcast-bgp 
provide a solution for aggregation when the P-Tunneling technology is mLDP 
based P2MP LSP.

> This is more like the situation of P2P LSP which can be used for aggregation
> for various application. For example, LDP based IP prefix LSP can be used
> for aggregation for PW, L3VPN and L2VPN. This should be also the case for
> multicast LSP, which can reduce the forwarding state for P routers. This is
> a very important issue for MPLS multicast. And the current problem is that
> mLDP based P2MP LSP can not be aggregated by various applications, because
> of leaf initiated nature of mLDP. That's what the leaf discovery want to
> solve.
>
> Does the above decription make sense?
>

No.

rahul

> BR
> Lizhong Jin
>
> =====================================================
> Date: Fri, 18 Jun 2010 11:53:55 +0800
> From: [email-masked]
> Subject: Re: Aggregation problem for I-PMSI in MVPN
> To: [email-masked]
> Cc: [email-masked], [email-masked],      Yakov Rekhter
>       <[email-masked]>,    [email-masked],
>       [email-masked],  [email-masked], [email-masked],
>       [email-masked]
> Message-ID:
>       <[email-masked]
>>
> Content-Type: text/plain; charset="us-ascii"
> OK, now I see two solutions:
> A: Setting the Leaf Information Required flag to 1 in the PMSI Tunnel
> attribute of its intra-as I-PMSI A-D route; (Yakov suggested)
> B: Delete I-PMSI A-D route suppression rule to section 9.1.1 of
> draft-ietf-l3vpn-2547bis-mcast-bgp-08 where already describes some
> suppression rules of intra-as I-PMSI A-D. (Eric suggested)
> I add another option, named C:
> C: Let other independent mLDP leaf discovery mechanism to solve this
> problem.
> It would be appreciated if there are any other comments from the WG, and
> decide which option is most optimized.
> BR
> Lizhong
>
> Eric Rosen <[email-masked]>
> 2010-06-17 22:36
> Please respond to
> [email-masked]
>
> To
> [email-masked]
> cc
> [email-masked], [email-masked], [email-masked], Yakov
> Rekhter <[email-masked]>, [email-masked],
> [email-masked], [email-masked], [email-masked]
> Subject
> Re: Aggregation problem for I-PMSI in MVPN
>
>
>
>> I think it is a bit difficult to ensure such "fact" as you described in
> a
>> mvpn network.
> On the contrary, an operator would have to go to considerable trouble to
> get
> himself into a situation like this.  If you want each PE to auto-discover
> all the other PEs in the same MVPN, you shouldn't suppress the I-PMSI A-D
> routes!  That is, if you go to the trouble of explicitly turning off the
> auto-discovery mechanisms, you shouldn't then complain that auto-discovery
> isn't working.
>

---

From: [email-masked]
Date: Tue, 3 Aug 2010 20:38:27 +0800

Hi Rahul,
Thank you for your reply. Please see the answer in line.

BR
Lizhong
 
----------------------------------------------------------------------------------

> What is the technical issue that you are referring to?

[Lizhong]: the issue is described in the following link:
http://www.ietf.org/mail-archive/web/l3vpn/current/msg02710.html
Please see Yakov's reply in the following link:
http://www.ietf.org/mail-archive/web/l3vpn/current/msg02711.html
Please get Eric's reply in the following link:
http://www.ietf.org/mail-archive/web/l3vpn/current/msg02714.html
We did not get the conclusion for this problem. We should evaluate the 
PROS and CONS, and get the solution.

> provide a solution for aggregation when the P-Tunneling technology is 
mLDP 

[Lizhong]: The above two drafts do provide a solution for mLDP based P2MP 
LSP aggregation. But as pointed out in 
draft-jin-mpls-mldp-leaf-discovery-01 section 2, the mLDP based P2MP LSP 
setup by applications except MCAST, e.g, static or mLDP inband signaling, 
can not be aggregated or used by MCAST. The two mcast drafts only solve 
the P2MP LSP aggregation which is setup by mcast itself. If I have not 
clarify this, please let me know.

> > Does the above decription make sense?

[Lizhong]: see above reply, thank you.

> > Lizhong Jin

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.