The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2002-Sep> msg00069



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

Clarification on Handling a specific event in LDP

  • From: "Gray, Eric" <egray@celoxnetworks.com>
  • Date: Wed, 18 Sep 2002 14:01:22 -0400
  • Cc: "MPLS (E-mail)" <mpls@UU.NET>

Eric,

	Please see below...

Eric W. Gray
Systems Architect
Celox Networks, Inc.
egray@celoxnetworks.com
508 305 7214


> ---

[snip]
Jack> (5)  Advertise using a non-NULL label, without withdrawing the
Jack>      NULL label.  The upstream peer *might* realize what you are
Jack>      trying to do...
> 
> This will probably upset the peer.

That depends on what you mean by "upset".  Assuming we do
not have to worry about the defective implementation case,
the worst that could happen is for the peer to decide that 
the session is compromised and reset it.  That would be BAD,
but it would also be very unusual.

Any reasonably robust implementation would simply release
the unsolicited label mapping if it does not know what else
to do with it.

> 
> Once you withdraw a label, you have to wait for the upstream 
> peer to request a new label.  The upstream peer could 
> probably get away  with requesting a new label immediately,  
> not percolating the withdraw upstream unless the new  
> request is refused.  Or the upstream peer could just percolate
> the withdraws upstream, in which case the ingress would have to  
> reinitiate a request.  I don't really see what else could be 
> done without causing interoperability problems.

This case does not have the LSR withdraw the label.  Even
if the LSR does withdraw the label after advertising a new
one (assuming it does not get a release for either of the
outstanding Label Mappings), by that time, the upstream 
LSR should have a replacement label and will not need to
either request one or withdraw corresponding labels from
upstream LSR peers.