[j-nsp] JUNOS MPLS vs. IOS MPLS

[Piotr Marecki]

Ehlo,



Slight correction -> JNPR doesn't use DoD advertisement mode, it's 
downstream unsolicited as well

as in CSCO case. Difference is that JNPR uses ordered control mode, e.g. it 
won't advertise label mapping unless it receives binding from its downstream 
neighbor OR it is egress router for that FEC.

Also, as far as interoperability is concerned, those different modes play 
quite well together, and you can filter CSCO advertisements so it will 
propagate only loopbacks  (to avoid mess in inet.3).



Now, if we speak about TE compatibility, it works quite well too, although 
one has to be aware of some differences, and it may or may not affect your 
case, depending on requirements.

For example, full blown DS-TE in only in JUNOS and IOS/XR, whether IOS uses 
proprietary implementation to disseminate additional subpool bandwidth (e.g. 
priority queue). When you'll be using

FRR, you need to take into account that JNPR has one-to-one and facility 
backup implemented (aka fast-reroute and link/node protection, 
respectively), whereas CSCO (both IOS and IOS/XR) have

only facility backup. Of course, there are more differences, like ability to 
forward traffic based on QoS class (junipers CBF, csco class-based tunnel 
selection - similar but more limited than in jnpr ), P2MP

RSVP-TE which only JNPR has (and I'm not sure if CSCO is into that area at 
all, given they follow multicast GRE for mdt approach), RSVP scalability 
extensions etc.

Having said that, if you will be aware of differences and consider them in 
the early stage of design , you shall be quite safe.



regards

Piotr Marecki

----- Original Message ----- 
From: "Yastrebov, Valery" <vyastrebov at amt.ru>
To: "Eric Van Tol" <eric at atlantech.net>; <juniper-nsp at puck.nether.net>
Cc: "Yastrebov, Valery" <vyastrebov at amt.ru>
Sent: Friday, September 21, 2007 3:54 PM
Subject: Re: [j-nsp] JUNOS MPLS vs. IOS MPLS


> Right,
> In JUNOS LDP Downstream On Demand mode realized
> Downstream Unsolicited - IOS
> It explains such behavior
> Sometimes I'm implementin in IOS "on demand" in the follow manner:
> !
> tag-switching advertise-tags for ldp-binding-filter
> !
> !
> ip access-list standard ldp-binding-filter
> remark -- anounce labels only for Loopback address space --
> permit 10.255.0.0 0.0.255.255
> !
> ____________________________________________
>
>
> -----Original Message-----
> From: juniper-nsp-bounces at puck.nether.net
> [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Eric Van Tol
> Sent: Friday, September 21, 2007 5:42 PM
> To: juniper-nsp at puck.nether.net
> Subject: [j-nsp] JUNOS MPLS vs. IOS MPLS
>
> All,
> I am venturing into the fray of JUNOS/IOS MPLS interop and have some
> questions.  It's my understanding that with JUNOS, LDP will only
> advertise loopback routes into the inet.3 table, unless otherwise
> configured.  IOS appears to announce every known route via LDP by
> default.  What are best practices for handling route advertisements
> through LDP in a multivendor environment?  Would one implement
> restrictive filtering on the Cisco or rather configure less restrictive
> filtering on the Juniper?  While I imagine this depends on one's own
> design goals, maybe someone can comment on which one, to them, seems to
> add less complexity.
>
> Also, what other types of pitfalls would one expect when trying to
> implement MPLS and TE in a mixed Juniper/Cisco environment?  Links would
> definitely also help get me on the right track.
>
> TIA,
> evt
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp