[c-nsp] Re: [j-nsp] Re: CBTS-like functionality under JUNOS?

[Piotr Marecki]

----- Original Message ----- 
From: "Aaron Daubman" <daubman at gmail.com>
To: "cisco-nsp" <cisco-nsp at puck.nether.net>; "juniper-nsp" 
<juniper-nsp at puck.nether.net>
Sent: Monday, August 08, 2005 10:14 PM
Subject: [j-nsp] Re: CBTS-like functionality under JUNOS?


> First, another question:
>
> Andy, you are right - diffserve-te is what I was looking for...
IMHO not exactly - Junos DS-TE won't automagically forward traffic with 
different FC through
relevant LSP ( CT[0-3] mapping ). You need still use FBF/CBF etc
> unfortunately, on the Juniper DS-TE LSP site, it states:
> http://www.juniper.net/techpubs/software/junos/junos73/swconfig73-mpls-apps/html/mpls-diffserv-config16.html#1046243
> "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
> these routers."
> 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?
>

It's not Juniper specific requirement [example assume IS-IS tlv numbering] - 
it is using
proper way to advertise via subTLV 12  , while Cisco is using proprietary 
subTLV 251 ( or something
like that) - moreover Cisco implementation only considers one additional 
"sub-pool" -  priority queue
information in addition to standard TE - while IETF DS-TE model is more 
flexible. Therefore IGP signalling of
DS-TE topological information is in Cisco case proprietary , not the other 
way as you mentioned

> 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?
> AND
>>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
> DSCP/EXP/etc...
>
> 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
> traffic...
> ...if all that makes sense =)

Well , several perl/[insert your favorite tool] scripts can provide some 
help here - also
i can think (at least in fbf case) of some smart definition so configuration 
process can be made much
more simple.
>

> Thanks again,
>     ~Aaron
>

regards

Piotr Marecki