| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
[KN] I disagree that no standard supports this behavior. I believe, while not explicitly stated or exemplified, 802.1Q supports it, therefore it is not proprietary. It is also supported so widely in the industry and with no interoperability issues, that it cannot be called proprietary.  If no standard explicitly stated or exemplified the triple-tagging behavior and it is already widely supported by the industry with no interoperability issues, then there is no need for 1904.2 to explicitly state or exemplify it ether.   -Glen  From: Kevin Noll [mailto:kevin.noll@xxxxxxxxxxxx]  My reply seems to have not gone through. Resendingâ?¦  Inlineâ?¦  -- Kevin A. Noll Sr. Director, Systems Architecture Tibit Communications  From: Glen Kramer <glen.kramer@xxxxxxxxxxxx>  Kevin, please see below.  -Glen  From: Kevin Noll [mailto:kevin.noll@xxxxxxxxxxxx]  Glen, Marek,  I regularly see the need to match on 3 VLAN tags. [GK: ] Does that mean that you already do that? Can you describe the use case? [KN] Yes, we do this. We have customers that want to tag a frame based on 3 factors: service type (voice/video/data), per-ONU and per-OLT. So, S=OLT, C1=ONU, C2=Service. This might not be the way the standards were intended to be used, but it is a very common practice in the telco community and is widely supported in access network equipment today. Relating to our use of VLC, we sometimes need to match on the tags and Ethertype (or even deeper in the frame) to identify a special protocol that we want to send over VLC (e.g. DHCP, EAPOL, etc.)  I will not agree with you on the specific point of supporting 3 or more tags being proprietary. [GK: ] If you do that already, and no standard defines this behavior, how is this not proprietary? [KN] I disagree that no standard supports this behavior. I believe, while not explicitly stated or exemplified, 802.1Q supports it, therefore it is not proprietary. It is also supported so widely in the industry and with no interoperability issues, that it cannot be called proprietary.  I will agree with your overall assessment here.  Alternatively, we could remove VLAN support from 1904.2 and allow it to be handled entirely in 802.1Q which is what was suggested in our discussions in April. [GK: ] I thought you insisted earlier that VLCPDUs carrying OMCI or OAM may need to be tagged. But OMCI and OAM payloads never reach 802.1Q domain, so their tagging cannot be handled by 802.1Q. [KN] Context and semantics are important here. An OMCI frame, of course, will never have VLAN tags because itâ??s not an Ethernet frame. In practice, yes, OAM ends up with tags in many scenarios and this was described during our discussions in April.  That approach was rejected because some parties in the group could not conceive of a way to specify VLC (UMT at the time) working within the 802.1Q framework. [GK: ] That approach was rejected because it wanted the 802.1Q functionality to be moved to VLC sublayer, which would be a major layering violation. However, opening that door would allow 1904.2 to be silent altogether on VLANs, allowing implementers to be free to support as many VLANs as they want within the framework of widely available 802.1Q implementations. [KN] I disagree with you on this. Moving 802.1Q functionality into VLC was not rejected and is, in fact, exactly what we have in the current text. VLC can add and remove tags, which is a function of the 802.1Q EISS. The alternative that was proposed in April and May of this year (and even earlier) was to put VLC above the ISS where it could leverage the interfaces and capabilities of the 802.1Q architecture.  -- Kevin A. Noll  From: Glen Kramer <glen.kramer@xxxxxxxxxxxx>  Kevin,  There is a huge difference between (1) a standard explicitly prohibiting feature X, (2) being silent on feature X, or (3) explicitly requiring feature X.  If the feature X is explicitly prohibited, and vendor implements it, that implementation is non-compliant. Standards rarely prohibit anything. It is only done what that feature X breaks something if implemented, or is a safety/security issue.  If a standard is silent on feature X, any vendor may decide to implement it in a proprietary way. Such implementation still remains standards-compliant, even though it goes beyond the standard requirements.  And of course, if a feature X is required, any implementation must have it, and if it doesnâ??t, it is considered non-compliant.  So, here is my position on triple or quadruple tagging: with all existing standards being silent on it, any vendor is free to go ahead and support it in their implementations. Such proprietary support would involve defining proprietary field codes that point to 3rd and 4th tags (or 5th and 6th, if someone wants. The sky is the limit here.)  But explicitly adding this behavior to 1904.2 will require every vendor to support this, whether they need it or not.  -Glen  From: mxhajduczenia@xxxxxxxxx [mailto:mxhajduczenia@xxxxxxxxx]  It is all over the place in 802.1Q, Kevin â?? two tags, not 3, 4, or many more  From: stds-1904-2-tf@xxxxxxxxxxxxxxxxx <stds-1904-2-tf@xxxxxxxxxxxxxxxxx> On Behalf Of Kevin Noll  As I understand 802.1Q, the framework in 802.1Q allows an arbitrary number of tags to be in a frame.  Can you point me to specific text in 802.1Q that prohibits or limits support to 2 tags?  -- Kevin A. Noll  From: Glen Kramer <glen.kramer@xxxxxxxxxxxx>  Kevin,  This was not an arbitrary decision. Both 802.1Q and 1904.1 define frame formats and operations on double-tagged frames. There is no specification defining the format or processing operations for triple- or quadruple-tagged frames.  So, if a user classifies and manipulates the 3rd and 4th tag, what existing standard defines that processing? In 802.1, the ISS interface shows that frames can have just two tags S-TAG and C-TAG (I am not taking about I-tagged frames, which are very different).   -Glen  From: Kevin Noll [mailto:kevin.noll@xxxxxxxxxxxx]  Currently the draft allows classification and manipulation on up to 2 VLAN tags. Recalling the discussion that settled on 2 tags, this was a somewhat arbitrary decision that was made to allow the discussion to move on.  It is common to have more than 2 tags.  How would a user classify on or manipulate a 3rd or 4th tag, or an arbitrary tag depth?  --kan-- -- Kevin A. Noll  To unsubscribe from the STDS-1904-2-TF list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-1904-2-TF&A=1 To unsubscribe from the STDS-1904-2-TF list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-1904-2-TF&A=1 To unsubscribe from the STDS-1904-2-TF list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-1904-2-TF&A=1 |