[j-nsp] Re: CBTS-like functionality under JUNOS?
daubman at gmail.com
Mon Aug 8 16:14:00 EDT 2005
First, another question:
Andy, you are right - diffserve-te is what I was looking for...
unfortunately, on the Juniper DS-TE LSP site, it states:
"All the routers participating in the LSP must be Juniper Networks
routing platforms running JUNOS Release 6.3 or later. The network can
include routers from other vendors and Juniper Networks routers
running earlier versions of the JUNOS software. However, the
Differentiated-Services-aware traffic engineering LSP cannot traverse
Seeing as how I'm working with GSRs and M320s, is there any
vendor-interoperable way to approximate this? I don't understand what
is driving the Juniper-specific requirement above - it seems that this
would be an ingress-only function that would not affect other LSRs
along the path, no?
Also, has anybody done interop test with Cisco's CBTS configured at the ingress?
Now to try and answer the two questions:
> CBTS loks to be the same feature like JUNOS CBF. After reacing cisco doc
> I do not see big funcional differences.
> What is the problem? What you try to achive?
>Can You explain little bit more why CBF is not enough ? In another words,
> what are Your exact requirements that are not meet by CBF ?
> Well , one can try filter-based forwarding , with several forwarding routing
> instances , each with different
> lsp as next-hop for particular prefix - but all depends on your requrements
CBF/FBF/PBR would get the job done, however, if I were to expand this
experiment to a much larger network (or even turned this into a meshy
network with all 8 CoS) these manual methods of directing traffic to
the appropriate path become very cumbersome and difficult to manage.
Since these methods are both destination AND class specific, there
would be many statements...
What CBTS/DSTE-LSPs allow is the automatic selection of the correct
path to a given dynamically learned destination based on
e.g. rather than having to manually configure EF traffic destined to
10.10.0.0/16 t6 take Tunnel4, Tunnel4 can instead announce its
reachable networks, combining a CoS knob to be used in selecting the
best path, so that any EF traffic will traverse Tunnel4 as it is the
only Tunnel that can reach 10.10.0.0/16 that is marked to carry EF
...if all that makes sense =)
More information about the juniper-nsp