Subject: Re: [PWE3] [mpls] clarification on RFC 4447: Pseudowire Setup and Maintenance Using the Label Dist

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 1 Dec 2008 09:33:43 +0200

Dinesh,
RFC 4447 has been developed by the PWE3 WG and not by the MPLS WG. Hence I think you should re-send it to the PWE3 WG.

I also think that the questions you've raised are closely related to an earlier email by Shane Amante on the PWE3 WG mailing list (attached for our convenience0.

Regards,
    Sasha

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dinesh
Sent: Sunday, November 30, 2008 5:48 AM
To: [email-masked]
Subject: [mpls] clarification on RFC 4447: Pseudowire Setup and Maintenance Using the Label Dist

Hi,

This RFC does not address the case were one end point of attachment circuit is a qinq vlan and remote
attachment end point is a dot1q single tag vlan. Currently ether type vlan is used and this does not help the
PEs to  do proper insert/modify of the pw data  as they do not actually know if the received packet has single tag or double tag.

I want the PE to send out L2 frame with dot1p bits so that i can provide COS at remote end.
 if we use  vc-type ether, the  vlan information is not sent on the wire. and if vlan info is sent using vc-type  vlan, then
there is confusion if received data is a single tagged or double tagged. Please  clarify this.

Regards
dinesh

Subject: [PWE3] Questions on NSP functions in RFC 4448
From: Shane Amante <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Mon, 18 Aug 2008 06:35:10 +0300
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>

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