[c-nsp] Class-based Tunnel Selection questions

[Oliver Boehmer (oboehmer)]

Pete Templin <mailto:petelists at templin.org> wrote on Saturday, May 21,
2005 5:33 PM:

> Oliver Boehmer (oboehmer) wrote:
> 
>>> As far as incoming traffic supported, the doc says it supports:
>>> 
>>> 1: Unlabeled or MPLS (CsC) VRF traffic into a PE router.
>>> 2: Unlabeled or MPLS traffic into a P router.
>>> 
>>> Does it not support unlabeled traffic coming into a P router?
>> 
>> It does, you mentioned it, didn't you? "2: Unlabeled or MPLS traffic
>> into a P router."
> 
> Sorry, the sinus medication still isn't working its magic.  I meant to
> ask about unlabeled traffic into a PE router, i.e. ipv4 customer
> traffic wanting to make its way to the Internet and vice versa.

Yes, this works.. when unlabeled IPv4 non-vrf traffic is involved, there
is no distinction between P and PE.

>>> As far as the restrictions, "The operation of CBTS is not supported
>>>  with AToM..."; does that mean AToM packets won't travel on any
>>> tunnels, or simply that AToM is not CoS-aware and therefore not able
>>> to be deposited into the "correct" class-based tunnel?
>> 
>> As far as I know, this restriction only applies if L2VPN-PE and TE
>> head-end are on the same box.  So if you have
>> 
>> PE -- P === P -- PE
>> 
>> and you have parallel, CBTS-enabled TE tunnels between the two P
> 
> What happens if the L2VPN-PE is the TE head-end?  In this situation, I
> don't care if the PE can't select the "right" (i.e. selected by CoS)
> tunnel, just whether enabling CBTS will prevent AToM traffic from
> being traffic-engineered.  Shifting my TE tunnels to the next node
> results in a massive loss of granularity, which I'd like to avoid.

Just checked, and the restriction is that we make no guarantee that the
AToM traffic will use the "right tunnel" (based on EXP-bits and CBTS
config), so you can continue to use TE on the L2VPN-PE and use CBTS on
the same router for other traffic.

	oli