The MPLS WG Archive

[Eric Rosen <erosen@cisco.com>]

> OK,  you  want  to come  as  close  to  PHP  as  possible via  some  extra
> gates... ;-)

Now you've  got it ;-)  I think Explicit  Null is almost  as good as  PHP at
violating  the   G.666  architecture,  and  that   pesky  "transparent  QoS"
requirement we  run into occasionally is  the only reason for  not doing PHP
all the time.

> As the recevier controls the labels it hands out, you could pick any value
> and optimize the hell out of it or for that matter make any implementation
> choice. You  don't need an  explicit reserved value except  for historical
> reasons. 

That's what Eric Gray was saying  7 years ago; but we're not revisiting that
decision,  just  fixing  an   inconsistency.   I  think  there's  a  certain
simplicity  in  having  a  reserved  value  for a  function  which  is  FEC-
independent, but ymmv.

> Yes, I'd like to reduce the number of ways of doing the same thing. 
> Presumably any good implementation not only handles the label, but also
> checks that the payload is a real v4 or v6 packet. 

Well, when  IP packets are  encapsulated in a  data link protocol,  the data
link  codepoint  distinguished IPv4  from  IPv6,  even  though all  that  is
strictly necessary is  a single "IP" codepoint and a look  at the IP version
number.   I  think the  IPv6  WG  chose to  require  a  different data  link
codepoint in order  to simplify the process of  dispatching received packets
to the proper network layer module.   We followed this line of thinking when
we chose  to have  two different Explicit  Null values.  With  two different
Explicit  Null  values,  when S  is  set  you  can  dispatch to  the  proper
forwarding table  without first  needing to inspect  the IP  version number.
It's not  obvious to me that  there is no  value in this, so  my inclination
would be to retain both values.