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

[Andrew Ramsey]

Aaron,

You could build multiple LSPs between PE pairs and use policy to route
packets into the LSPs based on community, etc...

The policy would look something like:

policy-statement map_packets_into_lsps {
    term one {
        from community blah;
        then {
            install-nexthop lsp good_one;
        }
    }
    term two {
        from community blah2;
        then {
            install-nexthop lsp not_so_good_one;
        }
    }
}

Then apply it to the forwarding table.

Of course you end up with per-destination granularity.

Andy

>-----Original Message-----
>From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-
>bounces at puck.nether.net] On Behalf Of Piotr Marecki
>Sent: Monday, August 08, 2005 5:19 PM
>To: cisco-nsp; juniper-nsp
>Subject: Re: [j-nsp] Re: CBTS-like functionality under JUNOS?
>
>
>----- 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
>
>_______________________________________________
>juniper-nsp mailing list juniper-nsp at puck.nether.net
>http://puck.nether.net/mailman/listinfo/juniper-nsp