Re: [j-nsp] Carrier's carrier MPLS VPN

From: Robert Raszuk (raszuk@cisco.com)
Date: Wed Feb 20 2002 - 08:39:36 EST


Dimitri,

> They do it differently. ;) Cisco is currently making some efforts in getting
> proper rfc3107 support (BGP labelled-unicst) into 12.0ST stream, which does
> not work properly as yet. There are couple of things, but the main show
> stopper is the fact that current ST code claims that it sends "implicit-null"
> but label value sent is in fact "1", where it should have been 3.

Yes we had a bug, it is fixed now. In the EFT images you could advertise
explicit-null "0" value for your testing. New images will correctly
advertise value of 3 for implicit-null.

> I suspect
> that value of "1" is inherited from TDP (?), but we couldn't find the way of
> turning the things around.

Yes it comes back to the times when the value was not standardized yet,
but cisco was already shipping tag switching :).

> Cisco is busy looking into that, but this support
> is in _BETA STAGE_, so no firm promises as of now.

As far as promises as you know ST is over and the ST features are now in
120S. So next 120S image out (22 or 23)S should have the correct code.

Rgs,
R.

PS. If you need a new EFT images with ipv4+label code pls contact myself
offline.

> Dmitri Kalintsev wrote:
>
> Hi Javier,
>
> > I see from the 5.2 documentation how should Carrier's carrier VPNs
> > configured but I was trying to do the comparison with how Cisco
> > supports them.
>
> They do it differently. ;) Cisco is currently making some efforts in getting
> proper rfc3107 support (BGP labelled-unicst) into 12.0ST stream, which does
> not work properly as yet. There are couple of things, but the main show
> stopper is the fact that current ST code claims that it sends "implicit-null"
> but label value sent is in fact "1", where it should have been 3. I suspect
> that value of "1" is inherited from TDP (?), but we couldn't find the way of
> turning the things around. Cisco is busy looking into that, but this support
> is in _BETA STAGE_, so no firm promises as of now.
>
> > In Cisco carrier's carrier simply means enabling LDP on the PE-CE
> > interfaces. That way, routes in the vrf which have a VPN label received
> > through MP-BGP are assigned a label and advertised via LDP to the CE.
>
> It also means that you have to run common IGP between your CEs and PEs (of
> course, it is run inside vrf, but well, how many OSPFs you're happy with
> running on your GSR?) Alternative, of course is RIPv2. ;)
>
> > In the Juniper docs it just says that MPLS is enabled in the CE, but
> > in the config examples there is nowhere saying
> > protocols
> > ldp
> > interface (interface to PE)
> >
> > and the same in the PE. On the other hand, the only command to
> > configure this arquitecture is the "labeled-unicast".
>
> It enables rfc3107. You don't need an LDP session for this to work.
>
> > Can someone tell me what exactly this command does, and in general,
> > how does Juniper implement carrier's carrier, that is, does it use LDP
> > for PE-CE label advertising, can the CE be non-Juniper in this case?,
>
> Well, answer is "it depends". If you happy with keeping full routing table
> inside your vrf, you won't need any LDP or labeled-unicast stuff between your
> PE and CE, so your CE can be anything, as it won't need any MPLS support. If
> you want your P/PE cloud only know about itself and keep internal vrf routes
> number to required minimum, you'll have to have working rfc3107 support on
> your CEs.
>
> > must the PE-CE protocol be BGP? (in Cisco it is not necessary)
>
> Yes. eBGP to be precise.
>
> SY,
> --
> CCNP, CCDP (R&S) Dmitri E. Kalintsev
> CDPlayer@irc Network Architect @ connect.com.au
> dek @ connect.com.au phone: +61 3 9674 3913 fax: 9251 3666
> http://-UNAVAIL- UIN:7150410 mobile: +61 414 821 382



This archive was generated by hypermail 2b29 : Mon Aug 05 2002 - 10:42:39 EDT