RE: ASON Opacity

["Brungard, Deborah A, ALABS" <dbrungard@att.com>]

Hi Adrian,

The ASON Routing Requirements DT agrees with your analysis regarding the
ASON Routing Requirements Draft. We will provide an updated draft by
next Friday.
Thanks,
Deborah 

-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf Of Adrian Farrel
Sent: Wednesday, September 29, 2004 8:54 PM
To: ccamp@ops.ietf.org
Subject: ASON Opacity

Hi,

Here is my summary of the changes proposed by Jonathan Sadler for
inclusion in the CCAMP
ASON Signaling and Routing Requirements drafts.

As you will recall, these drafts (which have been through WG last call
and have had a full
process of exchange and liaison with the ITU-T's Study Group 15) had
been reviewed by the
AD and a few comments were raised. These comments were addressed
immediately before the
San Diego IETF, but the editors just missed the publication deadline.

Normally we would have gone ahead and submitted the drafts by now and
they would have gone
through the IESG. However, Jonathan spoke up in the CCAMP meeting in San
Diego to express
his reservations about the inadequate description of how the "opacity"
of a sub-network
should be preserved. We were concerned to get the drafts right and so
held back from
re-publication.

Jonathan was kind enough to agree to review the two drafts and document
his concerns in
greater detail. Pressure of work has unfortunately meant that Jonathan
has been unable to
do more than send me a draft of his worries. Since we must move forward
with these
documents I am taking the liberty of interpreting his draft and
expressing my views on
what changes should be made. This will allow the editors of the two
documents to debate
the points, make any necessary changes, and submit the documents. There
are plenty of SG15
people on this list, so I know that any errors I make in my
representation on Jonathan's
views will be immediately jumped upon.

Since the changes suggested to the document are so very small, I shall
not be calling for
a further WG last call. This means that I expect the editors to make a
call on the changes
necessary and to inform the WG of what they have done. I do not expect a
long discussion.

Thanks,
Adrian

====

ASON Signaling Requirements Draft

Issue:
The draft states that it provides "signaling requirements for G.8080
distributed call and
connection management based on GMPLS, within a GMPLS based control
domain (I-NNI) and
between GMPLS based control domains (E-NNI)." (Section 4, PP 2)  This
implies that the
requirements are consistent regardless of where the ingress and egress
of a connection is,
as long as all control domains involved in the connection use GMPLS.
Response:
I believe that Jonathan's inferred implication is correct and that the
text as it
currently stands is reliable. That is, the requirements are for GMPLS
signaling at I-NNI
and E-NNI reference points and that no statement is made about the
location of the ingress
or egress of calls or connections. No change to the text is needed to
clarify this.

Issue:
It should be noted that the draft does allow for different non-GMPLS
Control Plane
signaling protocols to be used in adjoining domains (Section 4, PP2),
and states that
interworking between signaling protocols is outside of the scope of the
requirements
document.  This statement eludes to the opacity of the subnetwork, but
does not explicitly
state it.
Response:
This is correct, but it might depend on the definition of "sub-network"
and "opacity".
Since the term "opaque" is neither defined nor used in G.805, G.8080 or
G.7713 it would be
inappropriate to introduce the term in this draft. In fact, in the
context of this
paragraph, the point seems to be well covered by exactly what is stated
here. The draft is
looking at signaling protocols (not at next hop routing, nor path
computation) and must
express how the signaling message is passed from one GMPLS-capable node
to the next. This
it does, and I don't believe any further change to the document is
necessary.

Issue:
The draft further goes on to say that for Call requests, "end-to-end
signaling should be
facilitated regardless of the administrative boundaries and protocols
within the network."
(Section 4, PP 2)  While subnetwork boundaries are instituted to realize
administrative
and signalling protocol boundaries in the network, there are other
reasons to create
subnetwork boundaries, including differences in how a subnetwork
connection is realized
within the subnetwork.
Response:
I understand this point, but the logic is reversed. The draft does not
refer to
subnetworks and so the reasons for their existence are not important in
this context.
Further, it should be noted that an important feature of G.8080 is that
a "control
network" can include multiple "subnetworks". Still further, I am unclear
how the
realization of Connections within a subnetwork is important to the
end-to-end nature of
Call request signaling. However, it might be appropriate (or harmless)
to change the text
to say "end-to-end signaling should be facilitated regardless of the
administrative
boundaries, protocols within the network or method of realization of
connections within
any part of the network."

Issue:
Further to this point, Jonathan and I have discussed whether the
end-to-end requirements
as expressed in Section 4 PP2 and the "end-to-end principle" applied to
Internet protocols
are compatible with the need to establish ASON Connections. I believe,
however, that my
response to him indicated that the "end-to-end principle" dictates not
that state is only
held at end points, but that state is only held on a need-to-know basis.
Thus Call state
is only held at UNI and E-NNI reference points, while Connection state
is held at UNI,
E-NNI and I-NNI reference points. It would be incorrect to require that
Call state should
be held at I-NNI reference points (even if that state is held
unprocessed in a transparent
manner). No change to the text is required for this point.

======

ASON Routing Requirements Draft

Jonathan points out that the draft already contains requirements that
are developed from
the autonomous nature of Routing Areas. There is a tendency, I feel, in
what Jonathan says
to tie a subnetwork too closely to the concept of a Routing Area where
G.7715 clearly
refers to "a subnetwork or a routing area" as distinct things that may
be commonly
referred to as a "node". Further, neither G.7715, nor G.7715.1 uses the
term "opaque" so
it is a little hard to conjure a precise wording for additions to this
draft.

Nevertheless, Jonathan makes a couple of simple suggestions for
additions to the draft as
follows.

Issue:
A routing area is a subnetwork with visibility to the egress links
connected to the
subnetworks ports (see G.8080 Sec 6.2)
Response:
This is not the definition of Routing Area that I find in section 6.2 of
G.8080 (perhaps I
have a different version?). However, the definition found in G.8080 *is*
useful and should
be included in our draft. It runs...
"Within the context of this Recommendation a routing area exists within
a single layer
network. A routing area is defined by a set of subnetworks, the SNPP
links that
interconnect them, and the SNPPs representing the ends of the SNPP links
exiting that
routing area. A routing area may contain smaller routing areas
interconnected by SNPP
links. The limit of subdivision results in a routing area that contains
two subnetworks
and one link."
Fortunately, this definition is included (verbatim) in Appendix 2 of the
draft. So no text
change is required.

Issue:
The method used by a subnetwork to realize a subnetwork connection is
not visible to a
route calculation being performed in the containing area.
Response:
This statement seems to mix routing areas and subnetworks too freely. A
routing area can
surely see all realizations within subnetworks that comprise the routing
area itself.
However, if we are talking about hierarchical routing areas then, yes,
this is precisely
the definition of the hierarchical routing area and the draft goes into
considerable
detail about the way in which reachability information may be exchanged,
but that routing
information abstraction is used to limit the visibility into the child
RAs topology and
capabilities. I don't believe any further additions are required.

Issue:
The subnetwork may provide an abstracted representation of the
connectivity available
through the domain to the higher level routing area.  This is done at
the discretion of
routing controller(s) within the subnetwork, and not through filtering
performed by the
higher level routing controllers.
Response:
There are two statements here. The first is true and is described in
some detail in
section 4.2 of the draft. The second statement again mixes subnetworks
and routing areas,
but if we re-state it fully in terms of RAs we also find text that
covers this situation
in section 4.2 of the draft. Further, we should note that G.7715.1
actually also allows
the filtering within the parent RA...
"In the second approach, the Level N+1 RC listens to the routing
protocol exchange
occurring in each contained Level N RA and retrieves the endpoints being
announced by the
Level N routing instance(s) and the full Level N topology.  This
information may be
summarized into one or more address prefixes and an abstracted topology
in order to
facilitate scalability."
Thus, I think no change to the draft is required on this account either.