Subject: PHP

From: "Sandeep B" <[email-masked]>
Date: Wed, 17 Apr 2002 19:34:37 +0000

Francis,

If all vendors support MPLS as it was intended, only egress and penultimate 
hop should be checking for L3PID. No intermediate LSR should be even 
noticing what is inside the label.

Few of the biggest names in industry do check on L3PID at every LSR and 
reject if its not IP. Due to this all other implementations of MPLS based 
VPNs signal L3PID as 0x800 (IP) even when it is suppose to be 0x8847.

my 2 cents.

-Sandeep

Hello,

I have a question on RFC 3209 (RSVP-TE spec.). Section 4.2.4 (handling of 
LABEL REQUEST object) states the following:

>If the receiver cannot support the protocol L3PID, it SHOULD send a   
>PathErr with the error code "Routing problem" and the error value
 >  "Unsupported L3PID."  This causes the RSVP session to fail.

Does this mean that a **transit** LSR should reject the LSP setup, even 
though it never sees the data beneath the mpls label?

Thanks for any help you can provide,

        Francis.

_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com

---

From: David Charlap <[email-masked]>
Date: Wed, 17 Apr 2002 15:53:19 -0400

Sandeep B wrote:
> 
> If all vendors support MPLS as it was intended, only egress and
> penultimate hop should be checking for L3PID. No intermediate LSR
> should be even noticing what is inside the label.

Absolutely correct.  A transit router shouldn't care at all what's
inside the packets.  Only nodes that pop labels (and really only those
that pop the last label off the stack) need to know about the L3PID,
since they are the only nodes who will be responsible for forming an
appropriate layer-2 header.

> Few of the biggest names in industry do check on L3PID at every
> LSR and reject if its not IP.  Due to this all other
> implementations of MPLS based VPNs signal L3PID as 0x800 (IP) even
> when it is suppose to be 0x8847.

Your conclusion does not follow from the premise.  Even if nobody has a
transit router validating L3PID, it is still illegal to use a PPP
protcol ID in that field.  RFC 3209 explicitly defines this field as an
Ethernet type:

	4.2.1. Label Request without Label Range

		...

	L3PID

	   an identifier of the layer 3 protocol using this path.
	   Standard Ethertype values are used.

It doesn't matter if the ingress/egress nodes are using PPP
encapsulation.  If the L3 content is IP, the the L3PID field should be
0x0800.

It is the responsibility of the ingress and egress nodes to be able to
map between the interface's local encapsulation (PPP, or whatever) and
standard Ethertype values.

To continue this thread just a bit further, it is illogical to have an
ingress node use whatever ID its local interface might be using.  There
is no guarantee that an arbitrary layer-2 will use a 16-bit value for
its layer-3 protocol IDs.

There is also no guarantee that the egress node will use the same
encapsulation as the ingress node.  What if the egress node is
different?  How will it know that the L3PID it was given is supposed to
be PPP instead of Ethernet or something else?  If it blindly uses the
value as-is, then it will be impossible to use ingress/egress interfaces
that have different layer-2 technologies, which violates several basic
rules of router operation.

-- David

---

From: David Charlap <[email-masked]>
Date: Wed, 17 Apr 2002 16:18:22 -0400

David Charlap wrote:
> inside the packets.  Only nodes that pop labels (and really only
> those that pop the last label off the stack) need to know about the
> L3PID, since they are the only nodes who will be responsible for
> forming an appropriate layer-2 header.
> 
>> LSR and reject if its not IP.

I should just add that this isn't necessarily unreasonable.

Due to the nature of RSVP, a router does not know whether or not it will
have to pop a label during Path processing.  Yes, it will know if it is
the egress node, but if it's not, it can't know in advance if it will be
given a label to swap to or a request to pop the label (implicit NULL).

Also note that when the route table changes, a pure transit router may
become a penultimate-hop router.

In other words, a router can't know for certain that it will never be
asked to pop a label stack.  The result is that it may make sense to
validate the L3PID at the time of Path processing.

It could wait for the Resv message, and only validate L3PID if it has to
do a pop, but that may not be efficient for all implementations.  It
would also increase the overhead of cleanup after generating the error.

But none of this has anythng to do with the fact that RSVP's L3PID must
be an Ethernet protcol ID.

-- David