The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2004-Jan> msg00004



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Correction of Explicit Null specification in RFC 3032

  • From: Eric Rosen <erosen@cisco.com>
  • Date: Tue, 06 Jan 2004 11:27:16 -0500
  • cc: Shahram Davari <Shahram_Davari@pmc-sierra.com>, mpls@UU.NET
  • User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3(Unebigoryōmae) APEL/10.3 Emacs/21.3(sparc-sun-solaris2.8) MULE/5.0 (SAKAKI)


David> I would agree that if there is a mess already deployed, clarification
David> is required

Yes, there is a mess already deployed. 

David> If  you want  to offer  a common  label for  all FECs  to a  peer for
David> whatever reason, it does not need to be a reserved label. 

Using a reserved label  eliminates the need to look up the  label in a large
table; instead  you can spend  your time looking  up the label  (or address)
beneath it. 

David> Having multiple  reserved labels with  forwarding semantics dependent
David> on the 's' bit ...

Whenever a label invokes the "pop the stack" label operation, the forwarding
semantics are dependent on the s bit. 

David> ... can only complicate life

Generally  the hardware guys  can figure  out how  to do  a comparison  to a
constant without introducing undue complexity ;-)

David> We  seem to be  going down  the road  where the  first nybble  of the
David> payload is  becoming significant and permits v4/v6  and other traffic
David> to  be  distinguished without  requiring  unique  reserved labels  to
David> identify the traffic. 

If you're  suggesting that we only need  one value of "IP  explicit null", I
think that is worth considering.