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

From: [email-masked]
Date: Fri, 6 Aug 2010 10:30:38 +0800

Hi,
Send again, because of updating Ben's email. Sorry for the inconvience, 
Ben.

BR
Lizhong

JinLiZhong/user/zte_ltd wrote on 2010-08-03 20:38:27:

> Hi Rahul,
> Thank you for your reply. Please see the answer in line.
> 
> BR
> Lizhong
> 
> 
----------------------------------------------------------------------------------
> Rahul Aggarwal <[email-masked]> wrote on 2010-08-03 06:41:22:
> 
> > 
> > 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?
> 
> [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.
> 
> 
> > 
> > > 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.
> 
> [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.
> 
> > 
> > > 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.
> 
> [Lizhong]: see above reply, thank you.
> 
> > 
> > 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:
> > >       <OFC119FA6A.DB832366-ON48257746.00130833-48257746.
> [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.

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