Glen,
I agree that this thread has gone long enough. In fact, it has gone so long that the original question has been lost in the attempt to respond to all the intervening confusion.
As I expressed in this email thread, I am not trying to change what is written in D0.6. I am trying to ensure that we don’t run into roadblocks during balloting. I have tried here to explain why there is a
potential for concern. Since you are the only one that has engaged in that conversation, and you believe that there is no cause for concern, then I will assume that the group feels the same and it’s time to move on.
--kan--
--
Kevin A. Noll
Sr. Director, Systems Architecture
Tibit Communications
kevin.noll@xxxxxxxxxxxx
From: Glen Kramer <glen.kramer@xxxxxxxxxxxx>
Date: Wednesday, May 6, 2020 at 3:46 PM
To: Kevin Noll <kevin.noll@xxxxxxxxxxxx>, "stds-1904-2-TF@xxxxxxxxxxxxxxxxx" <stds-1904-2-TF@xxxxxxxxxxxxxxxxx>
Cc: "Curtis (CableLabs)" <c.knittle@xxxxxxxxxxxxx>, Pradeep Kondamuri <pkondamu@xxxxxxxxx>
Subject: RE: VLANs and UMT Sublayer
Kevin,
First, thank you for putting the effort into annotation the diagram. This explains your concerns well. That is not to say that I share these concerns.
You noted correctly that in 1904.1, the VLAN manipulation takes place in the MAC client, which sits just above the OAM sublayer. In 1904.2, the VLAN manipulation happens inside the UMT sublayer,
which sits just below the OAM sublayer. The interfaces north and south of UMT sublayer and north and south the OAM sublayer are all the same MA_DATA interfaces. So, if the MA_DATA interface is “synonymous with the ISS”, as you stated in you diagram, then the
interface between UMT and OAM sublayers is also synonymous with ISS. Keep in mind that OAM sublayer are optional. If OAM sublayer is absent, then UMT sublayer is adjacent to MAC client, so it makes no sense that one would be allowed to touch VLAN tags and
the other wouldn’t because of an arbitrary placed boundary.
Placement of a function relative to some abstract internal interface in not a big concern when someone talks about compatibility of two standards. You seem to equate the MAC Client to a bridge
and even pointed to a sequence of 802.1Q subclauses that describe functional blocks similar to what we used in SIEPON MAC Client reference model. This is where the analogy ends. The actual function and behavior of each functional block are vastly different.
Specifically, in relation to VLAN modification in 1904.1, it is done based on provisioned OAM rules. For example, for package A, see attribute aRuleSetConfig (0xD7/0x05-01) -- it can SET, COPY, DELETE, REPLACE, INSERT the I-Tags, S-Tags, and C-Tags. And that
operation is not based on MVRP.
Let me remind you that your initial question was: “ if MVRP is in use and UMT Sublayer is adding VLAN tags, how the rest of the network is expected to know
about those tags such that the intermediate switches will accept UMT’s VLAN tags for forwarding to the next hop?”
Similarly, if SIEPON ONU adds or modifies VLAN tags, how is the rest of the network is expected to know about these tags? The answer is simple, the NMS is aware of what tags should be used and provisions them accordingly into intermediate
bridges and into ONUs and the OLT. Exactly the same is with UMT rules. UMT manager and the overall network management system are NOT independent entities. The UMT Manager is part of the same NMS and sets VLAN values based on the input given to it. The operation
of NMS is always operator-specific and is not part of any standard.
Anyway, I’ll repeat again that my position is that we are not in conflict with 802.1Q, even if some previously untaggable frames (like OAMPDU) now can be tagged. That tagging is not random, it
is based on rules set by UMT Manager that coordinates it with the rest of the network and that itself can be a MVRP participant.
But this debate is going on long enough with (at least two) people reading and writing long emails without any resolution in sight. Let’s get to the point: what is your most desired outcome
from this?
If it is just a TF or WG reconfirmation, it was already done when the WG approved D0.5 or the TF approved D06. But if you want an explicit record in the minutes reaffirming the VLAN handling,
let’s put a motion on the floor.
If you’d like to remove VLAN handling from the draft, please submit a comment.
If you’d like to specify an alternative method, please make a proposal.
Regards,
-Glen
From: Kevin Noll [mailto:kevin.noll@xxxxxxxxxxxx]
Sent: Tuesday, May 05, 2020 8:43 PM
To: Glen Kramer <glen.kramer@xxxxxxxxxxxx>;
stds-1904-2-TF@xxxxxxxxxxxxxxxxx
Cc: Curtis (CableLabs) <c.knittle@xxxxxxxxxxxxx>; Pradeep Kondamuri <pkondamu@xxxxxxxxx>
Subject: Re: VLANs and UMT Sublayer
See the annotated diagrams that are attached….
To be clear, I am not arguing that 1904.1 has any problem related to the 802.1AC and 802.1Q models. I am also not trying to say that 1904.1 is strictly compliant with 802.1AC and 802.1Q. However, as illustrated
in the attached diagrams, 1904.1 appears to fit the architectural model of 802.1AC and 802.1Q, I am completely fine with how 1904.1 is described and where it fits in the 802 models, and I am completely fine with the differences in functionality between 1904.1
and 802.1Q.
Is there a specific statement in 1904.2 that is in conflict with 802.1? As you already know… none that I can find. However, the proposed behavior in 1904.2 is architecturally inconsistent with 1904.1 and
802 models. I’ve tried to illustrate this in several different ways.
If the TF chooses to accept a standard that crosses the architectural boundaries that are described in 802.3, 802.1AC and 802.1Q, I am fine with that, too. However, in some cases we’ve argued that 1904.2 must
fit into those models and now we are saying that 1904.2 does not need to be bound by those models. Which is it?
--kan--
--
Kevin A. Noll
Sr. Director, Systems Architecture
Tibit Communications
From: Glen Kramer <glen.kramer@xxxxxxxxxxxx>
Date: Tuesday, May 5, 2020 at 5:25 PM
To: Kevin Noll <kevin.noll@xxxxxxxxxxxx>, "stds-1904-2-TF@xxxxxxxxxxxxxxxxx" <stds-1904-2-TF@xxxxxxxxxxxxxxxxx>
Cc: "Curtis (CableLabs)" <c.knittle@xxxxxxxxxxxxx>, Pradeep Kondamuri <pkondamu@xxxxxxxxx>
Subject: RE: VLANs and UMT Sublayer
Kevin,
> I don’t think it’s accurate to compare 1904.1 VLAN operations with the proposed
> 1904.2 VLAN operations. 1904.1 clearly has the VLAN operations occurring above the
> MAC layer …
You seem to see some differences in the how the 1904.1 handles VLAN operations and how 1904.2 does it. Where do you believe 1904.1 handles the VLAN tags compared to 1904.2? Both are doing it
above MAC and even above MAC Control. But SIEPON is doing much more to VLANs, including VLAN translation, aggregation, and provider bridging modes.
> so, even if it’s not explicitly described, it is easily envisioned how SIEPON
> conforms with the 802.1Q architecture.
Since it is easily envisioned, can you describe how exactly SIEPON conforms to 802.1Q architecture and why exactly the same description does not apply to 1904.2? Better yet, show the specific
text snippets that make 1904.1 conformant to the 802.1Q architecture and 1904.2 not?
> I feel like clause 6.4 will be perceived by our colleagues in 802.1 as semantical handwaving
> to get around the 802.1 architecture. I suppose we can simply say that we are not bound
> by the 802.1 architecture, but then we would be contradicting ourselves because we have
> made every other effort to fit into the 802 architectures.
I don’t see the 1904.2 draft contradicting 802.1Q in any way and I have not been shown any evidence that it does. You raise an alarm, but only provide some vague statements about the problem
and speculation about how our draft will be perceived by SA balloters. Can you be more specific? What exact statement in 1904.2 contradicts what exact statement in 802.1Q?
-Glen
From: Kevin Noll [mailto:kevin.noll@xxxxxxxxxxxx]
Sent: Tuesday, May 05, 2020 1:12 PM
To: Glen Kramer <glen.kramer@xxxxxxxxxxxx>;
stds-1904-2-TF@xxxxxxxxxxxxxxxxx
Cc: Curtis (CableLabs) <c.knittle@xxxxxxxxxxxxx>; Pradeep Kondamuri <pkondamu@xxxxxxxxx>
Subject: Re: VLANs and UMT Sublayer
Glen,
Thank you for humoring my questions, again. I, and others, expressed in the previous calls (9 April and prior) our concern on this issue.
As the TF chair, I feel that it is my responsibility to ensure we have consensus, move the draft forward, and ensure that potential barriers to passage in balloting are removed or risk is minimized. I feel
like clause 6.4 will be perceived by our colleagues in 802.1 as semantical handwaving to get around the 802.1 architecture. I suppose we can simply say that we are not bound by the 802.1 architecture, but then we would be contradicting ourselves because we
have made every other effort to fit into the 802 architectures.
How should I go about ensuring that we don’t run into this during the balloting phase?
--kan--
--
Kevin A. Noll
Sr. Director, Systems Architecture
Tibit Communications
From: Glen Kramer <glen.kramer@xxxxxxxxxxxx>
Date: Tuesday, May 5, 2020 at 3:50 PM
To: Kevin Noll <kevin.noll@xxxxxxxxxxxx>, "stds-1904-2-TF@xxxxxxxxxxxxxxxxx" <stds-1904-2-TF@xxxxxxxxxxxxxxxxx>
Cc: "Curtis (CableLabs)" <c.knittle@xxxxxxxxxxxxx>, Pradeep Kondamuri <pkondamu@xxxxxxxxx>
Subject: RE: VLANs and UMT Sublayer
Kevin,
Please, see below.
-Glen
From: Kevin Noll [mailto:kevin.noll@xxxxxxxxxxxx]
Sent: Tuesday, May 05, 2020 5:16 AM
To: Glen Kramer <glen.kramer@xxxxxxxxxxxx>;
stds-1904-2-TF@xxxxxxxxxxxxxxxxx
Cc: Curtis (CableLabs) <c.knittle@xxxxxxxxxxxxx>; Pradeep Kondamuri <pkondamu@xxxxxxxxx>
Subject: Re: VLANs and UMT Sublayer
Glen,
After re-reading your email, I am confused, again.
Why do you reference figure 11-1?
[GK: ] Because in your email you stated that “I failed to state in the diagrams that the stack represents a single-port device… presumably a host/server.”
I responded that the picture you showed is not a single-port device, because it had MAC Relay Entity, which is used only in bridges. So, the Figure 11-1 illustrates the difference in layering between
the bridges and single-port devices. That is why I referenced it.
Specific to the scenario I posited: 802.1Q-2018 Clause 6.3 specifically says that “A VLAN-aware end station can use the EISS Multiplex Entity (6.17) to provide multiple SAPs, one per VID of interest, to separate
MAC Clients”. I am confused why you did not reference this in your response.
[GK: ] I stated exactly that in my response.
“But end stations may be VLAN-aware for other reasons, such as source pruning
or to support multiple MAC clients served by a single physical port. So, I guess your example wants to look at this latter scenario – one MAC client is an IP Client X and another MAC client is an IP Client Y.” Is it not the same thing, just stated differently?
I specifically asked how the proposed 1904.2 layering diagram aligns with the 802.1 layering. Figure 11-1 does not help clarify the relationship between UMT and 802.1Q.
[GK: ] We have been through this many times, including the presentation I made on our call on April 9th. Here is the slide I showed. It explains how 1904.2 layering relates to 802.1Q layering.
This diagram includes MAC Relay Entity (i.e., assumes a multi-port device).
I thought it all was clear since there were no more questions about this since that presentation. If something is still confusing, please let me know.
Figure 11-1 is specific to describing the operation of MVRP. MVRP would be only tangentially relevant to VLAN tagging operation and only if it is deployed in the end station. Ultimately, MVRP exists, if implemented/deployed,
to support the EISS, so referencing MVRP doesn’t seem to actually answer the questions I am asking.
You have previously indicated that UMT Sublayer didn’t need to participate in MVRP and that UMT Sublayer’s tag manipulation is transparent to 802.1Q. However, I am wondering, if MVRP is in use and UMT Sublayer
is adding VLAN tags, how the rest of the network is expected to know about those tags such that the intermediate switches will accept UMT’s VLAN tags for forwarding to the next hop. Should there be a requirement that UMT cannot add a tag if that VLAN is not
also configured in MVRP?
[GK: ] No, there should not be such a requirement for the UMT Sublayer.
UMT sublayer doesn’t do anything at all until it is explicitly provisioned via UMT_CONFIG message(s). And when it is provisioned by the UMT_CONFIG message to add a tag to frames that match specific rules,
it should not question that order or defy it.
Q: How does the UMT sublayer know what tag value to add and when?
A: It is provisioned by the UMT Manager that issues the UMT_CONFIG UMTPDU.
Q: How does the UMT Manager knows what tag value is to provision?
A: It participates in MVRP or is configured statically by the operator/NMS.
Q: If UMT sublayer is provisioned to insert a VLAN tag, does it mean that the entire device must be VLAN-aware and be a participant in MVRP?
A: No, it does not mean that. Network configuration may require only specific frames to be tagged, for example, only UMTPDUs with OAM subtype or UMTPDU with OMCI subtype. These frames do not cross EISS
and therefore the device’s MVRP participation and VLAN-awareness has no impact on these frames.
This is explained in section 6.4.
--kan--
--
Kevin A. Noll
Sr. Director, Systems Architecture
Tibit Communications
From: Glen Kramer <glen.kramer@xxxxxxxxxxxx>
Date: Monday, May 4, 2020 at 6:29 PM
To: Kevin Noll <kevin.noll@xxxxxxxxxxxx>, "stds-1904-2-TF@xxxxxxxxxxxxxxxxx" <stds-1904-2-TF@xxxxxxxxxxxxxxxxx>
Cc: "Curtis (CableLabs)" <c.knittle@xxxxxxxxxxxxx>, Pradeep Kondamuri <pkondamu@xxxxxxxxx>
Subject: RE: VLANs and UMT Sublayer
Kevin,
The figures you had in your email illustrated a bridge. In a single-port end station, there is no MAC Relay Entity, since there are no multiple ports to relay the frames from and to. The figure
below shows a bridge on the left and a VLAN-aware end-station on the right.
An end station connected to a VLAN-aware bridge via aP2P link does not have to be VLAN aware. The bridge generally takes care of all VLAN-related filtering for the data sent to that station.
But end stations may be VLAN-aware for other reasons, such as source pruning or to support multiple MAC clients served by a single physical port. So, I guess your example wants to look at this latter scenario – one MAC client is an
IP Client X and another MAC client is an IP Client Y.
I am assuming that if there is no any UMT support (i.e., no UMT sublayer) in this end station and in the rest of VLAN-aware bridged network, then there are no questions about IP Clients X and
Y use of VLAN tags X and Y and we don’t need to go into any details. After all, this is 802.1Q stuff that exists today and that has nothing to do with 1904.2.
Now, the question is what happens if this end-station does have an UMT sublayer? There are no rules provisioned for the IP frames, so these frames pass through UMT sublayer unchanged. IP clients
X and Y continue operating as if the UMT sublayer does not exist.
As for the UMTPDUs, we want the UMT sublayer to insert VLAN tag X in UMTPDUs that carry OAM or OMCI payload (presumably because the rest of the bridged networks require those VLAN tags in order
to properly transport the UMTPDUs).
So, in the TX direction, we provision these egress tunnel entrance rules:
1)
For OAM:
IF( DA == SP_DA and ETH_LEN_TYPE == 0x88-09 and Subtype == 0x03 ) THEN
CHANGE( DA, <provisioned unicast addr> )
CHANGE( ETH_TYPE_LEN, 0xA8-C8 )
ADD( VLAN0, X )
2)
For OMCI:
IF( exists( OMCI_DATA) ) THEN
ADD( DA, <provisioned unicast addr> )
ADD( ETH_TYPE_LEN, 0xA8-C8 )
ADD( UMT_SUBTYPE, 0x04 )
ADD( VLAN0, X)
There are some difficulties integrating non-Ethernet-based protocol, such as OMCI into the Ethernet-based protocol stack. But there are a few approaches we can take:
1)
“exists( OMCI_DATA )” checks to see if the data represents OMCI data. The “exists” operator is already defined in Table 6-1. We don’t need to specify the exact mechanism used for determining that the data
is OMCI, but we do need to add a field code for that OMCI data.
2)
Another approach is to specify codes for interfaces from which the Request primitive is received {UMTSI:UMTPDU, UMTSI:OMCI, UMTSI:MA_DATA}.
If we do that, then the condition for this rule can be written as
IF( REQUEST_FROM( UMTSI:OMCI ) ) THEN …
This maybe a better approach because it also can be used for demultiplexing the received data to the above three interfaces
There are no any other egress rules, so anything that arrived from UMTSI:MA_DATA.Request primitive and that does not match a rule, is simply passed down as the MACCSI:MA_DATA.Request
primitive. This applies to all frames sourced from IP Clients X and Y. They already have their VLAN tags inserted by their respective Clients.
Now, for the RX direction we have these ingress tunnel exit rules:
1)
For OAM:
IF( DA == <local_addr> and ETH_LEN_TYPE == 0xA8-C8 and Subtype == 0x03 and exists(VLAN0) ) THEN
CHANGE( DA, SP_DA )
CHANGE( ETH_TYPE_LEN, 0x88-09 )
DELETE( VLAN0 )
INDICATION_TO( UMTSI:MA_DATA )
2)
For OMCI:
IF( DA == <local_addr> and ETH_LEN_TYPE == 0xA8-C8 and Subtype == 0x04 and exists(VLAN0) ) THEN
DELETE( DA, <provisioned unicast addr> )
DELETE( ETH_TYPE_LEN, 0xA8-C8 )
DELETE( UMT_SUBTYPE, 0x04 )
DELETE( VLAN0, X)
INDICATION_TO( UMTSI:OMCI )
Note, the above RX rules simply check for the existence of the VLAN tag (exists(VLAN0)), but do not require a specific value.
If needed, these conditions can be changed to “VLAN0==X” to verify that the VLAN value is exactly X. But I don’t think this is needed.
Again, there are no other rules that match IPv4 Ethertype 0x08-00, so all these frames simply pass through the UMT sublayer unchanged, i.e., from MACCSI:MA_DATA.Indication, they simply change
into UMTSI: MA_DATA.Indication. Per 802.1Q, the EISS Multiplex Entity then would demultiplex the received packets to their respective clients based on the value of VLAN tag. This is all done at a higher layer and out of scope for 1904.2.
I hope this helps.
-Glen
From: Kevin Noll [mailto:kevin.noll@xxxxxxxxxxxx]
Sent: Friday, May 01, 2020 7:40 PM
To: Glen Kramer <glen.kramer@xxxxxxxxxxxx>;
stds-1904-2-TF@xxxxxxxxxxxxxxxxx
Cc: Curtis (CableLabs) <c.knittle@xxxxxxxxxxxxx>; Pradeep Kondamuri <pkondamu@xxxxxxxxx>
Subject: Re: VLANs and UMT Sublayer
1)
Yes. The MAC DA is the receiving port’s MAC. I failed to state in the diagrams that the stack represents a single-port device… presumably a host/server.
2)
UMTPDU subtype is irrelevant for the example… it could be anything, but let’s make examples of OAM and OMCI.
3)
The network administrator’s intent is to ensure that all UMTPDUs and all IP Network X are carried on VLAN X throughout the network and all IP Network Y is carried in VLAN Y throughout the network. The host/station in the
example is VLAN aware. If it receives a frame for VLAN X, then it accepts it and processes it (how it processes it is the question I would like to answer). By “process it”, I mean that UMTPDUs that have VLAN X on them will be accepted and processed by the
host in the corresponding sublayer, IP Packets that have VLAN X on them will also be processed by the corresponding sublayer(s) and network layer in the host. IP packets with VLAN Y on them will be processed by the corresponding sublayer(s) and network layer
in the host. Frames received with any other VLAN tag will not be accepted by the host, and, since the host is not a bridge, the frames will not be forwarded elsewhere.
Thank you for pointing out where the EISS and ISS are defined and providing the diagram. Unfortunately, this is the source of my confusion. It is unclear to me how the UMT layering maps onto the 802.1 layering.
I understand that the higher layers should not even realize that the UMT Sublayer is present, but it continues to be fuzzy to me how that will work when UMT is manipulating VLAN tags.
This gets especially confusing when you have UMT CONFIG being sent between UMT stations to configure the CTE (which might be filtering on VLANs) and some switch in the middle of the network is also manipulating
VLAN tags, potentially removing the very tag that UMT CONFIG has configured in the remote UMT Sublayer. In this case, how would UMT CONFIG work? I suppose the answer is that there will need to be a centralized management entity for UMT that is fully aware
of all the VLAN manipulation that is occurring in the network.
--kan--
--
Kevin A. Noll
Sr. Director, Systems Architecture
Tibit Communications
From: Glen Kramer <glen.kramer@xxxxxxxxxxxx>
Date: Friday, May 1, 2020 at 5:52 PM
To: Kevin Noll <kevin.noll@xxxxxxxxxxxx>, "stds-1904-2-TF@xxxxxxxxxxxxxxxxx" <stds-1904-2-TF@xxxxxxxxxxxxxxxxx>
Cc: "Curtis (CableLabs)" <c.knittle@xxxxxxxxxxxxx>, Pradeep Kondamuri <pkondamu@xxxxxxxxx>
Subject: RE: VLANs and UMT Sublayer
Kevin,
I will be happy to show the exact rules that would accomplish what you need if you could clarify what exactly your use case tries to do.
Specifically, please, clarify these questions:
1)
For all three frames types, is the DA equal to the receiving port’s MAC address?
2)
What is the UMTPDU subtype?
3)
Do you want the receiving device to verify that the UMTPDU is received with exactly VLAN X and discard the frame is it is either untagged or if VLAN value is not X?
The answer to your question in red is No, the EISS is not the same as MA_DATA.request/indication. ESS is located in different place (see the figure below) and its primitives (EM_UNITDATA.request
and EM_UNIDATA.indication) have many more parameters then are present in MA_DATA primitives. The MA_DATA interfaces maps into ISS (M_UNITDATA.request/indication primitives) and the mapping is described in the 802.1AC, Section 13.1.
I am not sure why this is even a question, though. Anything above UMT remains as it is now. None of the higher layers even know if UMT sublayer is there or not.
-Glen
From: Kevin Noll [mailto:kevin.noll@xxxxxxxxxxxx]
Sent: Friday, May 01, 2020 1:39 PM
To: stds-1904-2-TF@xxxxxxxxxxxxxxxxx
Cc: Glen Kramer <glen.kramer@xxxxxxxxxxxx>; Curtis (CableLabs) <c.knittle@xxxxxxxxxxxxx>;
Pradeep Kondamuri <pkondamu@xxxxxxxxx>
Subject: VLANs and UMT Sublayer
Glen,
I continue to be puzzled by the ability of UMT sublayer to add/remove and filter based on VLAN tags.
Could you take a look at the attached figures and help me understand how this would work and what I am misunderstanding.
--kan--
--
Kevin A. Noll
Sr. Director, Systems Architecture
Tibit Communications
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