Subject: RE: Stepping back from the ASON Routing Discussion

From: "Don Fedyk" <[email-masked]>
Date: Tue, 16 Mar 2004 21:41:18 -0500

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:[email-masked]] 
> Sent: Tuesday, March 16, 2004 5:44 PM
> To: [email-masked]
> 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

---

From: [email-masked]
Date: Wed, 17 Mar 2004 22:06:17 +0100

don

> to signal a name i.e. UNI TR address (complete). 

i have some difficulties to map the above sentence with the
below, for me reading this it is yes and then no i've another
way so i don't need, and the below is the real problem of
course the name resolution into the address prefix and one
uses the address prefix not the name in the signaling, why
shall you assume that the names are distributed but not their
corresponding prefixes or the mechanism to resolve them?

> participating fully in GMPLS routing.

but in 1-n, 1 controls n, and 1 participates to the routing,
the devices (part of the set n) are data plane entities that
are by definition not gmpls capable, so i don't understand
what you try to say here by the above justification

-- 
Papadimitriou Dimitri
E-mail : [email-masked]
E-mail : [email-masked]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 18 Mar 2004 11:43:01 -0000

Don,

Just picking out one snippet...

> > participating fully in GMPLS routing.

I had to read this several times before I got it. Sorry.

You mean that...
"It is a requirement of ASON routing to support networks that contain devices that do not
contain the capabilities to participate fully (or at all) in the routing protocols run
within the network."

That sounds a reasonable requirement.

There are two developments of this requirement.

The first is where the routing responsiblity for the device is taken on "by proxy" by a
control plane entity such as one that Lyndon, Jonathan and I have been drawing. In this
case, although the device is not participating in the routing protocols within the
network, it is fully represented and there are no issues (although we must ensure that
this function is covered by the requirements).

In the second case, ther are islands within the network which are simply not represented
to the routing protocol. This gives me a greater problem. Clearly you cannot route through
a part of the network unless it appears to be connected in the TEDB. In this case, I
suggest that what is needed is to represent those (legacy?) devices/subnetworks as
Forwarding Adjacencies or virtual TE links. This requires some advertisement by a control
plane entity on behalf of the devices/subnetworks, but does not expose the details of the
connectivity of the devices that do not support routing.

Some of you may (from time to time) hear me burble on about the fact that soft permanent
LSPs should not simply cover the case where the permanent part is at the edge of the
network. When I ramble in this way, I am talking about the second case, above.

Cheers,
Adrian

---

From: [email-masked]
Date: Thu, 18 Mar 2004 15:44:48 +0100

adrian, so let me try to recap here, what are the combination
using the terminology you were introducing that are w/i scope

1) R(i) 1:1 L(i) with every L(i) 1:1 P(i)
2) R(i) 1:n L(j) with every L(j) 1:1 P(j)
3) R(i) 1:1 L(i) with every L(i) 1:m P(j)
4) R(i) 1:1 L(i) with some  L(i) 1:0 P(j) and some L(i) 1:1 P(i)
5) R(i) 1:n L(j) with some  L(j) 1:0 P(k) and some L(j) 1:1 P(j)

if this is the case, are we missing something that needs to be
further covered ?

also there is no discussion here about DP<->CP realization and
or physical co-location issue(s), this is completely orthogonal
to the present discussion (some responses on the list show this
is still not clearly integrated)

---

From: "Vishal Sharma" <[email-masked]>
Date: Thu, 18 Mar 2004 11:43:26 -0800

Adrian, et al,

You mention that there are two developments of the following requirement:

["It is a requirement of ASON routing to support networks that contain
devices
that do not contain the capabilities to participate fully (or at all) in the
routing protocols run within the network."]

The second development listed below seems to assume that the islands within
the network will not be represented to the routing protocol only when they
contain devices that do not support routing.

However, this is where I would appreciate some clarification to
help clear some of my understanding of this discussion.

It seems to me that while one implication of the above requirement
is certainly this, it is also possible that islands are not represented
to the routing protocol, simply because the provider does not wish to
reveal the topology of its network beyond a certain level of granularity
(even if the devices do support routing protocols within those islands).

This would be increasingly so when hierarchy is implemented. (The devices
could then support routing at a given level of the hierarchy, but may be
abstracted at the next (higher) level.)

While I understand that the current discussion focuses initially on a given
level of the hierarchy, I think the second development you talk about
below is also a consequence of the need to support hierarchy.

Or, did I not get it right?

-Vishal

> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Adrian Farrel
> Sent: Thursday, March 18, 2004 3:43 AM
> To: [email-masked]; Don Fedyk
> Cc: [email-masked]
> Subject: Re: Stepping back from the ASON Routing Discussion
>
>
> Don,
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 18 Mar 2004 23:18:58 -0000

Vishal,

I think what you describe is business as usual for hierarchies.
This is clearly a requirement that needs to be captured, but it is nothing startling or
controversial (I believe).

Thanks,
Adrian
----- Original Message ----- 
From: "Vishal Sharma" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; <[email-masked]>; "Don Fedyk"
<[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, March 18, 2004 7:43 PM
Subject: RE: Stepping back from the ASON Routing Discussion

---

From: "Vishal Sharma" <[email-masked]>
Date: Thu, 18 Mar 2004 15:55:28 -0800

Adrian,

Great, thanks. I just wanted to make sure, since hierarchy was
point 3 of the requirements email you sent.

-Vishal

> Sent: Thursday, March 18, 2004 3:19 PM
> To: Vishal Sharma; [email-masked]; Don Fedyk
> Cc: [email-masked]
> To: "Adrian Farrel" <[email-masked]>;
> <[email-masked]>; "Don Fedyk"