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" <[EMAIL PROTECTED]> To: "Eric Van Tol" <[EMAIL PROTECTED]>; <[email protected]> Cc: "Yastrebov, Valery" <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Eric Van Tol > Sent: Friday, September 21, 2007 5:42 PM > To: [email protected] > 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 [email protected] > https://puck.nether.net/mailman/listinfo/juniper-nsp > > _______________________________________________ > juniper-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
