[j-nsp] MPLS and QoS at penultimate hop ?

[Christopher E. Brown]

The table-lable bit is the one time I am aware of that the forwarding
class is changed in the middle without the system being specifically
setup to do so.


Assuming that you have mpls and ipv4 classifiers on all interfaces.

Incoming is classified on the label, label pop, outgoing is transmitted
as same class.  If you have a ipv4 rewrite in place it would kick in.





On 2/5/13 12:31 AM, Alexandre Snarskii wrote:
> On Mon, Feb 04, 2013 at 09:36:10AM -0900, Christopher E. Brown wrote:
>>
>> The packet is classified on input.
>>
>> *UNLESS* you use table-label in a l3vpn, then it gets re-classified
>> after the label POP.
> 
> Intresting. However, my question is not about l3vpn, it is about plain 
> old IPv4 packet with one MPLS header entering PHP router programmed to Pop 
> this header and forward this packet towards next (egress) router..
> 
> Example: 
> 
> ingress router:
> 
> AA.BBB.205.0/25    *[BGP/170] 6w1d 22:28:33, MED 100, localpref 200, from AA.BBB.224.5
>                     > to AA.BBB.233.133 via ae2.6, Push 604050
> 
> (BA-classification is done on ipprec/dscp of ingress packet)
> 
> PHP router: 
> 
> 604050             *[LDP/9] 4d 00:37:22, metric 1
>                     > to AA.BBB.233.13 via ae4.9, Pop      
> 604050(S=0)        *[LDP/9] 4d 00:37:22, metric 1
>                     > to AA.BBB.233.13 via ae4.9, Pop      
> 
> (BA-classification is most possibly done on ip-prec after Pop is done, 
> but that's the point where I'm not sure.... Classification on EXP may be 
> more accurate: as there are no "payload type" field in MPLS header, this 
> router just can't know that packet's content is IPv4).
> 
> 
>> On 2/3/13 6:03 PM, Chris Kawchuk wrote:
>>> It was my understanding that the label was "logically" popped on
>>> Egress (in terms of how one would envision the packet flow); hence
>>> the outer label EXP bits were evaluated by the BA classifier on
>>> ingress properly. (Whether it's popped on ingress, yet evaluated
>>> prior-to-pop is a mechanics thing..)
>>>
>>> But yes, I have no documentation I can point to; off the top of my
>>> head that the above is indeed true. I would be interested to know for
>>> future information sake that the JNPR box is indeed "doing the right
>>> thing" so to speak? i.e. since the PIC/MPC pops the Layer-2
>>> information as well, it needs to be able to read the 802.1P bits, if
>>> there is a 1p-VLAN tag BA applied to the interface. Hopefully we're
>>> also reading the outer EXP label at the same time; as this would make
>>> sense.
>>>
>>> i.e. if you're doing VLAN pop/swapping, you'd need to retain any
>>> BA-p-tag specific classification there as well, prior to any tag
>>> manipulation.
>>>
>>> 400 quatloos says it's done on ingress before the label is popped.
>>>
>>> - Ck.
>>>
>>>
>>>>
>>>> Simple question I'm not able to find answer for: what is the order
>>>>  of label pop operation and BA classification on penultimate router
>>>> ?
>>>>
>>>> I have a gut feeling that label is stripped first and then BA 
>>>> classification is done on a "naked" packet, f.e., ipprec-based in
>>>> case of IP packet, without taking (already stripped) EXP bits into
>>>>  account, but I can't find any documentation proving or disproving
>>>> it...
>>>
>>>
>>> _______________________________________________ juniper-nsp mailing
>>> list juniper-nsp at puck.nether.net 
>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>>
>>
>>
>> -- 
>> ------------------------------------------------------------------------
>> Christopher E. Brown   <chris.brown at acsalaska.net>   desk (907) 550-8393
>>                                                      cell (907) 632-8492
>> IP Engineer - ACS
>> ------------------------------------------------------------------------
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 


-- 
------------------------------------------------------------------------
Christopher E. Brown   <chris.brown at acsalaska.net>   desk (907) 550-8393
                                                     cell (907) 632-8492
IP Engineer - ACS
------------------------------------------------------------------------