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

From: Shane Amante <[email-masked]>
Date: Sun, 17 Aug 2008 21:35:10 -0600

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

---

From: "Howard Green" <[email-masked]>
Date: Sun, 17 Aug 2008 23:03:37 -0500

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,

---snip---

      
^
^
^
^
^
^

---snip---
use by 'customer'

---snip---

-shane

---

From: Yaakov Stein <[email-masked]>
Date: Mon, 18 Aug 2008 08:34:44 +0300

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

---

From: Shane Amante <[email-masked]>
Date: Mon, 18 Aug 2008 08:20:32 -0600

Hi Howard,

The intent of my e-mail was not to open up a discussion on the 
architecture of a bridge module, specific to VPLS, on the PWE3 WG 
mailing list.  If you would like to discuss that, I would recommend that 
you take that discussion to the L2VPN WG mailing list.

The intent of my e-mail was to: a) understand the history of the PWE3 
NSP functions, specifically related to RFC 4448, which Yaakov has 
provided good insight into; and, b) given hindsight available to us 
today, reaffirm if we are still OK with previous decisions, particularly 
as precedent for future design decisions, or if we wish to improve on 
our current specification of the PWE3 NSP to better accommodate both 
current and future Ethernet data-plane formats.

-shane