The MPLS WG Archive

[Bora Akyol <akyol@pluris.com>]

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


Eric Gray wrote:

> 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."
> >