Minutes IETF104: bcause
minutes-104-bcause-00

BNG Control-plane And User-plane SEparation (BCAUSE) BoF Meeting
IETF-104, Prague
Tuesday, March 26th, 11:20 - 12:20
==========================================
Area Director : Martin Vigoureux (martin.vigoureux at nokia.com)
Chairs: Barbara Stark (bs7652 at att.com), Adrian Farrel (adrian at
olddog.co.uk) Notes: Mach Chen, Dave Allan, Tim Carey, et al (on Etherpad)
Jabber (bcause@jabber.ietf.org): Daniel King
==========================================
1. Admin (chairs) [5 : 5/60]
Adrian presented:
https://datatracker.ietf.org/doc/slides-104-bcause-chairs-slides/02/
==========================================
2. Purpose and aims of the BoF (AD) [5 : 10/60]
Martin Vigoureux presented from slide 7 of the chair slides.
Focus on requirements independent of solution advocacy. Too soon to have a
charter discussion.  This is a multi-SDO situation.  Barbara (co-chair's)
opinion has no more or no less weight than anyone else participating.
==========================================
3. Questions to address in the BoF (chairs) [5 : 15/60]
Continuing with slides 8 and 9 of chair slides.
Adrian: reference to RFC 5434 on BOFs.  Provided a list of questions to be
addressed. Will come back to topic after presentations
==========================================
4. Use cases for deployment
-------------------------------
   a. What would China Mobile like to achieve? (Fengwei Qin) [10 : 25/60]
China Mobile view:
    Currently main requirements are on fixed network BNG. CMMC has 1000+ BNGs
    and over 150 million residential subscribers. Very rapid growth rate for
    deploying BNG and BRAS equipment. Most subscribers are GPON with others
    EPON. Noted challenges include inefficient address management; unbalanced
    session management (CP) and capacity load (UP); interfaces with neigboring
    systems are complex; inflexible software upgrade for BNG. Desired
    Disaggregated BNG is to separate control and user plane. This addresses the
    noted challenges. Investigation was carried out since 2017 with PoC and
    field trial practices Wide DBNG deployment in 2019 and 50% legacy BNG (150m
    subscribers) will be upgraded to DBNG in the comming years. With VNF-CP +
    hybrid UPs, better performance is achieved and service provisioning is
    substantially simplified. Deployment timeframe is tight; there is a need
    for a standard for multi-vendor interoperability to support mass
    deployment; want CUPS to be standardized in IETF.
Adrian: Asked if there were any questions for clarification: No questions from
the floor
-------------------------------
   b. What would AT&T and DT like to achieve? (Dirk von Hugo) [10 : 35/60]
   Common infra layer supports wireline, mobile etc. with general hardware.
   Significant legacy support requirements to be addressed.
    Should support native Ethernet access and 3 types for Metro Ethernet
    services Deployed as rack-n-roll POD Noted there is an urgency to
    deployment Noted that OSS/BSS/Dbs wont change at outset Working on PoCs and
    prototypes Everything is open source with NFVI with SDN Merchant silicon
    enriched with compute and storage
Adrian: Asked if there are questions for clarifications.
Person in the room: What is a POD?
Dirk: It's a single unit.
==========================================
5. BBF work plan and methods (David Sinicrope) [10 : 45/60]
Dave explained his role here is the IETF liaison manager to the BBF.
Noted that the BBF has significant list of work related to BNG: provided a list
of TRs. Explained new work in the BBF with WT-459 "Disaggregated BNG" as well
as WT-458 "CUPS for 5G FMC functions". Noted the BBF and IETF communications on
this topic dating back to March 2018. Several liaisons have been exchanged
between IETF and BBF. Hope people read all 4 liaisons. Links between liaisons
are broken, Dave S. working with the secretariat to address. BBF is normally
restricted to members. Datamining of the Bcause list shows all but two
participants can be associated with BBF member companies. The affiliation of
the other two is not obvious from the email address. Noted the differences in
working between the BBF and IETF and how work that comes from the BBF, since it
is a private member organization, is liaised. There have been numerous liaison
exchanged in the past. Noted that the work in IETF is by the IETF process and
in the BBF by the BBF process. Provided information on how the IETF individuals
can communicate to the BBF:  1) as part of the member companies, or 2) through
the liaison process if not a part of a BBF member. Ning Zong:  TR-384 is latest
(published document) dealing with CO-separation. Sri Gundavelli:  In the
context of this work, are there specific technical problems. My employer
suports such schemes. Is the problem to be solved the controller to user plane
communication? David: You are asking the wrong guy!  There are many documents
in BBF related to this. As for actual problem statement, material being shown
here (in IETF, in contributed IDs) is similar to what is being shown
(contributed) at BBF. Brian Trammel (wearing IAB liason manager manager manager
hat):  Would the context of any cooperative work be based on TR-384 or go
beyond that. David: WT-458/459 should be considered. If work in IETF was to
progress it would be likely chartered around these items. Brian: How does this
fit in relation to milestones? David: BBF is trying to hit the advertised
dates. Sanjay Wadhwa:  TR-384 just defines the concept, does not capture
requirements. Simply a clarification. Adrian:  The IETF sometimes does joint
work with other bodies, in a more day by day basis than can be supported by a
liaison process. Such as joint interim meetings. David: Cannot answer that. 
There are projects that involve non-members.   There is coordination,
cooperation, collaboration. Collaboration is problematic.  Implies a joint
deliverable, and involves lawyers.  I recomment staying away. Dan Druta:  It
makes no sense to do swivel chair. David: What has happened in the past is the
BBF did the architecture and equipment requirements.  Usually identifies a
protocol and mandatory optional status. BBF has tended to re-use existing work,
and then sought to fill gaps, and where practical define extensions.  Also have
defined protocols (e.g. TR-69).  Also addressed gaps in data modelling.  BBF
makes decisions by consensus.
==========================================
6. Questions to shape our work (chairs and discussion) [12 : 57/60]
Parviz Yegani: This is not new, done it many times. The requirement for BBF can
come here, nothing new, well established process in place. Wim Henderickx:
Several operators have made requests, different deployment models but desire
for a similar solution. Need to look at all of them.  BBF has the knowledge,
IETF does not have this. BNG does not exist in IETF terminology. Better off to
focus efforts in BBF.   There are people in a hurry, so we should focus energy
in a single SDO. This would better serve the industry. Erik Nordmark:  No
feedback, since you were not proposing anything. This feels extremely nebulous.
It is not defined, with a cumbersome inter SDO interface. Jeffery Zhang: 1st
point is that the decision should be to do multi-access BNG. Second point:
prefer the work to be fone in BBF, more expertise there. Sanjay: IETF should
wait to receive the requirements from BBF. Greg Mirsky: We have two individual
documents in IETF about the requirements. Requirements are identified already.
Don't see the problem. IETF has the expertise. The timeframe of the operator is
urgent. Deigo Lopez: Focus on common access. General problem statement to deal
with access nodes fits well here. Dan Druta: BBF to start requirements, then
define protocols here. Ning Zong: Concerned about the wait; noted the overlap
in membership; noted that BBF doesn't object to the work. Wen Lin: Agreed with
Wim and noted that the speed to completion. Dave Allan: BBF WWC Work Area
director. Noted the Wireline/Wireless work and noted the smooth working
relationship with 3GPP and noted WT-458 is dealing with FMC CUPS. Noted there
isn't a need to for additional help, and a concern that the nature of the work
may result in mulitple solutions to the same problem, which would be bad for
the industry. 7. Wrap up (chairs/AD) [3 : 60/60] Martin/AD: Heard following
point:
    Tendency to prefer BBF complete this work on requirements.
    Understands waiting is not really an option in some cases: but 3Q isn't
    that far off. Will take the input and get back to the participants on the
    list.