The MPLS WG Archive

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



[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: "David Allan" <dallan@nortelnetworks.com>
  • Date: Tue, 6 Jan 2004 11:00:08 -0500
  • Cc: mpls@UU.NET

Eric:

I suspect we are at a point where needing two explicit NULL labels are
redundant and the whole concept may have become redundant (except for
backwards compatibility).

1) If you want to offer a common label for all FECs to a peer for whatever
reason, it does not need to be a reserved label. Having multiple reserved
lables with forwarding semantics dependent on the 's' bit IMO can only
complicate life. 

2) We seem to be going down the road where the first nybble of the payload
is becoming significant and permits v4/v6 and other traffic to be
distinguished without requiring unique reserved labels to identify the
traffic. This would have always been true anyway if the explicit label was
simply "IP packet of any flavor follows" as IP does contain a version
number.

I would agree that if there is a mess already deployed clarification is
required, but we do seem to be defining multiple mechanisms for doing
precisely the same thing.

rgds
Dave

> -----Original Message-----
> From: Eric Rosen [mailto:erosen@cisco.com] 
> Sent: Tuesday, January 06, 2004 10:19 AM
> To: Shahram Davari
> Cc: mpls@UU.NET
> Subject: Re: Correction of Explicit Null specification in RFC 3032 
> 
> 
> 
> 1) Section 3 says: 
>    "With this restriction in place, one should not distribute, to a
>    particular label distribution peer, a binding of Explicit NULL to a
>    particular FEC, unless the following condition (call it "Condition
>    L") holds:  all MPLS packets received by that peer with an incoming
>    label corresponding to that FEC contain only a single label stack
>    entry.  If Explicit NULL is bound to the FEC, but 
> Condition L doesn't
>    hold, the peer is being requested to create illegal 
> packets.  None of
>    the MPLS specifications say what the peer is actually 
> supposed to do
>    in this case.  This situation is made more troublesome by the facts
>    that, in practice, Condition L rarely holds, and it is not possible
>    in general to determine whether it holds or not."
> 
> Shahram> If an egress router does not distribute the explicit 
> null label 
> Shahram> for a set of FEC  elements, when it is not the 
> egress  LER for 
> Shahram> at least one of those FEC elements, then condition L always 
> Shahram> holds.
> 
> Shahram> Am I missing something?
> 
> Consider a  packet of FEC  F traveling from  LSR A through  
> LSR B to  LSR C. Suppose that C distributed to B a label, L1, 
> for F, and B distributes to A a label, L2, for F.  
> 
> Condition L states that if B receives  an MPLS packet from A, 
> and if the top incoming label on that packet is L2, then the 
> packet has only a single label stack entry.
> 
> Whether  this condition holds  depends on  what has  happened 
> to  the packet before it gets to B. 
> 
> The problem arises  if the condition doesn't hold, but  L1 is 
> explicit null.
>