The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Correction of Explicit Null specification in RFC 3032
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. >
|
|