Subject: Re: PHP negotiation

From: [email-masked]
Date: Wed, 24 Jan 2001 14:06:34 -0800

From:  James Huang@MITEL on 01/24/2001 02:06 PM PST
I found in sec 6 of RFC 3036 that PHP negotiation is an area of future study for
LDP.   Is it also an area of future study for RSVP-TE?  Before this negotiation
mechanism becomes available,  I presume we can only reply on manual
configuration on a per peer basis.

-- James Huang

Bora Akyol <[email-masked]> on 01/24/2001 12:33:03 PM

To:   James Huang/USA/Mitel@Mitel
cc:   Bora Akyol <[email-masked]>, [email-masked]

Subject:  Re: PHP negotiation

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

    James> Am I missing something here?

    James> -- James Huang

---

From: Serge Maskalik <[email-masked]>
Date: Mon, 29 Jan 2001 10:10:44 -0800

Believe it or not, this used to be a major inter-operability
     problem between two major vendors. One major vendor singalled 
     implicit null for all LSPs, _unless_ it was a single hop LSP
     in which case the explicit null was signalled to preserve the
     EXP field. The fact that the other vendor treated label 0 as 
     implicit null did not help either ;) 

      I think most folks would agree that php is a good default
     behavior. If folks want to do L-LSPs and not have to look at 
     DSCPs for the sake of keeping policies equal across the board
     or want to maintain the encapsulation to the last hop for other 
     reasons, global or per-LSP configuration options could exist. 
    
      I do not see a need for a negotiation mechanism. 

	- Serge