The implict null specification is not specfic to ipv4.
The corrected descriptions:
-a label value of 0 stands for the ipv4 explicit null label
-a label value of 2 stands for the ipv6 explicit null label
-a label value of 3 stands for the implicit null label
-- <ruhann> CCIE (R&S) blog.ru.co.za On Tue, Feb 9, 2010 at 2:38 PM, Roger Pfaeffli <rpf23543_at_gmail.com> wrote: > Hi group, > > I have a question regarding the implicit and explicit label values. We all > know that > > -a label value of 0 stands for the ipv4 explicit null label > -a label value of 2 stands for the ipv6 explicit null label > -a label value of 3 stands for the ipv4 implicit null label > > O.k., fine until now. > > My question is why is there no label value for the ipv6 implicit null > label? > Or with other words, why is there a special label value for the ipv6 > explicit null label? > > My assumption is that since with the explicit null label, the egress LSR > (PE) receives a labeled packet and if he already knows while "checking the > label" whether it is an ipv4 or an ipv6 packet after popping the label, he > already knows in which table he has to do the lookup, the operation goes > much quicker instead of just popping the label and then checking if it is > ipv4 or ipv6. A bit similar like the Ethertype in the Ethernet Frame. > > On the other way, with the implicit null label, due to the PHP at the > egress > LSR (PE) gets the packet unlabeled and can already do the decision between > ipv4 / ipv6. So no need to create a special label value for ipv6 implicit > null label. > > > Can someone bring light into this???? > > > Roger #23543 > > BTW: In the example above, I was thinking about mpls labeled ip traffic, > not > vpn traffic since this would require the additional vpn label. > > > Blogs and organic groups at http://www.ccie.net > > _______________________________________________________________________ > Subscription information may be found at: > http://www.groupstudy.com/list/CCIELab.html Blogs and organic groups at http://www.ccie.netReceived on Tue Feb 09 2010 - 16:45:44 ART
This archive was generated by hypermail 2.2.0 : Mon Mar 01 2010 - 06:28:35 ART