[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Stepping back from the ASON Routing Discussion
don
Don Fedyk wrote:
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).
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?
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.
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
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
--
Papadimitriou Dimitri
E-mail : dimitri.papadimitriou@alcatel.be
E-mail : dpapadimitriou@psg.com
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone : +32 3 240-8491