Re: [mpls] Question about 0x8848 Ethertype
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [mpls] Question about 0x8848 Ethertype
Hi Eric,
Do you know why such restriction for unicast exist? Why didn't the standard let unicast Ethernet carrying upstream-assigned label also use 0x8848?
What should a system that receives a Unicast Ethernet frame with Ethertype 0x8848 do? Should the packet be dropped?
Regards,
Shahram
-----Original Message-----
From: Shahram Davari
Sent: Thursday, October 22, 2009 12:28 PM
To: erosen at cisco.com
Cc: Nitin Bahadur; mpls at ietf.org
Subject: RE: [mpls] Question about 0x8848 Ethertype
Hi Eric,
Thanks for your clarifications.
Regards,
Shahram
-----Original Message-----
From: Eric Rosen [mailto:erosen at cisco.com]
Sent: Thursday, October 22, 2009 12:21 PM
To: Shahram Davari
Cc: Nitin Bahadur; mpls at ietf.org
Subject: Re: [mpls] Question about 0x8848 Ethertype
Nitin's interpretation matches the intention of the text.
If the ethertype of an ethernet frame is 8848:
- The top label is to be looked up an interface-specific label space that is
populated by the context labels in use on the LAN. Each such label must
uniquely correspond to an LSR on the LAN.
- As a result of making this lookup, you identify a second label space, one
that is specific to the LSR that transmitted the frame. This label space
is populated by the labels that have been upstream-assigned by that LSR.
If the ethertype is 8847, the top label is an ordinary downstream-assigned
label, looked up in a label space populated by the downstream-assigned
labels of the LSR that receives the frame.
The above mentions three different label spaces; all label uniqueness
requirements are relative to a particular label space.
> How will a node receiving a unicast packet can identify whether the top
> label is upstream assigned or downstream assigned?
Per the standards, there is no way of using upstream-assigned labels in
unicast ethernet frames.
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.