[Pce] New Liaison Statement, "Response to 18 Dec 2016 liaison concerning: Achieving Packet Network Optimization using DWDM Interfaces"

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

Title: Response to 18 Dec 2016 liaison concerning: Achieving Packet Network Optimization using DWDM Interfaces
Submission Date: 2016-02-02
URL of the IETF Web page: https://datatracker.ietf.org/liaison/1454/

From: "David Sinicrope" <[e-mail]>
To: [e-mail]
Cc: Alvaro Retana <[e-mail]>,Deborah Brungard <[e-mail]>,Julien Meuric <[e-mail]>,David Sinicrope <[e-mail]>,Jonathan Hardwick <[e-mail]>,Fatai Zhang <[e-mail]>,Path Computation Element Discussion List <[e-mail]>,Traffic Engineering Architecture and Signaling Discussion List <[e-mail]>,Vishnu Pavan Beeram <[e-mail]>,Alia Atlas <[e-mail]>,Daniele Ceccarelli <[e-mail]>,Lou Berger <[e-mail]>,Common Control and Measurement Plane Discussion List <[e-mail]>,JP Vasseur <[e-mail]>,
Response Contacts: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Technical Contacts: 
Purpose: In response

Referenced liaison: Achieving Packet Network Optimization using DWDM Interfaces (https://datatracker.ietf.org/liaison/1449/)

Body: 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 work.

Sincerely,
TEAS, PCE and CCAMP WG Chairs
———
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 side).

* 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 casess.

* 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” (https://tools.ietf.org/html/draft-kdkgall-ccamp-dwdm-if-mng-ctrl-fwk-01)
* 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 Channel).
* 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 4.3.2.1
Attachments:

No document has been attached