Kevin,  We are going in circles without bringing any new information. All of these points were already addressed in our earlier email discussions. No one is arguing that you may have a special use case that you solved using triple tagging. I even take your word that there are multiple vendors implemented triple tagging in interoperable way.  This is not the argument. The argument is this: if 802.1Q is silent on triple tagging and multiple vendors already interoperate using triple tags anyway, why should 1904.2 take any different approach? You seem to suggest that not requiring support for triple or quadruple tagging will doom the 1904.2 standard to fail, and that to avoid that fate, we should make the 1904.2 standard the only standard in existence explicitly requiring support for triple or quadruple tagging. That means that any vendor that doesnâ??t face the same use case or that solved this use case differently, now will have to support triple tagging just to be able to claim compliance to 1904.2.  My position is that 1904.2 should be silent on triple tagging , just like any other standard.    Hereâ??s my 2 cents worthâ?¦  There are networks in existence that support 3 and more VLAN tags for 802.1Q operations. We can argue whether those systems are or are not compliant with 802.1Q, but thatâ??s not really the point. They exist and they are supported by equipment available from multiple vendors and they all interoperate under the 802.1Q framework.  I previously described a real-world problem that would ask 1904.2 to also support 3 or more tags. (Included in the email thread below). If TF 1904.2 does not address this then it will negatively affect the ability to implement 1904.2 and interoperate among 1904.2 implementations.  --kan-- -- Kevin A. Noll   That's just a wiki generalization. Not always people writing there articles are really conscious of the little language implications.  Hi Marek, You mean in 802.1ad document or in wiki link? In the wiki link for instance I see this â??In frames having more than one tag, the tags are numbered 1 to N, and appear sequentially and contiguously in the frame from Ethernet header to payload. In this case the innermost tag is the C-TAG and all other tags are S-TAGs.â??
Sent from Yahoo Mail for iPhone On Thursday, August 27, 2020, 7:38 PM, mxhajduczenia@xxxxxxxxx wrote: Pradeep,  I do not see any references in there that would imply triple or more tags are permitted.  Marek   I think IEEE 802.1ad covers the topic of processing 2 or more tags. I don't have access to that standard for me to validate but the wikipedia page has some references to more than 2 tags. [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.     My reply seems to have not gone through. Resendingâ?¦ Inlineâ?¦  -- Kevin A. Noll Sr. Director, Systems Architecture Tibit Communications kevin.noll@xxxxxxxxxxxx  Kevin, please see below.    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,  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.    It is all over the place in 802.1Q, Kevin â?? two tags, not 3, 4, or many more   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,  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).     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
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
|