The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2001-Jan> msg00278



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

PHP negotiation

  • From: Eric Gray <eric.gray@sandburst.com>
  • Date: Wed, 24 Jan 2001 17:52:14 -0500
  • Cc: James_Huang@Mitel.COM, mpls@UU.NET

Bora,

    This explanation presupposes the existence of a standard way for
the knowledgeable network operator to "configure their equipment"
to compensate for a mismatch in equipment models relative to PHP.
To my knowledge, the only such "standard" way at present is for the
knowledgeable network operator to buy compatible equipment.  Did
I miss something?

--
Eric Gray

You wrote:

> There is no such mechanism. The assumption is that the network
> operator knows how to configure their equipment and they know
> their network.
>
> Bora
>
> >>>>> "James" == James Huang <James_Huang@Mitel.COM> writes:
>
>     James> From: James Huang@MITEL on 01/24/2001 12:03 PM PST Hi
>     James> Bora: Maybe I did not express my concern clear
>     James> enough.  As you said, the LSP setup will fail when
>     James> the egress LSR assigns an Implicit NULL label to the
>     James> penultimate hop, if the penultinate hop does not
>     James> support PHP.  So there should be some negotiation
>     James> mechanism in LDP or RSVP/TE such that an egress
>     James> router will know not to assign an Implicit NULL label
>     James> to a penultimate hop that does not support PHP.  But
>     James> I can not find such mechanism in the documents.
>
>     James> -- James Huang
>
>     James> Bora Akyol <akyol@pluris.com> on 01/23/2001 08:24:45
>     James> PM
>
>     James> To: James Huang/USA/Mitel@Mitel cc: mpls@UU.NET
>
>     James> Subject: PHP negotiation
>
>     James> You should also read the label encapsulation
>     James> RFC. What happens is that the egress LSR assigns an
>     James> (...) NULL label (I think it should be Implicit Null)
>     James> to the penultimate hop, if penultimate hop does not
>     James> support this, then LSP setup should fail.
>
>     James> There was a LOOONG discussion on this sometime last
>     James> year.
>
>     James> Some people think this stuff is really clear. I think
>     James> that it is in about three different RFCs, and someone
>     James> needs to write a BCP that explains common usage and
>     James> tricks that network operators that use MPLS should
>     James> use.
>
>     James> BTW, this question comes up about once a month on the
>     James> list, maybe we should have an MPLS FAQ.
>
>     James> Bora
>
> >>>>> "James" == James Huang <James_Huang@Mitel.COM> writes:
>
>     James> Hi all, The following paragraph is from Section
>     James> 3.16. (Penultimate Hop Popping) of RFC3031.
>
>     James> "Initial label distribution protocol negotiations
>     James> MUST allow each LSR to determine whether its
>     James> neighboring LSRS are capable of popping the label
>     James> stack.  A LSR MUST NOT request a label distribution
>     James> peer to pop the label stack unless it is capable of
>     James> doing so."
>
>     James> However, I can not find any mechanism in LDP/CR-LDP
>     James> or RSVP-TE to accomplish this PHP negotiation.
>
>     James> Am I missing something here?
>
>     James> -- James Huang