Liaison statement
Response to 18 Dec 2016 liaison concerning: Achieving Packet Network Optimization using DWDM Interfaces

State Posted
Posted Date 2016-02-02
From Groups ccamp, pce, teas
From Contact David Sinicrope
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
Purpose In response
Attachments (None)
Liaisons referred by this one Achieving Packet Network Optimization using DWDM Interfaces
The TEAS, PCE and CCAMP Working Groups would again 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 IETF RFCs. As offered, we have conducted a more in depth review
on the revised draft you provided in your liaison on 18-Dec-2015. Please find
the comments and feedback below for your consideration. If you have any
questions or concerns, please feel free to contact the respective WG Chairs,
or send email to the respective WG email lists.
Also please keep us informed of any gaps you identify in the RFCs that are
needed to satisfy the requirements in your specifications. Your feedback is
greatly appreciated and can also be provided via the relevant IETF WG email
list without the need for a formal liaison.

We look forward to our continued communication on this important area of

Comments and feedbacks received from WG participants:

* In WT-319 Part-B is mentioned the fully separated solution while in TR-319
the fully integrated DWDM interface in the client equipment.

* The two solutions can signal on the UNI interface different service request
(Ethernet or OTN in the former, optical channel in the latter)
* It would be nice to see also the Hybrid solution to be supported (i.e. Fully
integrated on one side of the circuit and fully separated on the other

* Although are not yet published as RFC there are two drafts that may be
relevant and have been submitted for publication to the IESG:

* RSVP-TE Extensions for Collecting SRLG Information,
draft-ietf-teas-rsvp-te-srlg-collect . This draft supports the collection of
LSP SRLGs in the core and sharing the list to the Edge.
* Domain Subobjects for Resource ReserVation Protocol - Traffic Engineering
(RSVP-TE), draft-ietf-teas-rsvp-te-domain-subobjects. Which extends inclusion
and exclusion semantics in a way that is likely to be of interest to BBF use

* The usage of SNMP for the network provisioning and deployment should be
discouraged. In addition to that existing RFCs do not cover the provisioning
of the colored side of an optical interface. Yang models to provision colored
interfaces have been submitted to the IETF but have not been accepted yet,
however the CCAMP WG is in the process of starting the adoption process of “A
framework for Management and Control of DWDM optical interface parameters”
* the level of details does not look consistent along the text, e.g.:
- for RSVP-TE, LSP encoding/SC/G-PID are specified, but the label itself is
limited to "the Generalized Label represents a generic MPLS label", where the
last phrase puzzles me, especially in this context of DCSC;
- LMP is mentioned, but considering the number of feature it can bring, I
would expect a bit more about it;
- about PCEP: it is required in section 4.2 but its use is not defined; it is
also mentioned in section 4.4 along with SDN, but the appropriate reference
should include "draft-ietf-pce-stateful-pce" on top of RFC 5440, and possibly
even "draft-ietf-pce-pce-initiated-lsp".
* Just a suggestion: It would be nice not to limit the Client interface (Dd)
to Ethernet or OTN. Also Data center interfaces may be supported (like Fiber
* I note that you are stating that RFC2205 format TSPEC and FLOWSPEC are to be
used. I recommend using RFC6003 Ethernet Traffic Parameters for LSPs carrying
Ethernet Services, e.g., such as those discussed in RFC6004, and RFC7139 G.709
OTN TDM Traffic Parameters for LSPs carrying OTN Services.
* Page 17, r-14. Does this requirement mean RFC3209 is used as a foundation to
R-15 or that RFC3209 is used to signal the LSPs? If the former, the
requirement is unnecessary and misleading and should be dropped. If the
latter, this is inconsistent with signaling Ethernet or OTN GMPLS LSPs.
* R-17, the specific required timers should be identified.
* Message ID and reliable delivery defined in Rfc2961 are supported by GMPLS
implementations. You may wish to make this a recommendation or requirement.
* You may wish to add that RESCONF is for further study at the end of section