The MPLS WG Archive

[Serge Maskalik <serge@ivmg.net>]

      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 

Thus spake James_Huang@Mitel.COM (James_Huang@Mitel.COM):

> 
> 
> 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 <akyol@pluris.com> on 01/24/2001 12:33:03 PM
> 
> To:   James Huang/USA/Mitel@Mitel
> cc:   Bora Akyol <akyol@pluris.com>, mpls@UU.NET
> 
> 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 <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
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>