Subject: RE: bug in draft-ietf-mpls-label-encaps-08

From: Eric Gray <[email-masked]>
Date: Mon, 16 Oct 2000 10:45:21 -0700

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:[email-masked]]
> Sent: Monday, October 16, 2000 10:23 AM
> To: [email-masked]
> Cc: Puneet Agarwal; [email-masked]'; [email-masked]'; 
> [email-masked]'
> 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."
>

---

From: Bora Akyol <[email-masked]>
Date: Mon, 16 Oct 2000 11:06:46 -0700

Yes

But this is a bit too brute for my taste. The fact is that people are using
Implicit and Explicit NULL labels in the manner originally described and it
would be nice to acknowledge that.

Bora