RE: Stepping back from the ASON Routing Discussion

["Don Fedyk" <dwfedyk@nortelnetworks.com>]

Hi Adrian

I had to step away from my computer for a snowstorm looks like there was a
bit of a flurry here too;-) 
I'll try to stick to the questions and answers as I know them. 

See inline

> -----Original Message-----
> From: Adrian Farrel [mailto:adrian@olddog.co.uk] 
> 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?
My opinion is Yes there is a requirement in signaling protocols requirement
to signal a name i.e. UNI TR address (complete). 
No in inter domain routing. Requirement addresses must be able to be
aggregated and names are not. The requirement is that a UNI TR address must
resolve to an Prefix address (For GMPLS routing IP prefix fits). 
That leaves intra domain routing. The requirement is to have a destination
address resolution. You are signaling with a UNI TR address (complete) and
you have a IP address prefix or nothing.  The problem is IP cannot take you
all the way because resolving completely outside of the area is not a
requirement. But inside the area you should be able to resolve a UNI TR
address to a IP address Control plane element. 

> 
> 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 yes. The requirement I see here is devices not capable of
participating fully in GMPLS routing.

> 
> 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.
> 
> The requirements questions are:
> A. What does ASON require in terms of evolution of 
> hierarchies? B. Are these requirements immediate and high priority?
No comment from me. 

> 
> 
> 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?

Hope that helps,
Don 
> 
> Thanks,
> Adrian
> 
> 
>