Re: [netmod] Comments on draft-ietf-netmod-acl-extensions

[Oscar González de Dios]

Hi Mahesh, Med,

   Comments inline,

Oscar

De: mohamed.boucad...@orange.com 
Enviado el: lunes, 24 de julio de 2023 15:48
Para: Mahesh Jethanandani ; NetMod WG 
CC: samier.barguil_gira...@nokia.com; Oscar González de Dios 

Asunto: RE: [netmod] Comments on draft-ietf-netmod-acl-extensions

Hi Mahesh,

Thank you for the comments.

Please see inline. I let my co-author further comment as appropriate.

Cheers,
Med

De : netmod mailto:netmod-boun...@ietf.org>> De la 
part de Mahesh Jethanandani
Envoyé : lundi 24 juillet 2023 14:53
À : NetMod WG mailto:netmod@ietf.org>>
Objet : [netmod] Comments on draft-ietf-netmod-acl-extensions

I do support this work to extend the ACL model defined in RFC 8519.

What I suggested on the mike was that the ICMP types be defined in an existing 
IANA YANG module. But my own search did not reveal an existing model that has 
type definitions where ICMP types could be added. I would suggest that the 
authors name the module something more generic than iana-icmp-types simply to 
allow future additions to the model for other type definitions, something like 
iana-acl-header-types.

[Med] The new IANA ICMP type module can be used by models other than 
ACL-specific ones. I prefer to not have acl in the IANA module.

[Oscar] I also agree with Med on having ICMP types in a specific file to match 
1:1 with an IANA  registry 
(https://www.iana.org/assignments/icmp-parameters/icmp-parameters.xml) . Other 
type definitions should have also their own IANA maintained module. In fact... 
ICMPv6 has a separate registry which should be added too ...

The other question relates to how ICMP type are currently defined in RFC 8519. 
Is there a plan to update that type to the new types that will be defined in 
the IANA module? Is there a plan to include ICMP subtype (called code in RFC 
8519) both in the new IANA module, but also update RFC 8519 with the definition 
in the IANA module?

[Med] We aren't updating that part of 8519 because we are not approaching this 
as a bis. The new type is only used in the new extensions.

[Oscar] In fact, one of my questions of todays presentation at the end was  
Are we happy with current approach of augment-only? Should we opt for a new 
version of the yang model, the match vs ICMP code could be modified from 
matching vs a unit8 for type and code, match vs an identityref (which I guess 
is a non backwards compatible change).

Regards

Mahesh Jethanandani
mjethanand...@gmail.com








Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede 
contener información privilegiada o confidencial y es para uso exclusivo de la 
persona o entidad de destino. Si no es usted. el destinatario indicado, queda 
notificado de que la lectura, utilización, divulgación y/o copia sin 
autorización puede estar prohibida en virtud de la legislación vigente. Si ha 
recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente 
por esta misma vía y proceda a su destrucción.

The information contained in this transmission is confidential and privileged 
information intended only for the use of the individual or entity named above. 
If the reader of this message is not the intended recipient, you are hereby 
notified that any dissemination, distribution or copying of this communication 
is strictly prohibited. If you have received this transmission in error, do not 
read it. Please immediately reply to the sender that you have received this 
communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode 
conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa 
ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica 
notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização 
pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem 
por erro, rogamos-lhe que 

Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not?

[Christian Hopps]

Balázs Lengyel  writes:


Hello Andy,

I assume you are referring to the sentence “A new module revision MAY
contain NBC changes” from the versioning draft.

IMHO the authors agree that NBC changes are bad. They should be
allowed but discouraged.


That's what "SHOULD NOT" means.


Would a sentence like

“A new module revision MAY but SHOULD NOT contain NBC changes … ”

be OK ?

I think the MAY part is also needed< because that is what we are
introducing as new compared to 7950.


IMO using both MAY and SHOULD NOT is confusing and unnecessary. "SHOULD NOT" 
allows a thing while discouraging it.

Thanks,
Chris.




be agreeable?

Regards Balazs



From: Andy Bierman 
Sent: Sunday, 23 July, 2023 17:26
To: Balázs Lengyel 
Cc: Martin Björklund ; netmod@ietf.org
Subject: Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC
changes in YANG 1.0 & YANG 1.1 or not?







On Sun, Jul 23, 2023 at 5:08 PM Balázs Lengyel <
balazs.leng...@ericsson.com> wrote:

Hello Andy,

In 3GPP we have endless debates about what is a bugfix. If the
functionality will not work it is a bugfix. If it works in a bad
way it is or maybe not a bugfix. If it works just in an ugly way
is it a bugfix?

Conclusion: it is not possible to define clear criteria about
what is a bug and what is an improvement.





It is easy to change MAY to SHOULD NOT in the versioning draft.



IMO changing MUST NOT to MAY is unacceptable.

The versioning draft is attempting to completely toss out all of the
YANG update rules.

Changing the normative text to SHOULD NOT instead of MAY does not
require any specification of a bugfix.





Regards Balazs





Andy





From: netmod  On Behalf Of Andy Bierman
Sent: Wednesday, 19 July, 2023 10:13
To: Martin Björklund 
Cc: netmod@ietf.org
Subject: Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC
changes in YANG 1.0 & YANG 1.1 or not?







On Tue, Jul 18, 2023 at 4:48 AM Martin Björklund <
mbj+i...@4668.se> wrote:

What about Option 4 - Pragmatic Adherence to Current RFC7950
Rules





This is the approach I also suggested on the mailing list.



- As it works today; the IETF *has* published bugfixed
modules that break the
  rules.  (and many vendors do this as well)
- (Possibly) Introduce rev:non-backwards-compatible

This would allow 6991bis to update date-and-time to follow
the updated
semantics for RFC3339 timestamps (which imo is the only
reasonable
thing to do - the consuequences of this change is handled by
SEDATE).





The important thing in each case is to consider

the expected impact on the real world and real deployments.



IMO a bugfix should be OK, even if the rules in RFC 7950 say it
is an NBC change.

But this is not the same thing as changing the rules in a new
document to shift the

implementation burden to the client.



This is only an IETF issue and the burden should be on a WG to
convince the IESG and IETF

that making the NBC change is a bugfix and should be allowed as a
special case.






/martin



Andy




"Jason Sterne (Nokia)"  wrote:
> Hi all,
>
> At the request of the NETMOD chairs, and on behalf of the
YANG Versioning weekly call group, here's a summary of Key
Issue #1 for the versioning work (i.e. for the Module
Versioning and YANG Semver WGLC).
>
> We'd like to suggest that the WG has a strong focus on
deciding on this specific issue first. Then we'll move on to
tackle other key issues. The idea is to try and avoid getting
tangled in a web of multiple intertwined issues.
>
> Key Issue #1 is the following:  Allow NBC changes in YANG
1.0 & YANG 1.1 or not?
>
> For now please avoid debating other issues in this thread
(e.g. multiple vs single label schemes, whether YANG semver
is a good scheme, etc). Let's focus on K1 and work towards a
WG decision.
>
> ###
> K1) Allow NBC changes in YANG 1.0 & YANG 1.1 or not?
>
> Option 1 - Update RFC7950 to Allow NBC Changes
>
---
> - Module Versioning modifies 7950 to allow NBC changes
> - guidance that NBC changes SHOULD NOT be done (impact to
user base)
> - rev:non-backwards-compatible is a YANG extension
> - introduction in published YANG does not impact
current tooling (ignored until recognized)
> PROS:
> - address fundamental requirement of this versioning work
(requirements doc)
> - allows gradual adoption in the industry. YANG authors can
immeditately start publishing with the new extensions.
> - move 

Re: [netmod] Comments on draft-ietf-netmod-acl-extensions

[mohamed . boucadair]

Hi Mahesh,

Thank you for the comments.

Please see inline. I let my co-author further comment as appropriate.

Cheers,
Med

De : netmod  De la part de Mahesh Jethanandani
Envoyé : lundi 24 juillet 2023 14:53
À : NetMod WG 
Objet : [netmod] Comments on draft-ietf-netmod-acl-extensions

I do support this work to extend the ACL model defined in RFC 8519.

What I suggested on the mike was that the ICMP types be defined in an existing 
IANA YANG module. But my own search did not reveal an existing model that has 
type definitions where ICMP types could be added. I would suggest that the 
authors name the module something more generic than iana-icmp-types simply to 
allow future additions to the model for other type definitions, something like 
iana-acl-header-types.

[Med] The new IANA ICMP type module can be used by models other than 
ACL-specific ones. I prefer to not have acl in the IANA module.

The other question relates to how ICMP type are currently defined in RFC 8519. 
Is there a plan to update that type to the new types that will be defined in 
the IANA module? Is there a plan to include ICMP subtype (called code in RFC 
8519) both in the new IANA module, but also update RFC 8519 with the definition 
in the IANA module?

[Med] We aren't updating that part of 8519 because we are not approaching this 
as a bis. The new type is only used in the new extensions.

Regards

Mahesh Jethanandani
mjethanand...@gmail.com






Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Broadband Forum Liaison concerning: New Project for Addressing ONU Management at Scale

[David Sinicrope]

FYI - the liaison has been posted to IETF Statements 
.


https://datatracker.ietf.org/liaison/1850/

On 7/24/23 5:26 PM, David Sinicrope wrote:


Thanks Adrian. I wasn't aware of CCAMPs interest in broadband access 
ONU equipment management, but as it is management of optical network 
elements they should be aware.


Dave

On 7/24/23 5:22 PM, Adrian Farrel wrote:


Please copy CCAMP into these discussions as the WG actively writing 
YANG models for optical elements in the network.


Cheers,

Adrian

*From:*netmod  *On Behalf Of *David Sinicrope
*Sent:* 24 July 2023 22:11
*To:* netmod@ietf.org
*Cc:* david.sinicr...@ericsson.com
*Subject:* [netmod] Broadband Forum Liaison concerning: New Project 
for Addressing ONU Management at Scale


Hi All,

As noted during the NETMOD session today, the BBF has sent a liaison 
regarding their new project for Addressing ONU Management at Scale.


While not yet posted to IETF Statements 
, the liaison has the content 
below and as noted in the meeting today, should have a response.


In the coming days, I'll be drafting the response on behalf of the 
Chairs. Input is welcome.


Please let me know if you have questions

Thanks,

Dave Sinicrope
IETF Liaison Manager for the Broadband Forum

From the Chair's slides:

Liaisons and Communications

Incoming:
– From:Broadband Forum
– Received: 2023-03-09
– Title: New Project for Addressing ONU Management at Scale
– The Broadband Forum Fiber Access Networks (FAN) Work Area recently
agreed to initiate a new project for the optimization of management of
Optical Network Units (ONU) at scale. This project, called WT-505: ONU
Management at Scale, is intended to be an enhancement of the existing
specification, TR-385: ITU-T xPON YANG Modules. The following describes
the issues and considerations that led to the need for the new project.
– See list for attachment

Liaison content:

*Broadband Forum Liaison To: *

Kent Watsen, IETF NETMOD WG Co-Chair,  



Lou Berger, IETF NETMOD WG Co-Chair,  



Scott Mansfield, ITU-T Q14/15 Rapporteur, 
 


Liping Chen, ITU-T Q14/15 Associate Rapporteur,  



Paul Nikolich, IEEE 802 Chair,  



Glenn Parsons, IEEE 802.1 Chair,  



Jessy Rouyer, IEEE 802.1 Vice Chair,  



David Law, IEEE 802.3 Chair,  

Adam Healey, IEEE 802.3 Vice Chair,  



*From:*

Lincoln Lavoie
Broadband Forum Technical Committee Chair  



*Liaison Communicated* *By:*

Ken Ko

Broadband Forum Managing Director  



*Date:* 8^th June 2023

*Subject:* For Information: New Project for Addressing ONU Management 
at Scale


The Broadband Forum Fiber Access Networks (FAN) Work Area recently 
agreed to initiate a new project for the optimization of management 
of Optical Network Units (ONU) at scale. This project, called WT-505: 
ONU Management at Scale, is intended to be an enhancement of the 
existing specification, TR-385: ITU-T xPON YANG Modules. The 
following describes the issues and considerations that led to the 
need for the new project.


In contrast to many other transport technologies, a single PON 
interface can multiplex as many as 128 ONUs. It is also typical for a 
single Optical Line Termination (OLT) to contain many such PON 
interfaces.


At this level of dimensioning, the OLT YANG modeled configuration 
data becomes very large due to the high number of ONUs to be managed. 
With current TR-385 and TR-383 Broadband Forum YANG models, the 
management of large OLTs suffers severe performance degradation. 
Examples of such degradation are:


·Time to validate YANG constraints when configuring ONU data nodes 
(e.g., due to very large OLT interface and hardware component lists)


·Time to delete an ONU (time to retrieve all data nodes of the ONU)

·Time to perform a  of a full OLT configuration.

Many Broadband Forum contributions have been submitted and discussed 
that demonstrate ONU management needs to be optimized to keep the OLT 
manageable. It has been determined that efficient optimization of ONU 
management requires the following measures:


·Collocate ONU data nodes per ONU, rather than have them interleaved 
with OLT data nodes (e.g., in the same interface or hardware 
component list) as per TR-385. This involves defining a list of ONUs 
in the OLT where each ONU entry contains all ONU data nodes.


·Bring a strong reduction of the configuration data size per ONU. 
This will be achieved using ONU templates combined with the use of 
shared ONU profiles.


IETF schema mount was considered as a solution for collocating ONU 
data nodes. There were drawbacks to this approach, however. The size 
of the datastore was not 

[netmod] Comments on draft-ietf-netmod-acl-extensions

[Mahesh Jethanandani]

I do support this work to extend the ACL model defined in RFC 8519.

What I suggested on the mike was that the ICMP types be defined in an existing 
IANA YANG module. But my own search did not reveal an existing model that has 
type definitions where ICMP types could be added. I would suggest that the 
authors name the module something more generic than iana-icmp-types simply to 
allow future additions to the model for other type definitions, something like 
iana-acl-header-types.

The other question relates to how ICMP type are currently defined in RFC 8519. 
Is there a plan to update that type to the new types that will be defined in 
the IANA module? Is there a plan to include ICMP subtype (called code in RFC 
8519) both in the new IANA module, but also update RFC 8519 with the definition 
in the IANA module?

Regards

Mahesh Jethanandani
mjethanand...@gmail.com






___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Comments on draft-ietf-netmod-acl-extensions

[mohamed . boucadair]

Hi Joe,

Thank you for the comments.

Please see inline.

Cheers,
Med

De : netmod  De la part de Joe Clarke (jclarke)
Envoyé : lundi 24 juillet 2023 14:25
À : NETMOD Group 
Objet : [netmod] Comments on draft-ietf-netmod-acl-extensions

I support this work.  I think the authors have a number of good enhancements in 
here.  I have a few comments:


  *   It feels like the problem statement section will get dated as this 
document gets standardized.  I get wanting to rationalize the work, but I would 
focus more on the solution.  Perhaps the rationale needs to be move to an 
Appendix.
[Med] Fair comment. Added an issue to track this one: 
https://github.com/boucadair/enhanced-acl-netmod/issues/30


  *   On aliases, is there a plan to create a grouping of common aliases?  I 
can see that being useful.
[Med] We do have a grouping for alias. Not sure what you meant by "common", 
though :-)


  *   Could Aliases be applied to VLANs?  I think it would be useful to be able 
to match on a VLAN name or name class (match on VLAN SERVER, or Example, Co 
VLANs).
[Med] VLANs are currently not part of the current alias grouping. We may 
consider having l2-aliases to cover VLANs, MAC addresses, etc. We need to think 
more about mixing L2/L3 aliases. Created an issue to track this one: 
https://github.com/boucadair/enhanced-acl-netmod/issues/29

Joe

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Broadband Forum Liaison concerning: New Project for Addressing ONU Management at Scale

[David Sinicrope]

Thanks Adrian. I wasn't aware of CCAMPs interest in broadband access ONU 
equipment management, but as it is management of optical network 
elements they should be aware.


Dave

On 7/24/23 5:22 PM, Adrian Farrel wrote:


Please copy CCAMP into these discussions as the WG actively writing 
YANG models for optical elements in the network.


Cheers,

Adrian

*From:*netmod  *On Behalf Of *David Sinicrope
*Sent:* 24 July 2023 22:11
*To:* netmod@ietf.org
*Cc:* david.sinicr...@ericsson.com
*Subject:* [netmod] Broadband Forum Liaison concerning: New Project 
for Addressing ONU Management at Scale


Hi All,

As noted during the NETMOD session today, the BBF has sent a liaison 
regarding their new project for Addressing ONU Management at Scale.


While not yet posted to IETF Statements 
, the liaison has the content 
below and as noted in the meeting today, should have a response.


In the coming days, I'll be drafting the response on behalf of the 
Chairs. Input is welcome.


Please let me know if you have questions

Thanks,

Dave Sinicrope
IETF Liaison Manager for the Broadband Forum

From the Chair's slides:

Liaisons and Communications

Incoming:
– From:Broadband Forum
– Received: 2023-03-09
– Title: New Project for Addressing ONU Management at Scale
– The Broadband Forum Fiber Access Networks (FAN) Work Area recently
agreed to initiate a new project for the optimization of management of
Optical Network Units (ONU) at scale. This project, called WT-505: ONU
Management at Scale, is intended to be an enhancement of the existing
specification, TR-385: ITU-T xPON YANG Modules. The following describes
the issues and considerations that led to the need for the new project.
– See list for attachment

Liaison content:

*Broadband Forum Liaison To: *

Kent Watsen, IETF NETMOD WG Co-Chair,  



Lou Berger, IETF NETMOD WG Co-Chair,  



Scott Mansfield, ITU-T Q14/15 Rapporteur, 
 


Liping Chen, ITU-T Q14/15 Associate Rapporteur,  



Paul Nikolich, IEEE 802 Chair,  



Glenn Parsons, IEEE 802.1 Chair,  



Jessy Rouyer, IEEE 802.1 Vice Chair,  



David Law, IEEE 802.3 Chair,  

Adam Healey, IEEE 802.3 Vice Chair,  



*From:*

Lincoln Lavoie
Broadband Forum Technical Committee Chair  



*Liaison Communicated* *By:*

Ken Ko

Broadband Forum Managing Director  



*Date:* 8^th June 2023

*Subject:* For Information: New Project for Addressing ONU Management 
at Scale


The Broadband Forum Fiber Access Networks (FAN) Work Area recently 
agreed to initiate a new project for the optimization of management of 
Optical Network Units (ONU) at scale. This project, called WT-505: ONU 
Management at Scale, is intended to be an enhancement of the existing 
specification, TR-385: ITU-T xPON YANG Modules. The following 
describes the issues and considerations that led to the need for the 
new project.


In contrast to many other transport technologies, a single PON 
interface can multiplex as many as 128 ONUs. It is also typical for a 
single Optical Line Termination (OLT) to contain many such PON 
interfaces.


At this level of dimensioning, the OLT YANG modeled configuration data 
becomes very large due to the high number of ONUs to be managed. With 
current TR-385 and TR-383 Broadband Forum YANG models, the management 
of large OLTs suffers severe performance degradation. Examples of such 
degradation are:


·Time to validate YANG constraints when configuring ONU data nodes 
(e.g., due to very large OLT interface and hardware component lists)


·Time to delete an ONU (time to retrieve all data nodes of the ONU)

·Time to perform a  of a full OLT configuration.

Many Broadband Forum contributions have been submitted and discussed 
that demonstrate ONU management needs to be optimized to keep the OLT 
manageable. It has been determined that efficient optimization of ONU 
management requires the following measures:


·Collocate ONU data nodes per ONU, rather than have them interleaved 
with OLT data nodes (e.g., in the same interface or hardware component 
list) as per TR-385. This involves defining a list of ONUs in the OLT 
where each ONU entry contains all ONU data nodes.


·Bring a strong reduction of the configuration data size per ONU. This 
will be achieved using ONU templates combined with the use of shared 
ONU profiles.


IETF schema mount was considered as a solution for collocating ONU 
data nodes. There were drawbacks to this approach, however. The size 
of the datastore was not improved as the same data nodes are mounted 
per ONU. There is also a known lack of tooling that supports schema 
mount making it difficult for this solution to be broadly implemented 
in 

[netmod] Comments on draft-ietf-netmod-acl-extensions

[Joe Clarke (jclarke)]

I support this work.  I think the authors have a number of good enhancements in 
here.  I have a few comments:


  *   It feels like the problem statement section will get dated as this 
document gets standardized.  I get wanting to rationalize the work, but I would 
focus more on the solution.  Perhaps the rationale needs to be move to an 
Appendix.
  *   On aliases, is there a plan to create a grouping of common aliases?  I 
can see that being useful.
  *   Could Aliases be applied to VLANs?  I think it would be useful to be able 
to match on a VLAN name or name class (match on VLAN SERVER, or Example, Co 
VLANs).

Joe
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Broadband Forum Liaison concerning: New Project for Addressing ONU Management at Scale

[Adrian Farrel]

Please copy CCAMP into these discussions as the WG actively writing YANG models 
for optical elements in the network.

 

Cheers,

Adrian

 

From: netmod  On Behalf Of David Sinicrope
Sent: 24 July 2023 22:11
To: netmod@ietf.org
Cc: david.sinicr...@ericsson.com
Subject: [netmod] Broadband Forum Liaison concerning: New Project for 
Addressing ONU Management at Scale

 

 

Hi All,

As noted during the NETMOD session today, the BBF has sent a liaison regarding 
their new project for Addressing ONU Management at Scale.

While not yet posted to IETF Statements  
, the liaison has the content below and as noted in the meeting today, should 
have a response.  

In the coming days, I'll be drafting the response on behalf of the Chairs. 
Input is welcome.

Please let me know if you have questions

Thanks,

Dave Sinicrope
IETF Liaison Manager for the Broadband Forum

 

 

>From the Chair's slides:

Liaisons and Communications

Incoming:
– From:Broadband Forum
– Received: 2023-03-09
– Title: New Project for Addressing ONU Management at Scale
– The Broadband Forum Fiber Access Networks (FAN) Work Area recently
agreed to initiate a new project for the optimization of management of
Optical Network Units (ONU) at scale. This project, called WT-505: ONU
Management at Scale, is intended to be an enhancement of the existing
specification, TR-385: ITU-T xPON YANG Modules. The following describes
the issues and considerations that led to the need for the new project.
– See list for attachment

Liaison content:

 

Broadband Forum Liaison To: 

Kent Watsen, IETF NETMOD WG Co-Chair,   
 

Lou Berger, IETF NETMOD WG Co-Chair,   
 

Scott Mansfield, ITU-T Q14/15 Rapporteur,  
  

Liping Chen, ITU-T Q14/15 Associate Rapporteur,   


Paul Nikolich, IEEE 802 Chair,   


Glenn Parsons, IEEE 802.1 Chair,   
 

Jessy Rouyer, IEEE 802.1 Vice Chair,   


David Law, IEEE 802.3 Chair,    

Adam Healey, IEEE 802.3 Vice Chair,   
 

 

From:

Lincoln Lavoie
Broadband Forum Technical Committee Chair   
  

 

Liaison Communicated By:

Ken Ko

Broadband Forum Managing Director   


 

Date: 8th June 2023

 

Subject: For Information: New Project for Addressing ONU Management at Scale

 

The Broadband Forum Fiber Access Networks (FAN) Work Area recently agreed to 
initiate a new project for the optimization of management of Optical Network 
Units (ONU) at scale. This project, called WT-505: ONU Management at Scale, is 
intended to be an enhancement of the existing specification, TR-385: ITU-T xPON 
YANG Modules. The following describes the issues and considerations that led to 
the need for the new project.

 

In contrast to many other transport technologies, a single PON interface can 
multiplex as many as 128 ONUs. It is also typical for a single Optical Line 
Termination (OLT) to contain many such PON interfaces.  

 

At this level of dimensioning, the OLT YANG modeled configuration data becomes 
very large due to the high number of ONUs to be managed. With current TR-385 
and TR-383 Broadband Forum YANG models, the management of large OLTs suffers 
severe performance degradation. Examples of such degradation are:

*   Time to validate YANG constraints when configuring ONU data nodes 
(e.g., due to very large OLT interface and hardware component lists)

*   Time to delete an ONU (time to retrieve all data nodes of the ONU)

*   Time to perform a  of a full OLT configuration.

 

Many Broadband Forum contributions have been submitted and discussed that 
demonstrate ONU management needs to be optimized to keep the OLT manageable. It 
has been determined that efficient optimization of ONU management requires the 
following measures: 

*   Collocate ONU data nodes per ONU, rather than have them interleaved 
with OLT data nodes (e.g., in the same interface or hardware component list) as 
per TR-385. This involves defining a list of ONUs in the OLT where each ONU 
entry contains all ONU data nodes.

*   Bring a strong reduction of the configuration data size per ONU. This 
will be achieved using ONU templates combined with the use of shared ONU 
profiles.

 

IETF schema mount was considered as a solution for collocating ONU data nodes. 
There were drawbacks to this approach, however. The size of the datastore was 
not improved as the same data nodes are mounted per ONU. There is also a known 
lack of tooling that supports schema mount making it difficult for this 
solution to be broadly implemented in a timely manner. The following 
alternative has been agreed upon.

 

Complement current standard YANG models with new models that implement 
optimization measures 

[netmod] Broadband Forum Liaison concerning: New Project for Addressing ONU Management at Scale

[David Sinicrope]

Hi All,

As noted during the NETMOD session today, the BBF has sent a liaison 
regarding their new project for Addressing ONU Management at Scale.


While not yet posted to IETF Statements 
, the liaison has the content 
below and as noted in the meeting today, should have a response.


In the coming days, I'll be drafting the response on behalf of the 
Chairs. Input is welcome.


Please let me know if you have questions

Thanks,

Dave Sinicrope
IETF Liaison Manager for the Broadband Forum



From the Chair's slides:

Liaisons and Communications

Incoming:
– From:Broadband Forum
– Received: 2023-03-09
– Title: New Project for Addressing ONU Management at Scale
– The Broadband Forum Fiber Access Networks (FAN) Work Area recently
agreed to initiate a new project for the optimization of management of
Optical Network Units (ONU) at scale. This project, called WT-505: ONU
Management at Scale, is intended to be an enhancement of the existing
specification, TR-385: ITU-T xPON YANG Modules. The following describes
the issues and considerations that led to the need for the new project.
– See list for attachment

Liaison content:


*Broadband Forum Liaison To: *

Kent Watsen, IETF NETMOD WG Co-Chair, 

Lou Berger, IETF NETMOD WG Co-Chair, 

Scott Mansfield, ITU-T Q14/15 Rapporteur, 

Liping Chen, ITU-T Q14/15 Associate Rapporteur, 

Paul Nikolich, IEEE 802 Chair, 

Glenn Parsons, IEEE 802.1 Chair, 

Jessy Rouyer, IEEE 802.1 Vice Chair, 

David Law, IEEE 802.3 Chair, 

Adam Healey, IEEE 802.3 Vice Chair, 

*From:*

Lincoln Lavoie
Broadband Forum Technical Committee Chair 

*Liaison Communicated* *By:*

Ken Ko

Broadband Forum Managing Director 

*Date:* 8^th June 2023

*Subject:* For Information: New Project for Addressing ONU Management at 
Scale


The Broadband Forum Fiber Access Networks (FAN) Work Area recently 
agreed to initiate a new project for the optimization of management of 
Optical Network Units (ONU) at scale. This project, called WT-505: ONU 
Management at Scale, is intended to be an enhancement of the existing 
specification, TR-385: ITU-T xPON YANG Modules. The following describes 
the issues and considerations that led to the need for the new project.


In contrast to many other transport technologies, a single PON interface 
can multiplex as many as 128 ONUs. It is also typical for a single 
Optical Line Termination (OLT) to contain many such PON interfaces.


At this level of dimensioning, the OLT YANG modeled configuration data 
becomes very large due to the high number of ONUs to be managed. With 
current TR-385 and TR-383 Broadband Forum YANG models, the management of 
large OLTs suffers severe performance degradation. Examples of such 
degradation are:


·Time to validate YANG constraints when configuring ONU data nodes 
(e.g., due to very large OLT interface and hardware component lists)


·Time to delete an ONU (time to retrieve all data nodes of the ONU)

·Time to perform a  of a full OLT configuration.

Many Broadband Forum contributions have been submitted and discussed 
that demonstrate ONU management needs to be optimized to keep the OLT 
manageable. It has been determined that efficient optimization of ONU 
management requires the following measures:


·Collocate ONU data nodes per ONU, rather than have them interleaved 
with OLT data nodes (e.g., in the same interface or hardware component 
list) as per TR-385. This involves defining a list of ONUs in the OLT 
where each ONU entry contains all ONU data nodes.


·Bring a strong reduction of the configuration data size per ONU. This 
will be achieved using ONU templates combined with the use of shared ONU 
profiles.


IETF schema mount was considered as a solution for collocating ONU data 
nodes. There were drawbacks to this approach, however. The size of the 
datastore was not improved as the same data nodes are mounted per ONU. 
There is also a known lack of tooling that supports schema mount making 
it difficult for this solution to be broadly implemented in a timely 
manner. The following alternative has been agreed upon.


Complement current standard YANG models with new models that implement 
optimization measures for the data nodes applicable to ONU devices. 
These current models are found in Broadband Forum standards, e.g., 
TR-355, TR-383, TR-385, and standards from other organizations, e.g., 
IETF, IEEE, ITU-T.


This involves:

·Deriving from existing standard modules, the development of modules 
defining a list of ONU templates.


·Deriving from existing standard modules, the development of modules 
defining a list of ONU instances, where each instance refers to one or 
more ONU templates and gives the possibility to complement or overrule 
any data originating from templates.


·Deriving from existing standard modules, the definition of modules 
defining ONU profiles that can be shared between ONUs templates and 
instances. ONU profiles should be distinct from OLT profiles to allow 

[netmod] yang with relaxed versioning

[Jürgen Schönwälder]

Hi,

to demonstrate how a minimal solution allowing limited non-backwards
compatible changes can look like, I have posted the following internet
draft:

https://datatracker.ietf.org/doc/draft-schoenw-netmod-yang-relaxed-versioning/

There are details missing but I am positive that everything necessary
can be written down using ~15 pages (in the old style text format).
For the reasoning behind this approach, see my blog posts.

https://www.beadg.de/js/post/yang-versioning-update/

/js

-- 
Jürgen Schönwälder  Constructor University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod