[CCAMP] Proposed communication to OIF on Routing

["BRUNGARD, DEBORAH A (ATTLABS)" <[e-mail]>]

CCAMP,

We need to send a communication to OIF related to their two previous
communications to us on routing. Let us know if any comments on this
proposal.

Deborah and Lou

------------------------ Proposed Communication------------------
Subject: IETF CCAMP Response to OIF on Routing

Dear Lyndon,

In your October 22nd communication , you requested consideration of two
routing related drafts for CCAMP related to OIF testing.

On ASON Routing implementation experience
"draft-ong-gmpls-ason-routing-exper-00.txt":

This document was presented at November's meeting. While it is
re-affirming to hear that your development work and interoperability
testing confirmed the routing functionality defined in [OSPF-ASON], your
use of different sub-TLVs for the testing does not support the
transition of [OSPF-ASON] to standards status. Due to the lack of
community interest in testing and deploying ASON routing functionality,
[OSPF-ASON] was designated as IETF experimental status. If future OIF
testing is based on [OSPF-ASON], the discussion on transition of
[OSPF-ASON] to standards status could be revisited. On your request for
your defined extensions to be given IETF standards status, we remind you
of RFC4929:

"The definition and publishing of non-standard extensions by other
   fora, without IETF review, and outside of the IETF publication
   process, regardless if rationalized as limited to use among fora
   vendors, or limited to a particular application, or rationalized as
   allowing timely demos, has the unfortunate potential to hinder
   interoperability and increase complexity of the protocol, sows
   confusion in the industry, and circumvents the Internet standards
   process that exists to ensure protocol implementability.  As
   described in [RFC4775], non-standard extensions, including
   experimental values, are not to be portrayed as industrial standards
   whether by an individual vendor, an industry forum, or a standards
   body."

Specifically of concern, we note in your document, the definition of
alternative functionality for existing functionality. In section 3.2.1,
a new ISCD sub-TLV for advertising "compact" description of connection
availability is defined which is non-compatible with standard GMPLS.
And, in section 4.4, new sub-TLV is defined as an alternative to
[OSPF-Node] which was used in [OSPF-ASON]. You state as justification
(section 4.4):
"This tested format is functionally equivalent to the format defined
   in [OSPF-ASON] but is independent of the function of advertising
   local addresses of a router for MPLS TE LSPs as defined in
   [OSPF-NODE]."

Are you concerned on the use of a common set of procedures by MPLS and
GMPLS such that you believe the need to develop alternatives to ensure
independence in the advertising? It would be of benefit to the GMPLS
community if you would communicate these concerns so they could be
addressed properly before developing your own extensions. We recommend
that future OIF testing and related drafts be based on [OSPF-ASON]. This
would facilitate the alignment of OIF work with CCAMP produced RFCs.

On additional functions for ASON routing
"draft-theillaud-gmpls-ason-routing-add-fcts-01.txt":

The document was introduced at November's meeting and a discussion
thread was initiated on CCAMP's exploder on one of the requested
functionalities: link associated local connection type. The example
provided in Section 3.1 on the need to distinguish high-order and
lower-order VC-3s was discussed and it was concluded the functionality
is already supported:
http://www.ietf.org/mail-archive/web/ccamp/current/msg10716.html

You may want to review RFC4202 where this is described:
"A way to handle the case where an interface supports multiple
   branches of the SDH multiplexing hierarchy, multiple Interface
   Switching Capability Descriptors would be advertised, one per branch.
   For example, if an interface supports VC-11 and VC-12 (which are not
   part of same branch of SDH multiplexing tree), then it could
   advertise two descriptors, one for each one."

Section 3 of RFC4202 additionally provides multiple examples which may
be helpful.

The other proposed functionality, on layer-scoped link attributes, has
not been discussed and we welcome the authors of the draft to initiate
discussion on the CCAMP list.

In your July 23rd communication, you indicated the need to support NSAP
format in the advertisement of node local prefixes. We welcome your
members to submit a draft detailing the requested functionality. We also
direct you to a related discussion that took place in the context of the
L1VPN Working Group on November 9, 2005 as reported in
http://www.ietf.org/proceedings/64/l1vpn.html. Specifically:

Several questions were discussed:
- Is there a requirement to support NSAPs?
The mechanisms for embedding NSAP in IPv6 (RFC 1888) is now marked as
historic. We could bring this back alive simply by republishing, if we
need the function.
Question is whether we actually need the function.
- A poll of room showed slight interest in supporting NSAPs, and no
opposition. 
Since there is very low cost to supporting this it is easy, but we don't
usually do things without specific demand.

We encourage your members to participate in IETF's CCAMP email exploders
and the development of standards to prevent these misunderstandings in
the future.

Regards,
Lou Berger and Deborah Brungard
IETF CCAMP Working Group Co-Chairs