[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Stepping back from the ASON Routing Discussion
Hi Dimitri
> -----Original Message-----
> From: Dimitri.Papadimitriou@alcatel.be
> [mailto:Dimitri.Papadimitriou@alcatel.be]
> Sent: Wednesday, March 17, 2004 4:06 PM
>
> 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?
Sorry I was trying to be consistent. I see the requirement of multiple
address types. What I don't see is a requirement that says to support
multiple addresses you have to have multiple addresses in every TLV in every
routing protocol. The relationship is like VoIP or even host names and IP
addresses. A user should be able to type in a destination UNI TR address and
without any other addressing a path/call/connection comes up. The fact that
internal translations were used is transparent to the user. The other
requirement I see is that the systems not be tied solely to UNI TR address
forever. The fact that internal translations were used is a key for
evolution/flexibiity.
As for address/name resolution it is very common to put the minimal
resolution information when you are distant from the address and refine it
as you get closer to the destination. I only see requirements for minimal
resolution of addresses/names outside the area. That is practical and
flexible.
>
> > 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 device/controller that speaks GMPLS may speak on behalf of devices that
don't.
> >>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
>
Regards,
Don
>