Subject: Re: PHP negotiation

From: [email-masked]
Date: Wed, 24 Jan 2001 12:03:19 -0800

From:  James Huang@MITEL on 01/24/2001 12:03 PM PST
Hi Bora:
     Maybe I did not express my concern clear enough.  As you said, the LSP
setup will fail when the egress LSR assigns an Implicit NULL label to the
penultimate hop, if the penultinate hop does not support PHP.   So there should
be some negotiation mechanism in LDP or RSVP/TE such that an egress router will
know not to assign an Implicit NULL label to a penultimate hop that does not
support PHP.   But I can not find such mechanism in the documents.

-- James Huang

Bora Akyol <[email-masked]> on 01/23/2001 08:24:45 PM

To:   James Huang/USA/Mitel@Mitel
cc:   [email-masked]

Subject:  PHP negotiation

You should also read the label encapsulation RFC. What happens
is that the egress LSR assigns an (...) NULL label (I think it
should be Implicit Null) to the penultimate hop, if penultimate
hop does not support this, then LSP setup should fail.

There was a LOOONG discussion on this sometime last year.

Some people think this stuff is really clear. I think that it is
in about three different RFCs, and someone needs to write a BCP
that explains common usage and tricks that network operators
that use MPLS should use.

BTW, this question comes up about once a month on the list,
maybe we should have an MPLS FAQ.

Bora

>>>>> "James" == James Huang <[email-masked]> 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
    James> LDP/CR-LDP or RSVP-TE to accomplish this PHP
    James> negotiation.

    James>      Am I missing something here?

    James> -- James Huang

---

From: Bora Akyol <[email-masked]>
Date: Wed, 24 Jan 2001 12:33:03 -0800

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 <[email-masked]> 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 <[email-masked]> on 01/23/2001 08:24:45
    James> PM

    James> To: James Huang/USA/Mitel@Mitel cc: [email-masked]

    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> However, I can not find any mechanism in LDP/CR-LDP
    James> or RSVP-TE to accomplish this PHP negotiation.

    James> -- James Huang

---

From: Eric Gray <[email-masked]>
Date: Wed, 24 Jan 2001 17:52:14 -0500

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

---

From: Bora Akyol <[email-masked]>
Date: Wed, 24 Jan 2001 13:55:52 -0800

One can presume to enable or disable functionality related to
PHP using CLI or MIB commands as well as centralized
configuration distribution. I know of at least one ISP that uses
a centralized configuration engine to control all of their
routers.

Bora

>>>>> "Eric" == Eric Gray <[email-masked]> writes:

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

    Eric> -- Eric Gray

    Eric> 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> Bora
    James> -- James Huang