Subject: Missing pieces in draft-team-tewg-restore-hierarchy-00.txt

From: Sudheer Dharanikota <[email-masked]>
Date: Thu, 16 Aug 2001 11:46:34 -0700

Hi all:

I have following comments on the design team draft presented at
IETF. I already discussed some of these comments with
Wai.

1. You need to take this drafts to next level in making protocol
related suggestions and requirements, and clarify deployment
assumptions.

2. Please make a clear distinction between hierarchy and partitioning.
What seemed to be a horizontal hierarchy is in fact a network partition
in the carrier networks. (These were Yong's comments)

3. Although you say only horizontal hierarchy is considered, we propose
atleaset two layer (Client and Server layer) capabilities should be
considered.
Example, if the server layer is optical or SONET/SDH then it itself can
possess some restoration capabilities, which need to be considered by
the client layer technologies. This helps in choosing the protection and

restoration mechanisms wisely.

4. Need to provide a better and clear definition of SRG and its
interaction
to the restoration strategy. In this context please refer to our work on
SRGs,
draft-many-ccamp-srg-00.txt. Feel free to take the definitions and other

requirements related material (with due acknowledgement :-) ) from this
draft.
Especially, as presented at the TEWG, we would like to include
following:

    - the concept of "Risk Domain" associated with SRG (please refer to
the
    draft on the definition and its usage).
    - add capabilities to SRG. This helps in diverse path computation.
    - add summarization requirements to reduce the amount of TE
information
    dissemination.

5. Recovery time requirements, capacity planning assumptions and service
request
interface definitions should be clarified.

Thank you,

sudheer

---

From: Jim Boyle <[email-masked]>
Date: Wed, 22 Aug 2001 20:36:28 -0400 (EDT)

Sudheer - you raise an interesting question...

> IETF. I already discussed some of these comments with

<snip>

> restoration mechanisms wisely.

It was felt in the design team that carriers are not quite at the point of
deploying GMPLS into their optical cores, not quite yet.  And even if they
had GMPLS cores, ready to be tapped into by routers from *within* their
company - most felt a bit uneasy about this prospect.

Are there folks deploying GMPLS Optical Cores that are worried that there
will be a time real soon when their routers won't be able to signal for
bandwidth on demand?  Or that there might be some crucial piece of
communication their Optical Core might be able to confer to their Routers
that might change their behavior (that couldn't be conferred in a more
ready manner - such as by configuration of the router) ??

The area that did seem more pressing was how to support edge to edge
signaling across a data network, which might have OSPF areas.  There
was concern about scalability, and a desire to have folks look into
approaches which would allow edge to edge signaling in a manner which
is more scalable than possible today.  The recurring context for such
a need was VPNs (mpls presumably) over IP/MPLS networks.  The need to
signal edge to edge might very well be questioned, however some folks
seem to think that if a VPN product offers an SLA, this is somehow
necessary.

Anyone else think that the "vertical" hierarchy is pressing (or a
non-issue at this time)?

Anyone have interesting operational perspectives which clarify the
"horizontal" requirements?

regards,

Jim

---

From: Sudheer Dharanikota <[email-masked]>
Date: Thu, 23 Aug 2001 09:54:36 -0700

Jim:

One comment inline.

> Anyone else think that the "vertical" hierarchy is pressing (or a

The issue I have raised is not just for the vertical hierarchy in my opinion.
GMPLS is mainly used for making transmission equipment more intelligent.
The intelligence is in selecting a path through these equipment (includes both

path computation and path setup). People are known to pre-provision different
transmission topologies to recover quickly from failures. Path computation
needs accurate representation (or accurate abstraction :-) ) of the
transmission
layer topology and its capability.   This in my opinion is not captured in the
draft.
I am still talking about a single layer here.

Regards,

sudheer