Subject: Re: [PWE3] Questions on NSP functions in RFC 4448

From: Maarten Vissers <[email-masked]>
Date: Sat, 20 Sep 2008 11:59:55 +0200

Howard,

> 4) VPLS appears to have abolished itself.
> The remaining job is to specify some interworking of PW identifiers
> and functions (e.g OAM) with the corresponding IEEE concepts. 

VPLS is just another name for a VLAN; specifically a VLAN of which the VLAN
Tag is replaced by a MPLS PW label Stack Entry header. The 802.1Q
vlan_identifier parameter value is carried inside the 20-bit Label field and
the priority and drop_eligible parameter values are carried in the 3-bit EXP
field. The MPLS PW label stack entry header performs the function of a VLAN
Tag. From the VPLS (i.e. Ethernet VLAN) layer this PW header could be viewed
as a MPLS-VLAN Tag (or M-Tag).

> 3) Someone should take full mesh/Split horizon to the IEEE and standardise
> it in .1Q as a loop avoidance technique.

Split horizon functionality has already been described in 802.1Q, annex B
for E-TREE type VLANs using two VLAN IDs. The full mesh application should
in my opinion be added to 802.1Q, as it is functionality operating in the
Ethernet VLAN layer. Such full mesh/split horizon architecture is more than
a loop avoidance technique. It is primarily a latency reduction technique in
network domains with p2p tunnels. It applies to any service VLAN over
point-to-point tunnels architectures; i.e. MPLS tunnel as well as VLAN
tunnels and PBB-TE tunnels.

MACinMAC is another method to support such full mesh/split horizon function;
each PBB-TE B/ESP-DA + B/ESP-SA value maps 1-to-1 with a tunnel. PBB-TE
could as such support similar VPLS functionality (which is available when
the BSI layer with its OAM is removed and the I-Tag is simply used as
demultiplex ID of the service VLAN). Main difference between MPLS VPLS and
PBB-TE VPLS is the number of bits in the labels; MPLS adds 2 x 20 bits and
PBB-TE adds 24 plus 108 bits:

MPLS VPLS		PBB-TE VPLS
-------------------------------------------------
20-bit PW label	24-bit I-SID
20-bit LSP label	108-bit <ESP-DA,ESP-SA,ESP-VID>

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Howard Green
Sent: 18 August 2008 06:04
To: Shane Amante; [email-masked]
Subject: Re: [PWE3] Questions on NSP functions in RFC 4448

Hi all
I understand the logic of Shane's argument. I suspect that it is true in
detail that the functionality of a bridge module in VPLS departs from the
specification in IEEE (and of course the current work in IEEE incorporates
much new functionality into the basic .1Q spec). I am unclear as to the full
scope of this argument, though. If the intention is to allow the IEEE to
evolve the standard without complex interworking with IETF, then surely the
logic is as follows:
1) a bridge module should be a fully compliant bridge as defined by 802.1Q
2) PW identities should be visible to this entity, so that the full range of
IETF VLAN and related functions (e.g. I-SID) should be possible.
If this is so, then the consequences would appear to be:
3) Someone should take full mesh/Split horizon to the IEEE and standardise
it in .1Q as a loop avoidance technique.
4) VPLS appears to have abolished itself.
The remaining job is to specify some interworking of PW identifiers and
functions (e.g OAM) with the corresponding IEEE concepts.
Is this what you want?
/Howard Green

________________________________

From: [email-masked] on behalf of Shane Amante
Sent: Mon 18/08/2008 04:35
To: [email-masked]
Subject: [PWE3] Questions on NSP functions in RFC 4448

Hi all,

This is a follow-up to several hallway discussions in Dublin regarding what
and, more importantly, how much we should specify as a function of the PWE3
NSP.  The question for everyone on the list is:
a)  Do people agree that the following are problem(s) in RFC 4448?
b)  What, if anything, should we do about it, both with respect to RFC
4448 and future Ethernet PW type/functions?

 From Section 1, "Introduction":
---snip---
    The Native Service Processing (NSP) function includes frame processing
that
    is required for the Ethernet frames that are forwarded to the PW
termination point.
    Such functions may include stripping, overwriting or adding VLAN tags,
physical
    port multiplexing and demultiplexing, PW-PW bridging, L2 encapsulation,
shaping,
    policing, etc. These functions are specific to the Ethernet technology,
and may not
    be required for the PW emulation service. The points to the left of A,
including
    the physical layer between the CE and PE, and any adaptation (NSP)
functions between
    it and the PW terminations, are outside of the scope of PWE3 and are not
defined here.
---snip---
Notice the last part of the sentence: "outside the scope of PWE3 and are not
defined here".

 From Section 3, "Applicability Statement":
---snip---
    - For an Ethernet VLAN PW, VLAN tag rewrite can be achieved by NSP at
the egress PE,
      which is outside the scope of this document.
---snip---
Notice, it says VLAN tag rewrite can be acheived by the /NSP/, however VLAN
tag rewrite is outside the scope of this document.

However, we now get down to Section 4.3, "Ethernet-Specific Interface
Parameter LDP Sub-TLV":
---snip--
    - 0x06 Requested VLAN ID Sub-TLV An Optional 16-bit value indicating the
      requested VLAN ID. This parameter MUST be used by a PE that is
incapable of
      rewriting the 802.1Q Ethernet VLAN tag on output. If the ingress PE
receives
                                                        
^^^^^^^^^^^^^^^^^^^^^^^^^^
      this request, it MUST rewrite the VLAN ID contained inside the VLAN
Tag at the
      
^
^
^
^
^
^
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      input to match the requested VLAN ID. If this is not possible, and the
VLAN ID
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      does not already match the configured ingress VLAN ID, the PW MUST not
be
      enabled. This parameter is applicable only to PW type 0x0004.
---snip---
Unfortunately, it seems that two prior sections of the RFC said that VLAN
tag rewrite was part of the NSP and outside the scope of this document, yet
this section clearly has a MUST support VLAN tag rewrite.

Of more concern is the following liaison received from IEEE, I believe by
CCAMP, during discussions around GELS:
https://datatracker.ietf.org/documents/LIAISON/file358.pdf
---snip---
Translation of 802.1Q S-VLAN tags (with 12 bit VIDs) is supported at S-
tagged service interfaces, as an option, by the IEEE Std 802.1ad Provider
Bridging amendment to IEEE Std 802.1Q. Translation of C-VLAN tags (again
with 12 bit-VIDs, but for use by 'customer'
bridges) is expressly prohibited by currently approved standards.
---snip---
However, RFC 4448 has a Normative Reference of 802.1Q, not 802.1ad.  
Should we spin a RFC 4448-bis to deprecate this functionality, update the
Normative reference to 802.1ad, or just point out that this particular
feature is non-conformant to IEEE 802.1Q-2005?

In addition, going back to the Introduction, it says that: "NSP function ...
may include stripping, overwriting or adding VLAN tags ... are outside of
the scope of PWE3 and are not defined here".  
However, in Section 4.4.1, "Raw Mode vs. Tagged Mode", it says the
following:
---snip---
    If an Ethernet PW is operating in raw mode, service-delimiting tags are
NEVER
    sent over the PW. If a service-delimiting tag is present when the frame
is received
    from the attachment circuit by the PE, it MUST be stripped (by the
NSP) from the
                                           
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    frame before the frame is sent to the PW.
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
---snip---
So, there are two concerns:
a)  Why if the Introduction says they are part of the NSP and outside the
scope, are they discussed here?
b)  Regardless of (a), it does say that it is part of the NSP, which leads
to the second point.

Also, just below that in Section 4.4.1:
---snip---
    If an Ethernet PW is operating in tagged mode, every frame sent on
    the PW MUST have a service-delimiting VLAN tag.  If the frame as
    received by the PE from the attachment circuit does not have a
    service-delimiting VLAN tag, the PE must prepend the frame with a
    dummy VLAN tag before sending the frame on the PW.  This is the
    default operating mode.  This is the only REQUIRED mode.
---snip---
With respect to tagged mode PW's, is it expected that if the AC does not
have a service-delimiting VLAN tag, the PE's NSP function is
*also* responsible for prepending the "dummy VLAN tag"?

Ultimately, instead of Section 4.4.1 of RFC 4448, why not just say that the
_NSP function_ may/must contain functions of adding, stripping VLAN tags in
accordance with Annex C of IEEE 802.1Q-2005, (maybe specifically Annex C.4:
"Procedures for tagging, untagging and relaying tagged frames")?  That
would, of course, lead to the question of why would we even need a raw vs.
tagged mode PW _type_ and, instead, rely on exchanging a NSP Capability
(sub-)TLV that said what the ingress and egress PE's NSP's are (capable of)
doing?

-shane
_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3

_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3

_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3

---

From: Maarten Vissers <[email-masked]>
Date: Sat, 20 Sep 2008 12:27:43 +0200

Yaakov,

A VLAN entity exists independent of a Tag. 
I.e. on the Untagged LAN there is one VLAN present, which can be uniquely
identied at a receiver (i.e. no need for a vlan (i.e. demux) identifier). On
the Priority Tagged LAN this one VLAN is "idnetified" by the null vlan
identifier (VID=0).

When such untagged or priority tagged VLAN continous on a LAN carrying more
than one VLAN, it is necessary to add a VLAN Tag. Such addition in one
direction and removal in another direction is already a form of VLAN ID
Translation. 802.1ad and 802.1ah have simply extended this translation
capability. E.g. a C-Tagged VLAN can be continued as a S-Tagged VLAN with
the C-VID translated into an S-VID value (PEB node), S-VID value of S-Tagged
VLANs can be translated in PB nodes, I-SID value of an I-Tagged "VLAN" can
be translated in BEB nodes.

When a VLAN enters a MPLS VPLS network, then this VLAN entity can continue
with a MPLS Tag (PW label stack entry header). The received untagged,
priority tagged, C-Tagged, S-Tagged or I-Tagged VLAN will the continue as a
M-Tagged VLAN and the VID/SID translates into a PW label.

As such one can conclude that the VLAN Tag format is optimized for the
tunnel signal it is carried in. In MPLS the optimal tag is the PW label and
in a similar ATM VPLS it would have been the ATM VCI (ATM VP would have been
the tunnel).

When the VLAN Tag in the incoming VLAN signal is preserved because e.g. a
bundle of client VLANs is treated as a single service, then this set of N
client VLAN signals is multiplexed in the UNI-N port into a server VLAN
signal (in case of VPLS application). This server VLAN signal starts
untagged and when multiplexed into the MPLS tunnel is tagged with a PW
label.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Yaakov Stein
Sent: 18 August 2008 07:35
To: Shane Amante; [email-masked]
Subject: Re: [PWE3] Questions on NSP functions in RFC 4448

Shane,

I view all wordings of the type "NSP functions are beyond the scope of this
document"
as political in nature.

The definition of NSPs is in RFC 3985, and there it is stated
  "The functional definition of any FWRD or NSP elements is
   outside the scope of PWE3."

The raison d'etre of this statement is to calm other standards bodies into
believing that PWE would not redefine native service behaviors defined
elsewhere.

This really would have been the case had PWE limited itself to pure
client/server interworking.
However, applications forced many of the PWE encap documents to include
various optimizations and  features that were not relevant in the context of
the original transport layer of the native service.

There are three ways to handle such NSPs :
1) declare that we will fully define them in the IETF (and bring down upon
ourselves the wrath of other SDOs)
2) liaise the appropriate SDO and ask them to define the required
functionality (and risk them not wanting to do so)
3) define them ourselves and immediately say that they are beyond our scope.

PWE took the third path, and it has worked very well until now.

The real question that has been brought up is why we need to swap VLAN tags
in Ethernet PWs at all.

When the Ethernet PW was being defined, the IEEE had not yet started work on
MAC-in-MAC, and so PWE was the first to confront the issues of
interconnecting previously disparate customer Ethernet networks.
Since these networks were originally completely separated, there had not
been any reason to align their use of VIDs, and thus when interconnecting it
would be useful to translate them, rather than enforcing renumbering of one
or the other.
As IEEE had not specifically stated that this was not allowed, it was
tacitly assumed at the time that it was allowed.

In the meantime the IEEE has encountered the same problem and has addressed
it in a somewhat different way. So we need to consider whether we want to
deprecate our mechanism and follow their lead, or continue on allowing VID
swapping (with or without stating so more clearly).

I would suggest starting by asking how widely the tagged mode is deployed.
Perhaps this is a nonissue at this point, and all we need is raw mode.

Y(J)S