New Liaison Statement, "Follow-on response to IETF liaison: ‘Potential RTGWG work related to the disaggregated BNG architecture’"

[Liaison Statement Management Tool <[e-mail]>]

Title: Follow-on response to IETF liaison: ‘Potential RTGWG work related to the disaggregated BNG architecture’
Submission Date: 2019-03-07
URL of the IETF Web page: https://datatracker.ietf.org/liaison/1631/

From: Lincoln Lavoie <[e-mail]>
To: Chris Bowers <[e-mail]>,Jeff Tantsura <[e-mail]>,Alvaro Retana <[e-mail]>,Deborah Brungard <[e-mail]>,Martin Vigoureux <[e-mail]>
Cc: Deborah Brungard <[e-mail]>,Chris Bowers <[e-mail]>,Martin Vigoureux <[e-mail]>,Alvaro Retana <[e-mail]>,The IETF Chair <[e-mail]>,Routing Area Working Group Discussion List <[e-mail]>,Dave Sinicrope <[e-mail]>,Jeff Tantsura <[e-mail]>,Liaisons at Broadband Forum <[e-mail]>,Statements at IETF <[e-mail]>,Robin Mersh <[e-mail]>,April Nowicki <[e-mail]>,David Allan<[e-mail]>,George Dobrowski<[e-mail]>,Chris Croot <[e-mail]>,David Sinicrope <[e-mail]>
Response Contacts: 
Technical Contacts: 
Purpose: In response

Referenced liaison: Potential RTGWG work related to the disaggregated BNG architecture (https://datatracker.ietf.org/liaison/1615/)

Body: Dear colleagues,
 
In our initial response on December 17, 2018 to your 3 December 2018 liaison ‘Potential RTGWG work related to the disaggregated BNG architecture’ we informed you that we intended to complete the review of the drafts and communicate any comments to you by mid-February 2019. This response is the result of the review of the following architecture drafts:
•	draft-cuspdt-rtgwg-cu-separation-bng-architecture-03
•	draft-wadhwa-rtgwg-bng-cups-02

>From our review of the architecture drafts, we believe the following points would be relevant to further work by the IETF on the drafts:
•	In the scope of a protocol to address the separation of the control and user plane for a multi-service BNG we would like to:
        o	inform you that the primary nodal requirements for a multi-service BNG is defined in BBF TR-178 and the known examples are described in TR-384 for the disaggregated BNG 
                functions. In addition to these requirements, the BNG can be used in various multi-access deployments with additional capabilities, including integration into the BNG. These  
                additional capabilities with examples of deployment options are specified in TR-348, TR-378, TR-291, TR-300, TR-321.
      o	inform you of the deployment scenarios based on BBF's "V" reference point encapsulation and relevant protocols (e.g., MPLS PW, L2oGRE, L2TPv3) specified in the supporting 
                Broadband Forum Technical Reports (e.g., TR-101, TR-178 for Ethernet VLAN, MPLS PW).
      o	note that the architecture drafts that reference TR-384 (section 5.2.5) only addresses 1 of the 2 exemplary disaggregation options. Minimally both options within TR-384 for   
               disaggregation of a BNG should be addressed by the architecture.
      o	inform you that the BBF has started work on control and user plane separation for a disaggregated BNG that may include additional capabilities addressing various deployment 
                scenarios. (WT-459). 

•	We also have noted several items that to consider in order to improve the clarity of the work toward the audiences of the draft:
      o	 We would encourage the use of consistent terminology among drafts in order to avoid confusion.
      o	To help with alignment between the IETF / BBF, it would be helpful for the IETF to clarify what the CUPS function and protocol is addressing (problem or issue), or beneficially 
                providing so that so we can better understand and map the functionality to the different BBF BNG specifications. Without that clarity it makes it difficult to determine the inter-
                dependencies and impacts between the established BBF BNG specifications and any new function. For example. if CUPS were to become a functional requirement in a BBF 
                specification, the specification would need to understand what problem the CUPS function is addressing.
•	The Security Considerations sections in the drafts are inadequate and should be improved to discuss the security of communications between the CP and UP.
 
In addition, in our last response we noted that we were discussing our current work Wireline and Wireless Convergence (WWC) as it relates to the need for protocol requirements and specification for the separation of the control and user plane for disaggregated BNGs for fixed network subscribers. Recently, as part of our 5G Fixed Mobile Convergence (FMC) stream, we started a new working text WT-458 on “CUPS for 5G FMC functions”. This working text does not include CUPS for BNG. However, this is a work of interest, as one of the 5G convergence models redistributes existing BNG functions across the 5G core network and an Access Gateway Function (AGF). AGF is going through normative work at BBF and WT-458 will specify how the AGF control and user planes can be separated. The target completion date for WT-458 is Q3 2019. As highlighted in our previous liaison, our preferred direction is to leverage 3GPP’s PFCP protocol for CUPS on AGF. The feasibility of this is being verified as part of WT-458. Assuming a positive result and subject to 3GPP agreement, extensions needed to PFCP for AGF support will be done by BBF in direct consultation and cooperation with 3GPP.   We would be happy to keep RTGWG informed of our work status as it progresses.
As stated in our last liaison response we continue to welcome further coordination as the work of both organizations progresses on this topic.  


Sincerely,

Lincoln Lavoie,
Broadband Forum Technical Committee Chair
Attachments:

No document has been attached