ASON Opacity

["Adrian Farrel" <adrian@olddog.co.uk>]

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.