Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [1904-ANWG] PAR Modification for IEEE 1904.2



All,

Can someone remind me what was the specific objection to the term
"Ethernet-based  subscriber access networks" on the last call? Like Marek, I
also don't see anything ambiguous or confusing about this. But I do have a
concern about expanding the scope to cover 802.11 and 802.16 standards. That
was never discussed in the TF2 before.  Not do I think this will fly with
the Nescom. On the one hand, we took too long even with the existing scope
and are asking NesCom for additional time, on the other hand, we are trying
to significantly expand the scope of the project. There are no .11 or .16
representatives or affiliates in TF2 and I don't think NesCom will be keen
to approve this change.

I do remember we decided to include the CO-based devices, in addition to the
currently-listed CPE devices. Also, we talked for a long time about removing
the encryption. I don't see what other changes are needed.

 Thank you,
-Glen

-----Original Message-----
From: Kevin A Noll [mailto:ieee.lists@xxxxxxxxxxxxxxx]
Sent: Wednesday, August 08, 2018 12:35 PM
To: STDS-1904-WG@xxxxxxxxxxxxxxxxx
Subject: Re: [1904-ANWG] PAR Modification for IEEE 1904.2

I cannot find a reference in IEEE 802 or any of its parts that refer to all
the parts as “Ethernet”. Can you provide such reference?

Either way, whatever we call it, it just needs to be clear. This was a point
of discussion in the meeting, so I attempted to clarify it.

Regarding transiting MAC bridges: The original text was “multi-hop
capabilities” and there was discussion in the last meeting that this could
mean L2 or L3 and that it should be clarified. This is my attempt to do
that. Is there a better way to state this?

—kan—

> On Aug 8, 2018, at 8:43 AM, Marek Hajduczenia <mxhajduczenia@xxxxxxxxx>
> wrote:
>
> Kevin,
>
> All .11, .16, etc. is still Ethernet so I do not really understand the
> issue here - perhaps it is just something I missed in understanding what
> was wrong with " Ethernet-based subscriber access networks" to begin with.
>
> As far as transiting MAC bridges is concerned - do we need to say
> anything, really, provided that we use proper MAC addressing, it is
> inherent
>
> Marek
>
> -----Original Message-----
> From: Kevin A Noll <ieee.lists@xxxxxxxxxxxxxxx>
> Sent: Wednesday, August 8, 2018 8:34 AM
> To: Marek Hajduczenia <mxhajduczenia@xxxxxxxxx>
> Cc: stds-1904-wg@xxxxxxxxxxxxxxxxx; stds-1904-2-TF@xxxxxxxxxxxxxxxxx;
> Fernando Villarruel <villarf@xxxxxxxxx>; Pradeep Kondamuri
> <pkondamu@xxxxxxxxx>; Edward A Walter <ew8532@xxxxxxx>
> Subject: Re: PAR Modification for IEEE 1904.2
>
> 1. I chose to use “IEEE 802 Suite” because this protocol should be able to
> operate in the context of any of the protocols defined under IEEE 802… for
> example, it should be able to operate over an 802.11 link, and an 802.16
> link, etc etc. Arguably, those are PHY layers, but they are NOT Ethernet
> (802.3), but we should cover those as use cases.
>
> Can you suggest text that would be clearer, but still cover that scope?
>
> 2. “Ability to transit MAC-bridges” was meant to clarify the original
> “multi-hop” statement. It seems to me that this should be stated for the
> exact example that you give… one of the use cases is to enable a method
> for protocols that would normally be link-local to transit a MAC bridge.
>
> Do you have alternative text to suggest that would be more clear or
> precise?
>
> 3. “Single 802 MAC domain”… I agree that this term is not well
> established. Refer to (1) above … the intent is to communicate that
> “multi-hop” could mean that the frames could cross multiple link types.
>
> Suggested text?
>
> —kan—
>
>
>> On Aug 3, 2018, at 7:30 AM, Marek Hajduczenia <mxhajduczenia@xxxxxxxxx>
>> wrote:
>>
>> Personally, I do not k now what was wrong with " Ethernet-based
>> subscriber access networks" to begin with. Perhaps someone can explain it
>> to me what is wrong with this term - the way I read it, it is anything
>> that runs Ethernet, irrespective of the media underneath; and if we run
>> Ethernet, we can run this new management protocol of ours. The " the IEEE
>> 802 suite" term is not any clearer and I would argue - it is way more
>> vague and ill-defined.
>>
>> The " ability to transit MAC-bridges" is inherent to any L2 frame unless
>> it is explicitly link local.
>>
>> I also do not know " in a single IEEE 802 MAC domain" is a
>> well-established term and what it is intended to mean. For link-local
>> protocols, this would be just link itself. I believe what you mean in
>> here is L2 broadcast domain, i.e., as far as any broadcast L2 frame
>> would reach. This is the term I saw used before
>>
>> Marek
>>
>> -----Original Message-----
>> From: stds-1904-wg@xxxxxxxx <stds-1904-wg@xxxxxxxx> On Behalf Of Kevin
>> A Noll
>> Sent: Thursday, August 2, 2018 7:39 PM
>> To: stds-1904-wg@xxxxxxxxxxxxxxxxx; stds-1904-2-TF@xxxxxxxxxxxxxxxxx
>> Cc: Fernando Villarruel <villarf@xxxxxxxxx>; Pradeep Kondamuri
>> <pkondamu@xxxxxxxxx>; Edward A Walter <ew8532@xxxxxxx>
>> Subject: PAR Modification for IEEE 1904.2
>>
>> Colleagues,
>>
>> During the 1 August 2018 meeting we discussed the need to modify the
>> scope of the PAR for IEEE 1904.2.
>>
>> There was consensus that
>> 1. encryption should be removed from the scope, 2. "Ethernet-based”
>> should be clarified, 3. the type of devices to be managed needs to be
>> expanded beyond “CPE”
>> 4. “Multi-hop” should be clarified to limit the scope to Layer-2
>>
>>
>> The current PAR Scope reads as follows:
>>
>> This standard describes a management channel for customer-premises
>> equipment (CPE) connected to Ethernet-based subscriber access networks.
>> The key characteristics of the specified management channel are:
>> - Multi-hop capabilities to allow management of various CPE devices
>> located behind an Optical Network Unit (ONU), a Coaxial Network Unit
>> (CNU), a Residential Gateway (RGW), etc.
>> - Extensibility to accommodate new management protocols and/or new types
>> of CPE devices.
>> - Broadcast/multicast capabilities to allow simultaneous (synchronized)
>> configuration of multiple devices.
>> - Encryption capabilities to ensure secure access to managed CPE devices
>> by the network operators.
>> The standard describes the message format as well as processing
>> operations and forwarding rules at the intermediate nodes.
>>
>>
>>
>> I propose the following as an updated scope:
>>
>> This standard describes a management channel for devices used in
>> subscriber access networks that use protocols in the IEEE 802 suite. The
>> key characteristics of the management channel are:
>> - The ability to transit MAC-bridges in a single IEEE 802 MAC domain to
>> allow management of devices using protocols that would not normally be
>> forwarded.
>> - Extensibility to accommodate new management protocols and new types of
>> devices.
>> - The ability to simultaneously send messages to multiple stations using
>> broadcast or multicast functions.
>> This standard describes the message format as well as processing
>> operations of stations and MAC-bridges.
>>
>> Please reply with comments and suggested edits.
>>
>> —kan—
>> Kevin A. Noll
>>
>> ______________________________________________________________________
>> __ To unsubscribe from the STDS-1904-WG list, click the following
>> link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-1904-WG&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-WG list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-1904-WG&A=1

________________________________________________________________________
To unsubscribe from the STDS-1904-WG list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-1904-WG&A=1