RE: Stepping back from the ASON Routing Discussion

["Vishal Sharma" <v.sharma@ieee.org>]

Adrian,

This is the clearest statement of requirements on these three
counts that I have yet seen! Thanks for zeroing in on these
so succinctly.

(And, yes, I agree that we are getting drawn into solutions; I
think the implication being that there is agreement on the
requirements?)

Responses in-line.

-Vishal

> -----Original Message-----
> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On
> Behalf Of Adrian Farrel
> Sent: Tuesday, March 16, 2004 2: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?

I would say "Yes."

> The second sentence is about solutions and is not relevant in this draft.
>
> 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?

I would say an emphatic "Yes."

(Recall Lyndon's ADM example, and
plenty of others, where such intelligence may not be co-incidental with,
or exclusive to, each data plane entity. And, recall Jonathan's logical
node Tn, in response to Issue 2)

> The remaining text is about solutions and not relevant in this draft.
>
> 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.

I agree, but would add "for the moment." Clearly, the next step
would be to move into the protocol capabilities.

> The requirements questions are:
> A. What does ASON require in terms of evolution of hierarchies?
> B. Are these requirements immediate and high priority?


I would add...

C. Are the hierarchy requirements, requirements on the routing protocol
or on the realization of the architecture?
(Strictly speaking, even this may not be part of the requirements
document, but it would be nice to know (and agree on) the answer
to this, because it dictates what we focus on next.)


> Is it reasonable to make this separation between requirements,
> and consequent required
> changes to the protocols?

I think very much so.

If so, can we focus on the requirements
> and make some
> rapid progress?
>
> Thanks,
> Adrian
>