RE: Stepping back from the ASON Routing Discussion

["Brungard, Deborah A, ALABS" <dbrungard@att.com>]

Agree, it would be better to separate and focus on the requirements first. Additional comments below. As I summarized below, the DT will redo the draft and limit to requirements only.
Thanks,
Deborah

-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On
Behalf Of Adrian Farrel
Sent: Tuesday, March 16, 2004 5:44 PM
To: ccamp@ops.ietf.org
Subject: Stepping back from the ASON Routing Discussion


Just stepping back a moment...

It feels to me that we are getting drawn into discussions of what can and cannot be
achieved using existing protocols. This is all very valid, but is clearly not part of the
requirements work.

I understand that the DT wishes to analyse the changes to existing protocols to meet the
requirements under the charter phrase "to capture
what's missing from current CCAMP work", but I feel that this is clouding (and delaying)
the production of a clear requirements draft.

So looking at the three topics that Deborah raised.

1.
Some members of the Design Team noted that reachability information (as described in
Section 4.5.3) may be advertised as a set of UNI Transport Resource address prefixes
(assigned and selected consistently in their applicability scope). These members of the
Design Team raised a concern that existing methods of advertising reachability may need to
be examined (on a per-protocol basis) to determine if they are also applicable for UNI
Transport Resource addresses. They invite CCAMP discussion on this aspect.

The first sentence is about requirements.
Do we, or do we not, need to support advertising UNI Transport Resource address prefixes?

The second sentence is about solutions and is not relevant in this draft.

db> As Jonathan corrected, reachability information advertised will depend on the applicable scope. The definition/requirement is the first sentence of the paragraph "Reachability information describes the set of endpoints that are reachable by the associated node." How (UNI address/SNPP) this is advertised is a "MAY". Additional note, on-going discussion in ITU is considering more appropriate terminology for UNI address is "name". Also, G7715.1 does not specify how/what reachability information is exchanged. Two hierarchical approaches are described, it is acknowledged in G7715.1 that multiple approaches exist. 

2.
ASON does not restrict the architecture choices used, either a co-located architecture or
a physically separated architecture may be used. Some members of the Design Team are
concerned that GMPLS's concept of the LSR requires a 1-to-1 relationship between the
transport plane entity and the control plane entity (Router). They invite CCAMP input on
GMPLS capabilities to support multiple architectures i.e. how routing protocols would
identify the transport node ID vs. the router or routing controller ID when scoping Link
IDs in a link advertisement.

The first sentence is about requirements.
Do we, or do we not need to support a physically separated architecture with a 1-n
relationship between control plane and transport plane entities?

The remaining text is about solutions and not relevant in this draft.

db> Support by "one" of "all" physical architectures is a "MAY". ASON does not restrict the architecture choice or realization. As ASON does not (at this time) include any performance requirements, as a carrier, I need to understand the protocol choices/tradeoffs if supporting a co-located (integrated) model vs. targeting a "one for all".

3.
In order to support operator assisted changes in the containment relationships of RAs, the
GMPLS routing protocol is expected to support evolution in terms of number of hierarchical
levels of RAs (adding and removing RAs at the top/bottom of the hierarchy), as well as
aggregation and segmentation of RAs. These GMPLS routing capabilities are considered of
lower priority as they are implementation specific and their method of support should be
evaluated on per-protocol basis e.g. OSPF vs IS-IS. In addition, support of non-disruptive
operations such as adding or removing a hierarchical level of RAs in or from the middle of
the routing hierarchy are considered as the lowest priority requirements. Note also that
the number of hierarchical levels to be supported is implementation specific, and reflects
a containment relationship e.g. a RA insertion involves supporting a different routing
protocol domain in a portion of the network.
Note: some members of the Design Team question if the ASON requirement for supporting
architecture evolution is a requirement on the routing protocol (protocol specific
capability) vs. a capability to be provided by the architecture. For example, ASON allows
for supporting multiple protocols within each RA. The multiple protocols share a common
routing information database (RDB), and the RDB is the component, which needs to support
architecture evolution. The Design Team invites CCAMP input to understand the
protocol-specific impacts.

This seems to mix up requirements and solutions.
It is not relevant what OSPF and IS-IS can or cannot do.

The requirements questions are:
A. What does ASON require in terms of evolution of hierarchies?

db> As Jonathan's notes, it is RA evolution (not the protocol). An ASON RA is a network subdivision (hierarchical level) which may contain multiple (different) routing protocols, it is not referring to one protocol's architectural subdivision. Jonathan's "further illustrated" list (for those unfamiliar with ITU terminology) is from an appendix illustrating examples (i.e. non-normative).

B. Are these requirements immediate and high priority?

db> The requirements are differentiated as shall/must and should/may.

Is it reasonable to make this separation between requirements, and consequent required
changes to the protocols? If so, can we focus on the requirements and make some
rapid progress?

db>The Design Team will redo the draft and limit to requirements only.

Thanks,
Adrian