Skip to main content

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

Additional information about IETF liaison relationships is available on the IETF webpage and the Internet Architecture Board liaison webpage.
State Posted
Submitted Date 2016-02-02
From Groups ccamp, pce, teas
From Contact Dave Sinicrope
To Group BROADBAND-FORUM
To Contacts michael.fargano@centurylink.com
Cc Alvaro Retana <aretana@cisco.com>
Deborah Brungard <db3546@att.com>
Julien Meuric <julien.meuric@orange.com>
David Sinicrope <david.sinicrope@ericsson.com>
Jonathan Hardwick <jonathan.hardwick@metaswitch.com>
Fatai Zhang <zhangfatai@huawei.com>
Path Computation Element Discussion List <pce@ietf.org>
Traffic Engineering Architecture and Signaling Discussion List <teas@ietf.org>
Vishnu Pavan Beeram <vbeeram@juniper.net>
Alia Atlas <akatlas@gmail.com>
Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
Lou Berger <lberger@labn.net>
Common Control and Measurement Plane Discussion List <ccamp@ietf.org>
JP Vasseur <jpv@cisco.com>
Response Contact vbeeram@juniper.net
lberger@labn.net
jonathan.hardwick@metaswitch.com
jpv@cisco.com
julien.meuric@orange.com
daniele.ceccarelli@ericsson.com
zhangfatai@huawei.com
Purpose In response
Attachments (None)
Liaisons referred by this one Achieving Packet Network Optimization using DWDM Interfaces
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