Subject: Aggregation problem for I-PMSI in MVPN

From: [email-masked]
Date: Thu, 10 Jun 2010 22:41:46 +0800

Hi all experts,
draft-ietf-l3vpn-2547bis-mcast-bgp-08 described the BGP procedure for 
mcast, and in section 9.1.1, it is pointed out that in one case PE SHOULD 
NOT originate an Intra-AS I-PMSI A-D route.

And in section 9.1.2, it is point out that PE will accept one BGP A-D 
route only when at least one of the Route Targets of the route matches one 
of the import Route Targets configured for a particular VRF on the local 
PE. That means if none of the import RT for local VRF matchs the received 
RT, it will reject this BGP A-D route. Do you think it is reasonable to 
allow import and export RT asymmetric for BGP A-D route?

Then we can see that every PE in one MVPN will not correctly know the VPN 
member through BGP A-D, because some PE will not originate BGP A-D or PE 
may reject the received BGP A-D but peer PE may accept if import RT and 
export RT are asymmetric. If the I-PMSI is setup by mLDP based P2MP LSP, 
then root PE of this P2MP LSP will not know the leaf PE of this P2MP LSP 
in some cases. Then root PE can not use this mLDP based P2MP LSP to do 
aggregation for other new MVPN. There is the same problem for P-multicast 
tunnel setup by PIM-SM.

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

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 15 Jun 2010 09:16:38 -0700

Hi,

First of all, sorry for the delay...

> allow import and export RT asymmetric for BGP A-D route?

Yes, it is reasonable to allow import and export RTs be different.
One possible application of this is to build hub-and-spoke VPNs.

> aggregation for other new MVPN. There is the same problem for P-multicast 

If the I-PMSI tunnel is setup by mLDP P2MP LSP then it is certainly
true that in some cases the information provided by the I-PMSI A-D
routes may not be sufficient for the root of such P2MP LSP to
determine all the leaves of that P2MP LSP, which in turn (as you
correctly pointed out) makes it hard to determine whether to aggregate
this LSP with any other LSPs.

In this case the root could obtain information about the leaves by
setting to 1 the Leaf Information Required flag in the PMSI Tunnel
attribute of its I-PMSI A-D route. That would force all the leaves
of that P2MP LSP to originate Leaf A-D routes, which would provide
the root PE with the information about the leaves. See 9.2.3.2 and
9.2.3.4.

Yakov.

---

From: [email-masked]
Date: Wed, 16 Jun 2010 20:09:04 +0800

Hi Yakov,
Thank you for your reply. For your second point, your suggested method is 
right, but section 9.2.3.4 only deals with Inter-AS I-PMSI A-D route, not 
Intra-AS I-PMSI A-D route. It is necessary to make some explicit 
description in section 9.2.3.4, or some other place in the draft.

Best Regards
Lizhong Jin

Yakov Rekhter <[email-masked]> 
2010-06-16 00:16

To
<[email-masked]>
cc
[email-masked], [email-masked], [email-masked], 
[email-masked], [email-masked], [email-masked], 
[email-masked]
Subject
Re: Aggregation problem for I-PMSI in MVPN

Hi,

Yakov.

---

From: Eric Rosen <[email-masked]>
Date: Wed, 16 Jun 2010 14:46:58 -0400

> attribute of its I-PMSI A-D route.

Well, from section 9.1.1 "Originating Intra-AS I-PMSI A-D routes":

     + The Leaf Information Required flag of the PMSI Tunnel attribute
       MUST be set to zero, and MUST be ignored on receipt.

I think the answer to the original question is that if you want to
aggregate several I-PMSIs into a single tunnel, based on the fact that they
have the same set of receivers, then all PEs need to originate the I-PMSI
A-D routes, and the import/export RTs must be configured so that all
transmitters receive this A-D routes from all receivers.

---

From: [email-masked]
Date: Thu, 17 Jun 2010 08:55:06 +0800

Eric,
I think it is a bit difficult to ensure such "fact" as you described in a 
mvpn network. If some kind of signaling can do this insurance, then that's 
good.

BR
Lizhong

Eric Rosen <[email-masked]> 
2010-06-17 02:46
Please respond to
[email-masked]

To
Yakov Rekhter <[email-masked]>
cc
[email-masked], [email-masked], [email-masked], 
[email-masked], [email-masked], [email-masked], 
[email-masked], [email-masked]
Subject
Re: Aggregation problem for I-PMSI in MVPN

aggregate several I-PMSIs into a single tunnel, based on the fact that 
they

---

From: Eric Rosen <[email-masked]>
Date: Thu, 17 Jun 2010 10:36:42 -0400

> 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: Richard Li <[email-masked]>
Date: Thu, 17 Jun 2010 09:19:33 -0700

Eric is right. The "Leaf Info Required" flag is not set in I-PMSI. Instead
it is set in S-PMSI.

For the aggregate I-PMSI to work, the (upstream) MPLS label should be used.
The upstream MPLS label is carried in PMSI attribute attached to Intra-AS
I-PMSI A-D route. The Tunnel ID and the route targets are not sufficient
enough for the receiver to set up the forwarding state in the case of
aggregate I-PMSI.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Eric Rosen
Sent: Wednesday, June 16, 2010 11:47 AM
To: Yakov Rekhter
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: Aggregation problem for I-PMSI in MVPN

I think the answer to the original question is that if you want to aggregate
several I-PMSIs into a single tunnel, based on the fact that they have the
same set of receivers, then all PEs need to originate the I-PMSI A-D routes,
and the import/export RTs must be configured so that all transmitters
receive this A-D routes from all receivers.

---

From: [email-masked]
Date: Fri, 18 Jun 2010 11:53:55 +0800

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: Add 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

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

On the contrary, an operator would have to go to considerable trouble to 
get