The MPLS WG Archive

[Eric Gray <EGray@zaffire.com>]

Bora,

	There is always a brute force negotiation
mechanism: the upstream LSR that does not support
PHP can simply refuse to do so - perhaps sending
an appropriate error message.  The procedure for
this is spelled out in section 4.1.1.2 of RSVP-TE
-

"4.1.1.2. Upstream

   A node uses the label carried in the LABEL object as the outgoing
   label associated with the sender.  The router allocates a new label
   and binds it to the incoming interface of this session/sender.  This
   is the same interface that the router uses to forward Resv messages
   to the previous hops.

   Several circumstance can lead to an unacceptable label.
...
     2. The implicit null label was assigned, but the node is not
        capable of doing a penultimate pop for the associated L3PID
...
   In any of these events the node send a ResvErr message with an error
   code of 'routing problem' and an error value of 'unacceptable label
   value'."

--
Eric Gray

> -----Original Message-----
> From: Bora Akyol [mailto:akyol@pluris.com]
> Sent: Monday, October 16, 2000 10:23 AM
> To: erosen@cisco.com
> Cc: Puneet Agarwal; 'mpls@uu.net'; 'tappan@cisco.com'; 
> 'yakov@cisco.com'
> Subject: Re: bug in draft-ietf-mpls-label-encaps-08
> 
> 
> Eric
> 
> Unfortunately, this is the way we observe Implicit Null being 
> used in the field.
> Also, I have not seen a negotiation mechanism for RSVP-TE for 
> PHP support.
> 
> I also think that the arch spec may contradict the label encaps spec.
> 
> Bora
> 
> 
> Eric Rosen wrote:
> 
> > Puneet> My understanding was  that when a LSR got a label  
> 3 from the egress
> > Puneet> LSR during signaling, if the LSR was  able to do a 
> pop then it would
> > Puneet> perform  a penultimate  hop pop  otherwise  it 
> would  just swap  the
> > Puneet> incoming label  with label 0  and then the  egress 
> LSR would  do the
> > Puneet> actual pop.
> >
> > I don't think  this understanding accords with section  
> 4.1.5 of draft-ietf-
> > mpls-arch-07.txt:
> >
> >         "... a  binding of Implicit NULL may  be distributed only
> >         to LSRs which can support that function."
>