Subject: penultimate hop poping

From: Srinivas Reddy <[email-masked]>
Date: Tue, 24 Jul 2001 20:49:28 +0530

Dear all,

	as per rfc3031 under section 3.16. 
1)Initial LDP negotiations MUST allow each LSR to determine whether its 
neighbouring LSRS are capable of poping the label stack.

how can we(egress) determine that our neighbour has the capability of poping 
the stack.

2)A LSR MUST NOT Request a label distribution peer to pop the label stack 
unless it is capable of doing so.
	is it possible that a LSR will not support the label stack poping.

and under section 4.1.5 (rfc3031)
LSR Rd distributes a binding between Implicit NULL and an address prefix X to 
LSR Ru if and only if :
	1. the rules os -----------
	2.Rd knows that Ru Can Support Implicit NULL label(i.e. that it can pop the 
label stack) ...
how can Rd (egress) knows that  Ru has support of poping of stack. or is it a 
MUST that each LSR should support penultimate hop poing.

please calrify ,me about this.
thanks in adv.
regards
lonka

---

From: Eric Gray <[email-masked]>
Date: Tue, 24 Jul 2001 11:15:54 -0400

Lonka,

    In general, PPP and Ethernet MPLS implementations SHOULD be able
to support PHP and ATM/FR implementations MAY be able to support
PHP (using a 'default' VC corresponding to forwarding to the nexthop
routing instance).  Currently the only indication that an LSR MAY get
that a peer does not support PHP is if that LSR consistently rejects (by
sending a Label Release message, for example) any attempt to distribute
an IMPLICIT NULL label.

    Clearly there will be some interoperation friction between an LSR that
does not support PHP and a neighboring LSR that is learning impaired.
The scenario in which the downstream keeps giving IMPLICIT NULL is
avoided if the upstream peer asks for a new label, and waits for a Label
Mapping message (again, for example), before releasing the IMPLICIT
NULL label it has received.

    Of course, some implementations may so far depend on PHP that they
will give the IMPLICIT NULL label again in this case - even though this
is a clear violation of the specification.

--
Eric Gray

---

From: "chetan kumar s" <[email-masked]>
Date: Wed, 25 Jul 2001 09:00:12 +0530 (IST)

Hi,

> is a clear violation of the specification.

	'violation of specification' how ?? I do not see any such
statements in any of the RFC, have I missed something ??

And beyond that if I look at the RFC 3031 section 3.16 Page 19, it states

   Initial label distribution protocol negotiations MUST allow each LSR
   to determine whether its neighboring LSRS are capable of popping the
   label stack.

So, does the RFC 3036 missing something in the init message ??

Thanks
Chetan S

---

From: Bob Thomas <[email-masked]>
Date: Wed, 25 Jul 2001 06:33:17 -0400

> So, does the RFC 3036 missing something in the init message ??

Please see the first bullet in Section 6 of RFC3036:

      -  Section 2.16 of the MPLS architecture [RFC3031] requires that
         the initial label distribution protocol negotiation between
         peer LSRs enable each LSR to determine whether its peer is
         capable of popping the label stack.  This version of LDP
         assumes that LSRs support label popping for all link types
         except ATM and Frame Relay.  A future version may specify means
         to make this determination part of the session initiation
         negotiation.

         (The reference to Section 2.16 should be a reference to
          section 3.16).

Bob

---

From: Eric Gray <[email-masked]>
Date: Wed, 25 Jul 2001 11:25:37 -0400

Chetan S,

    Yes, violation of the specification.  Regardless of the distribution mode
that an LSR is using (DU/DoD), any LSR may request additional labels
for a particular FEC.  This is intended primarily to support LSP setup when
the upstream LSR does not want (or is not able) to merge all packets onto
a single downstream LSP.  Labels returned for such requests MUST NOT
be the same as those distributed (for this, or any other, FEC) previously
(unless also previously released by the upstream LSR).

    This is required because simply issuing the same label forces upstream
LSR(s) to merge packets.  The procedures in the appendix of RFC 3036
specify this behavior.

--
Eric Gray