Liaison statement
In Response to Broadband Forum Liaison: Achieving Packet Network Optimization using DWDM Interfaces

State Posted
Posted Date 2015-12-02
From Groups ccamp, pce, teas
From Contact Daniele Ceccarelli
To Contacts
CcAlvaro Retana
Deborah Brungard
Julien Meuric
David Sinicrope
Jonathan Hardwick
Fatai Zhang
Path Computation Element Discussion List
Traffic Engineering Architecture and Signaling Discussion List
Vishnu Pavan Beeram
Alia Atlas
Daniele Ceccarelli
Lou Berger
Common Control and Measurement Plane Discussion List
JP Vasseur
Response Contact Vishnu Pavan Beeram
Lou Berger
Jonathan Hardwick
JP Vasseur
Julien Meuric
Fatai Zhang
Purpose In response
Attachments (None)
Liaisons referred by this one Achieving Packet Network Optimization using DWDM Interfaces
Achieving Packet Network Optimization using DWDM Interfaces

The TEAS, PCE and CCAMP Working Groups would like to thank the Broadband Forum
for informing us of your effort on packet-optical networks, and providing the
IETF with the opportunity to review and comment on your document and its use
of our RFCs.

We have conducted an initial review where we noted the references to IETF RFCs
on GMPLS and PCE for satisfying the control requirements.

Below is some preliminary feedback based on this initial review we hope you
will find helpful and consider for the document. However, given the recent
IETF 94 meeting activity, we regret there was little time to conduct a
thorough technical review of the document. We understand the document is in
the last call stage of development. If time and the BBF process allows, the
CCAMP, PCE and TEAS Working Groups would be happy to conduct a more in depth
technical review over the coming weeks. Please let us know if you wish us to
proceed with such a review.

As the Broadband Forum progresses its work on "Achieving Packet Network
Optimization using DWDM Interfaces", we would greatly appreciate if you keep
us informed of any gaps you identify in the RFCs that are needed to satisfy
these requirements. Feedback from the BBF on existing and progressing CCAMP,
PCE and TEAS work would be greatly appreciated and can be provided via the
relevant IETF Working Group mailing list without the need for a formal

We look forward to your response and our continued communication on this
important area of optical networking.

Best Regards,

Daniele Ceccarelli & Fatai Zhang - CCAMP Working Group Chairs
Jonathan Hardwick, Julien Meuric & Jean-Philippe Vasseur - PCE Working Group
Vishnu Pavan Beeram & Lou Berger - TEAS Working Group Chairs

Preliminary Feedback



* In A.2.1, how is the GMPLS communication between the Packet Node and the
DWDM Network Element achieved? Is there a specific control interface that is
used in your solution? There are a number of possibilities for control channel
connectivity available. Perhaps clarifying which are intended would aid
understanding and interoperability.

* Are there more details on the management and SDN control aspects between the
packet network and the optical network? Additional management and SDN control
detail might convey a better understanding of the solution configuration and
its operation.


* When referring to PCE and related issues, e.g., in [R-26] and [R-27], it
seems only stateless PCE (RFC4655) and corresponding PCEP (RFC5440) are
included in the current solution. The PCE Working Group is investigating
stateful PCE and PCE Initiated LSPs, which are planned to be published in the
future. It may be worth specifying which kind of PCE is suggested to be used
in the current solution, to differentiate the two. Has RFC 5623 - PCE-based
inter-layer MPLS and GMPLS Traffic Engineering been considered? It may be a
good reference for this solution.

* In section 4.4 when talking about SDN, Openflow is mentioned as a standard
protocol to interact between packet nodes and DWDM nodes. PCE Protocol (PCEP)
could be considered as another example, as it is currently used in IETF. RFC
3413 about SNMP, and RFC 4208 about GMPLS UNI are also recommended

* In section 4.5, [R-36] uses the term "North-Bound interface" to refer to the
interface between Network Elements and the SDN controller. We noted that some
commonly use the same term when referring to the interface between the
controller and what sits "above" the controller (e.g. another controller or
orchestrator). This could lead to unintended misunderstanding. Perhaps a
clarification would help avoid misunderstanding.