Subject: Re: Stepping back from the ASON Routing Discussion

From: Jonathan Sadler <[email-masked]>
Date: Wed, 17 Mar 2004 11:39:55 -0600

Hi Adrian -

Adrian Farrel wrote:

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

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.

It should be noted that there is a unique attribute of SNPP Prefixes and UNI Transport
Resource Addresses -- they exist independant of layer networks.  More specifically, UNI
Transport Resource Addresses are used to name an Access Group Container, where the Access
Groups within the Container can be in one or more layer networks.  So, it cannot be assumed
that a specific UNI Transport Resource Address is in Layer Network A or B.

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

Yes.

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

The requirements stated in G.7715.1 are:
  "...the routing protocol shall be capable of supporting
  architectural evolution in terms of number of hierarchical
  levels, as well as aggregation and segmentation of RAs."

This is further illustrated as being:
 - Segmentation of one Routing Area into two separate RAs
 - Aggregation of two RAs into one RA
 - Renaming of RAs
 - Insertion of an RA into the hierarchy
 - Deletion of an RA from the hierarchy

Insertion and Deletion can be done at any point in the hierarchy -- it is not limited to just
the top or bottom of the hierarchy.

> B. Are these requirements immediate and high priority?

No statement of immediate/high priority exists in the ASON documents for any ASON requirement.

> 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?
>
> Thanks,
> Adrian

-----------------------------------------
============================================================
The information contained in this message may be privileged 
and confidential and protected from disclosure.  If the 
reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to 
the intended recipient, you are hereby notified that any 
reproduction, dissemination or distribution of this 
communication is strictly prohibited. If you have received 
this communication in error, please notify us immediately by 
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================

---

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

jonathan,

> requirement is to advertise reachability in terms of SNPP IDs or UNI Transport Resources

i've checked in the i-d and it also says "may" inline with this but then 
the question becomes (assuming that reachability information is a 
requirement) that the alternatives may not be suitable for one
reason or another, most people say yes but this is not how imho .1 
reads, it is non limitative but not all inclusive for all control plane 
realizations

>>relationship between control plane and transport plane entities?

if the sentence reads "ASON does not restrict the architecture choices 
used, either a 1-1 architecture or a 1-n architecture between control
plane and transport plane entities" - this issue about physical co-
location is not a control plane requirement i don't think ASON has any
requirement in terms of internal vs external bus vs external network,
you're just degrading the performance - said in another way no control 
plane restricts this you can run 1000 of instances of the control plane 
on a single control plane entity to manage 1000 devices is there 
something specific to ASON here ? so as this a requirement shouldn't be 
something like "ASON control plane entity distribution and behaviour is 
independent of the actual distribution of the resources it controls."
in charge for the protocol to deliver the mechanism(s) to support this
flexibility in the architecture ?

> No statement of immediate/high priority exists in the ASON documents for any ASON requirement.

on this one rephrasing is needed, can we agree on a specific (condensed) 
text and say re-ask the same question, what i would propose is

"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. Example: 
support of non-disruptive operations such as adding and removing RAs at 
the top/bottom of the hierarchy, adding or removing a hierarchical level 
of RAs in or from the middle of the hierarchy, as well as aggregation 
and segmentation of RAs."

as the illustration was non-normative anyway

-- 
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: Kireeti Kompella <[email-masked]>
Date: Thu, 18 Mar 2004 12:03:09 -0800 (PST)

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:
> 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 :-)

> It should be noted that there is a unique attribute of SNPP Prefixes
> and UNI Transport Resource Addresses -- they exist independant of
> layer networks.  More specifically, UNI Transport Resource Addresses
> are used to name an Access Group Container, where the Access Groups
> within the Container can be in one or more layer networks.  So, it
> cannot be assumed that a specific UNI Transport Resource Address is
> in Layer Network A or B.

Okay, noted.

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

If you have references, that would be great.  In my reading (I'll look
for the reference), I understood this to be: ASON doesn't restrict the
architecture to physically co-located or to physically separate, i.e.,
a particular solution may do either.  In that case, unless GMPLS
supports both, we should just state which approach GMPLS takes.

(As an aside, I'm not convinced that GMPLS is restricted to a single
box architecture.  The combination of GMPLS and GSMP should yield a
non-co-located architecture.  However, this may not be as well-fleshed
out as one wishes.  But this is orthogonal to the requirements.)

...
> Insertion and Deletion can be done at any point in the hierarchy --
> it is not limited to just the top or bottom of the hierarchy.

Perfect.

> for any ASON requirement.

That's a good point.  When we liaize (forgive me!) this back to the
ITU-T SG14, we should mention that we have prioritized the
requirements, and ask if they have comments on that.

Thanks again for bringing us back to the DT charter!

Kireeti.
-------