Subject: RE: Stepping back from the ASON Routing Discussion

From: "Ong, Lyndon" <[email-masked]>
Date: Tue, 16 Mar 2004 15:32:40 -0800

Hi Adrian, Vishal,

Just when we had a good argument going!

Seriously, I would say yes to the first two requirements,
with the addition of the more detailed requirements you asked
to be captured from my email and Jon's email

(LYO: If it is possible
> to advertise from R1 that P1/P2/P3 are separate nodes with 
> links in-between, then that would I think be satisfactory.)

(JS/AF:    A collection of links and nodes such as a subnetwork or RA must
   be able to represent itself to the wider network as a single 
   logical entity with only its external links visible to the 
   topology database.)

Cheers,

Lyndon

---

From: "Brungard, Deborah A, ALABS" <[email-masked]>
Date: Wed, 17 Mar 2004 15:40:25 -0600

Agree, it would be better to separate and focus on the requirements first. Additional comments below. As I summarized below, the DT will redo the draft and limit to requirements only.
Thanks,
Deborah

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Adrian Farrel
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?

The second sentence is about solutions and is not relevant in this draft.

db> As Jonathan corrected, reachability information advertised will depend on the applicable scope. The definition/requirement is the first sentence of the paragraph "Reachability information describes the set of endpoints that are reachable by the associated node." How (UNI address/SNPP) this is advertised is a "MAY". Additional note, on-going discussion in ITU is considering more appropriate terminology for UNI address is "name". Also, G7715.1 does not specify how/what reachability information is exchanged. Two hierarchical approaches are described, it is acknowledged in G7715.1 that multiple approaches exist. 

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?

The remaining text is about solutions and not relevant in this draft.

db> Support by "one" of "all" physical architectures is a "MAY". ASON does not restrict the architecture choice or realization. As ASON does not (at this time) include any performance requirements, as a carrier, I need to understand the protocol choices/tradeoffs if supporting a co-located (integrated) model vs. targeting a "one for all".

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?

db> As Jonathan's notes, it is RA evolution (not the protocol). An ASON RA is a network subdivision (hierarchical level) which may contain multiple (different) routing protocols, it is not referring to one protocol's architectural subdivision. Jonathan's "further illustrated" list (for those unfamiliar with ITU terminology) is from an appendix illustrating examples (i.e. non-normative).

B. Are these requirements immediate and high priority?

db> The requirements are differentiated as shall/must and should/may.

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?

db>The Design Team will redo the draft and limit to requirements only.

Thanks,
Adrian

---

From: "Don Fedyk" <[email-masked]>
Date: Wed, 17 Mar 2004 18:26:52 -0500

Hi Dimitri

> From: [email-masked] 
> [mailto:[email-masked]] 
> 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
> > 
> > 
> >>From: Adrian Farrel [mailto:[email-masked]]
> >>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.
> >>
> >>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.
> >>
> > 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.
> > 
> > 
> >>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.
> >>
> >>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. 

> >>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.
> >>
> >>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 : [email-masked]
> E-mail : [email-masked]
> Webpage: http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone  : +32 3 240-8491
> 

Regards,
Don

---

From: "Don Fedyk" <[email-masked]>
Date: Thu, 18 Mar 2004 17:30:16 -0500

Jonathan and Kireeti

A question

> From: Kireeti Kompella [mailto:[email-masked]] 
> Sent: Thursday, March 18, 2004 3:03 PM
> 
> 
> Hi Jonathan,
> 
> On Wed, 17 Mar 2004, Jonathan Sadler wrote:
> 
> > There is a requirement to be able to advertise reachability (G.7715 
> > sec7.1.1, G.7715.1 sec 9.4).  G.7715.1 states:
> >   Reachability Information: Reachability information describes
> >   the set of endpoints that are reachable by the associated node.
> >   It may be advertised either as a set of UNI Transport Resource
> >   addresses/address prefixes, or a set of associated
> >   SNPP IDs/SNPP ID prefixes, the selection of which must be
> >   consistent within the applicable scope.
> > so technically, there isn't a requirement to advertise UNI 
> Transport 
> > Resource Addresses -- the requirement is to advertise 
> reachability in 
> > terms of SNPP IDs or UNI Transport Resources Addresses.
> 
> Thanks for the references!  This is exactly what I want to 
> see.  What I don't want is an ITU-T Liaison complaining that 
> we are re-doing their requirements :-)

Is it safe to say the primary requirement is not the advertisement itself
but the ability for a user/operator to be able to setup connections/calls
using either UNI Transport Resource addresses or SNPP IDs as the local and
remote endpoints identifiers?  I think this is the primary requirement and
it can be somewhat independent of the advertisement depending on scope.  I
hear the advertisement requirement as well, but I believe that by first
separating these requirements and scoping them we may be able to make some
progress. 

Thanks,
Don

---

From: <[email-masked]>
Date: Fri, 19 Mar 2004 10:10:46 -0000

Hi Adrian....I have been biting my tongue and trying hard to stay out of this....I have failed, but I'll try and keep it short.

You (and Vishal) are right....we have been doing hierarchies for years.  And there are not just technical issues wrt client/server layer network relationships (which is what transport hierarchies create), there are also commercial issues, ie different parties can own the client and server layer networks involved.

The problems arise when folks think they can converge (somehow) the 3 native network modes of cl-ps, co-ps and co-cs.  Sure you can try, but its a big mistake.  All these modes can be derived from applying constraints to the most basic network mode, which is 'broadcast at source, filter at sink'.  This is how humans communicate in a mtg, and its how ethernet works.  However, it does not scale.  So we introduce constraints.....and we do so to get benefits in simpler design/operations/management/etc.

Addressing and routing are the 1st set of constraints.....these provide a 'where' (not 'who') semantic and a limited directivity behaviour.  This gets us to the cl-ps WAN mode best exemplified by IP.  Adding signalling (ie controlling the directivity further) gets us to the co-ps mode.....and it has implications on the nature of the forwarding traffic unit, ie this can be simplified to simply contain a link-connection ID (ie label) and not a full DA/SA pair (as required for the cl-ps mode).....the addresses are now only related to the trail access points.  If we add further constraints to the forwarding traffic unit we end up with the co-cs mode, ie now fixed BW, labels become some time/freq/space metric and (*very* significantly) there are no traffic/QoS classes.

However, all these modes have very different behaviours, eg the faults that can affect each mode are very different and the arch constructions that are allowed are different (I'll resist explaining why certain types on MPLS break the arch rules).  The simple fact is they all do different jobs optimally and we thus need them all.  The last thing one should be doing is trying to converge them all.....its simply wrong and folks who try this will continue to hit problems. (What we do want however is convergence *within* each mode, ie no point in having lots of co-ps technologies say.....just leads to stovepipe proliferation (ie technology=service) and downstream i/w problems).

We require our suppliers to understand/respect the func arch stuff of layered networks that is detailed in G.805/809...everything flows from these, esp the management information models.  And we were instrumental in doing the control-plane func arch of G.8080.  

I'll stop at that point since I am sure you can fill-in where I am heading now ;-)

regards, Neil

> Sent: 18 March 2004 23:19
> To: Vishal Sharma; [email-masked]; Don Fedyk
> Cc: [email-masked]
> Subject: Re: Stepping back from the ASON Routing Discussion
> 
> 
> 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
> 
> 
> > 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
> >
> > > 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,
> > >
> > > Just picking out one snippet...
> > >
> > > > > I would say yes. The requirement I see here is 
> devices not capable of
> > > 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
> > >
> > >
> >
> >
> >
> >
> 
> 
>