Call Agendas and Minutes - FTTdp

Opening Session Led by:

Agenda as modified was agreed.

Meeting minutes

2016.583,  2016.584, 2016.613, 2016.614,2016.629, 2016.632 and 2016.637 approved.

Liaisons

2016.704 - RPF Managed Objects draft for G.997.2

Latency question is perhaps more Architecture related. Liaison was briefly reviewed.

AP - Jan Errygers (Commscope) agreed to look at the ETSI liaison.

Will be reviewed in detail during the joint session.

2016.705 - Managed objects used by the DPU rather than used by the PMA.

Question around where the state machine would run as the expectation would be that it would be the DPU running the state machine rather than the PMA.

Relating to the software image of the G.fast DPU.

Mauro - question on if the code to that goes to the unit is the full code or separate for the different parts of the DPU. It would be the entire DPU code.

Reviewed in the joint session tomorrow.

2016.867 - SELT in g.fast deployment

Mainly for PhyTX. Expectation to cover in the joint session, but there is a wish to have a teleconference to cover if needed before the next SG15/Q4 meeting.

Update on YANG on WT-355 / WT-371

YANG Models Advice to not to include specific revision dates. - Removed the revision dates Mike has some concerns especially over when we have test specifications we will need revision dates. If we don't, then we have a moving goalpost. Ken - think it is simpler. Just use the version by the supported The module has a specific revision date. It is about how the modules reference each other. All this is doing is removing from the modules itself the versions of the other modules. Always inside the module, but filename will have revision date on the file. So where are we removing the date from - If we have module A wanting to inport Module B, then rather than importing a date specific version, it will just pick up the latest version.  

The Revision date of each individual file will be set to 18th July 2016 (Date of FB approval). The Revision comment to reference the approval will have the approval and publication date. The BBF URL will be added as part of the "organisation" statement

The organisation statement was shown to the group

Any objections to the above changes - None

Software IPR

The New IPR policy is now in force from 24th June. There is a requirement that before submitting any contribution of software/ data models the form in Appendix A of the IPR policy needs to be filled in. DIscussion for having it apply to an individual or all memebers of a company and if it applies to just a project or multiple projects or various grouping of. The policy is in force and there is a short grace period and any such contributions will be discussed but it is a requirement of the author to ensure the form is filled in retrospectively.

What happens at this meeting? - We proceed as normal at present.

There is a webpage that shows who has filled in the form.

Update on FTTdp management interop project stream OD-374

Next steps on FTTdp management interoperability

The FTTdp management interop PS started a long time ago, but we have had no contributions apart from an outline framework. This is expected as we haven't had the management models available. Now the modules are published there is better ground to publish the test plan.

Mauro mentioned that he would like to go a little further than just that and have a look at the opportunities for the BBF to get into the NETCONF/YANG testing. The is an opportunity for working on the test plan and working on DPU-PMA test plan with a common part about the parts that are common and can be reused. e.g. NETCONF channel establishment. It could also help in stating how we do tests for SDN enabled devices. We could have a double stimulus to work on this and enable reuse within other projects.It could also be abstrated away from the PMA and DPU.

The PMA tends to be provided from the same vendor as the DPU as a piece of software that will run in some virtualised environment. This removes some of the pressure for the interop becuase of this bookending. The point of the DPU-PMA YANG model is to drive the interoperability.

We are also looking to drive the NBI interface from the PMA which is key to the operator.

There was a comment that there is nothing wrong with this approach if there are common items, but as we haven't had any work on it so far, then let's not try to add lots of additional work to do.

It was seen that there is value in broadning the scope to take into account the some of this commonality, but we need to identify the expertise to help contribution. It may be that we start with the expertise within the FTTdp area as this is where the focus is at the moment and then potentially expand.

AP - Chris & Sven : Make Michael Fargano aware of this point.

There will be parts in the DPU session establishment that are specific 301 items, but there could be standards just for opening the session.

AP - Christopher Croot & Sven Ooghe: Request to stimulate the discussion at the SC level.

AP - Christopher Croot - Request the secretariat to create the OD-374 document on ARO

301i2 - WT review latest version - Presented by Mike Shaffer

The latest version of the WT was presented and the updates to 301i2 between Prague and this meeting were shown. The revision was accepted as presented.

Issues list - presented by Dong Wei

The latest version of the issues list was presented and the updates were shown. The latest revision was accepted as presented.

General WT-301i2 Discussion 

We have spent a long time preparing Issue 2 and we have a spreadsheet with the items that we considered important - bbf2015.1126. Within this all the items that we have done are marked green. Those in yellow have been started and those left as white have not been started. We still have quite a few topics that are marked as 1st priority items but have not yet been started.

One item that has been added was a suggestion that a requirement to use the YANG models as described in 355 should be added into 301i2. This was supported by the group.

There is a wish to wrap up the current issue as quickly as possible and we need to get folks to pick up those items that need completing and drive them through. Even if we just covered the yellow items.

Timescales for completion of the issue were discussed and it was agreed to aim for an agreed SB version out of the Q4 meeting so that we would be doing SB CR in the Q1 2017 meeting. We would need several interim teleconferences to pick up the requirements with an expectation to get the owners of the items in the spreadsheet covered. 

AP - Sven Ooghe & Christopher Croot to send an email to the exploder detailing the agreed timescales and call to complete the open topics

There were 12 people attending the session :

Ken Kerpez, Assia Inc.

Sumithra Bhojan, AT&T

Christopher Croot, BT

Marcin Drzymala, Orange

Jan Erreygers, CommScope

Andreas Frangou, Cyta

Thomas Haag, Deutsche Telekom A/G

Shrinivas Joshi, Nokia

Lincoln Lavoie, UNH InteOperability Lab

William Lupton, BBF

Sven Ooghe, Nokia

Marta Seda, Calix Networks

Mike Shaffer, Nokia

Mauro Tilocca, Telecom Italia S.p.A

Dong Wei, Huawei

Sven Ooghe

William Lupton

Lincoln Lavoie

Mauro Tilocca

Mike Shaffer

Dong Wei 

 Led by:

Liaisons

bbf2016.704 - Frank Van der Putten presented

This is a liaison from Q14/15 referring to the RPF OAM. Q4 has been sending liaisons and received 2 from ETSI on RPF specification. The 1st version has now been approved. This has been communicated to Q4/15 and agreed a while ago to include the managed objects derived from the ETSI document in G.997.2.

There was agreement to create Annex A to G.997.2. The goal is to consent this by the end of Sept and the liaison attached the current WT. Asked for review and comments by TM6 and /or BBF. Few questions in response to ETSI in response to latency.

Latency between DPU and PMA don't think ETSI is the correct place to answer. Also question of ETSI TM6 from RPF that require low latency. Two listed the dying gasp & OHP technical study required to validate the latency.

We are asked to answer the question on DPU/NTE latency. The feeling is that this is a Q4 question down to EOC. The DPU to PMA latency question is unclear. The following actions were agreed:

AP - The FTTdp WA will need to use the Annex A material to start producing the YANG models for the RPF OAM.

The DPU - PMA latency is seen as an irrelevant question

The latency on dying gasp are currently under study in Q4

There are no further actions for the liaison at this time.

 Dong Wei

Les Brown

Led by:

Mike Shaffer

 Mike Shaffer

Led by:

WT-355 YANG Modules for FTTdp Management

 William Lupton made the announcement about the software contribution agreement. We want this to be in place before the first interim meeting.

Contributions considered today will go into WT-355 Amendment 1 (WT-355a1). Note: there was some discussion of whether this should be Amendment 1 or Issue 2 but subsequent discussion seemed to assume Amendment 1.

bbf2015.511.13: (TR-355) YANG Modules for FTTdp Management

Plan to publish the YANG to public GitHub next week. There is some minor clean-up, e.g. adding publication dates and README files.

We will continue to use the WT-355 repository for WT-355a1. We need to define branch rules for maintenance etc.

We need to create a WT-355a1 document. See bbf2016.819.00 discussion below.

bbf2016.677.00: PMA requirements for interference handling (China Telecom)

Some discussion of what is meant by "interference". There are existing statistics such as quiet line noise, but is this going beyond this? Yes, it's a high-level requirement.

The PMA can't itself detect interference, so would also need a DPU requirement to detect interference, then report to PMA, then report northbound. Suggestion to add a PMA NBI requirement, e.g. for an alarm, and request re-contribution to propose adding such a requirement.

bbf2016.752.02: G.Fast Bonding Management (Calix)

Reiterated yesterday's Common YANG alarm discussion in which it was agreed to work on alarms in IETF. The alarm module should be removed from this contribution and any gaps should be addressed via the IETF alarm work.

Discussion of the proposal to increase the maximum fragment size. The ITU-T standard still says 512 so it shouldn't be increased.

Discussion of why the proposal is specific to G.fast. It should work for VDSL too. Also, it currently supports only BACP, and needs also to support G.hs.

Discussion of whether DPU bonding requirements should be in WT-301 or WT-355. Although there are arguments for including it in WT-301 it's easier to add such requirements to WT-355 because WT-355 updates will be synchronized with DPU YANG updates.

Discussion of the nature of alarms. An alarm can be a leaf node that represents an error, a YANG notification, or handled via the alarms module. Can return to this as part of the generic alarm discussion.

As a specific point, 64/65 encapsulation isn't defined for G.fast, so it needs to be part of the VDSL model.

AP - Marta Seda - Remove the alarm module, remove alarms that use it, and make the bonding model generic (adding G.hs and using YANG features where appropriate); also remove the WT-301 requirement.

bbf2016.779.00: State Change Principles (Nokia)

Clarified that (slide 4) notification types are:

1. Notifications handled via the alarm module.
2. Notifications handled via NETCONF system events (relevant only if have multiple NETCONF clients).
3. Notifications handled via YANG notifications (indicating command completion).
4. Notifications handled via YANG notifications (indicating asynchronous events).

Reiteration that the YANG push work (including RFC 5277bis) is relevant for the Common YANG PS but not for the FTTdp Management PS. [Ed: this was agreed in Prague when discussing contribution bbf2016.472..: Bulk Counter Collection]

bbf2016.819.00: Precision on YANG module support by DPU (Orange)

AP - WT-355 editors - Create a WT-355a1_Rev-00 that includes this info.

bbf2016.821.00: YANG module for DPU identification on PON (Orange)

Discussion of whether the SFP serial number? note that the PON termination module has gone

Discussion of whether this (very small) module could be combined with another module. For example, could have a PON up-link model. Would need to think about the eventual structure so it's future-extensible.

AP - Contributors - Define a bbf-pon-id module that augments ietf-interface (will need to add the when clause later).

Ken Kerpez

Marta Seda

Joey Boyd, Ken Kerpez, William Lupton

Orange

Led by:

bbf2016.824.00: Persistent Management Agent Aggregator (PMAA) Management Model (Orange, TI, ASSIA)

To avoid confusion about which interface is being referred to, it would be better to talk in terms of the Q reference point, which is the reference point northbound of the PMAA.

Discussion of the need for abstraction and aggregation on this interface. YANG schema mount was mentioned as one way of handling aggregation (to support pass-through). More abstract models could be in addition to this, e.g. to define a higher-level concept of profiles.

Discussion of the "MUST re-use WT-355" requirement. This is too prescriptive at this stage and will be changed to "MUST leverage the WT-355 design".

WT-393 has been assigned, and the editors are Ken Kerpez and Joey Boyd.

AP - Ken Kerpez - Make changes arising from discussion and upload as WT-393_Rev-00.

Ken Kerpez

Ken Kerpez

 Led by:

Reviewed the WA closing plenary slides.

WT-298 needs to have a call to discuss going to SB

AP - Sven Ooghe & Christopher Croot to e-Mail Marco on 374 to get dates he can do and pass to doodle poll

Sven Ooghe

Session opened at 13:35

Called to close 13:55