Subject: RE: ASON Opacity

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Wed, 6 Oct 2004 17:15:10 -0400

Hi Adrian,

We very much appreciate to continue the process of exchange and liaison with CCAMP.
The second paragraph of your email however reminds me that these drafts have not been formally liaised to SG15 yet. It also reminds me that the Q14/15 Liaison Statement from the Februrary 2004 Chicago meeting to CCAMP 
ftp://sg15opticalt:[email-masked]/tsg15opticaltransport/COMMUNICATIONS/ccamp/IETF_ccamp_G.7713.2_comments.html
has never been responded by CCAMP yet. 

Regards,
Kam Lam 
ITU-T Q14/15

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Wednesday, September 29, 2004 8:54 PM
> To: [email-masked]
> 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.
> 
> 
> 
> 
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 7 Oct 2004 01:16:25 +0100

Hello Kam,

Thanks for the email. Let me go over the history before coming to your specific points.

The review and liaison in Chicago were in direct response to CCAMP passing the latest
copies of the drafts to SG15 and soliciting input. They were notified to the CCAMP mailing
list on 1st March, (and so copied to the ASON signaling and routing requirements design
teams), published on the CCAMP alternative web pages, and published on the IETF's liaison
pages.

The CCAMP design teams responsible for the ASON signaling and routing requirements drafts
were certainly grateful for the review comments received in a formal liaison from SG15.
You may be sure that the points raised were fully considered, especially since I was in
the room in Chicago when drafts were reviewed and the liaison statement was drafted.

The liaisons were subsequently presented to CCAMP in Seoul by Lyndon Ong and the efforts
of the ITU-T were recognized from the chair.

On return from Seoul, the editor of the ASON Signaling Requirements draft was able to
agree upon the points for inclusion in the draft after discussion with his design team.
The changes made were largely in line with those suggested by the liaison.

After Seoul, the editor of the ASON Routing Requirements draft was able to reach agreement
on all but three points. She quickly took these remaining issues to the CCAMP mailing list
where they were (hotly) debated. After a while it was possible to separate the requirement
issues from the discussion of solutions and progress was made thanks to the participation
of no fewer than seven people who regularly attend and participate in SG15. The debate
quietened down after March 19th with sufficient consensus for the design team to move
forward.

A working group last call was issued for the ASON Routing Requirements draft on April 15th
and included the text...
> The ASON Routing Reqts DT has updated the following draft based on
> ITU Q14/15's Liaison and CCAMP mail list comments.
This means that the SG15 comments were included as modified by the discussions on the
CCAMP mailing list, and that the draft had been agreed upon by the whole design team.

A working group last call was issued for the ASON Signaling Requirements draft on April
26th and included the text...
> The authors of this draft have updated it to reflect the comments on the
> mailing list and the helpful feedback from ITU-T SG15 Question 14.
This means that the SG15 comments were included. In fact, the draft had been updated and
agreed upon by the whole design team. The fact of the last call was circulated to the
IETF's OSPF, IS-IS and Routing working groups in order to ensure a wide coverage of
potential reviewers.

It is unthinkable that either draft would have been published or put up for last call if
any member of the design team had raised an objection.

A working group last call is public and is not confined to any particular body. It gives
an opportunity for everyone who is subscribed to the mailing list to comment. This covers
a considerable number of participants in SG15 and, of course, includes the whole of the
design team.

The ASON Routing Requirements draft completed last call with a few minor comments. It
turned out that most of these comments were questioning the validity of text in G.7715.1,
and CCAMP's position was (of course) that the draft must reflect the statements in that
recommendation and not try to invent different requirements. The other comments were
editorial nits. The draft was duly updated with agreement from the design team, and
re-published on May 6th with notification on the CCAMP mailing list.

The ASON Signaling Requirements draft completed last call with no comments.

Both drafts were passed to the AD for review.

On May 10th a further liaison was received from SG15 Q.14/15 thanking CCAMP and the
members of the ASON Routing Requirements Design Team for their efforts to understand and
capture ASON Routing Requirements for the future work in IETF. This liaison was published
and notified on the CCAMP mailing list.

In the run-up to the San Diego IETF, both drafts were reviewed by the AD and were updated
accordingly. The changes were minor and for clarification only. Again, the design team
agreed the changes. The drafts were not published before San Diego, but were made publicly
available.

In San Diego, both drafts were presented and the plan to forward them to the IESG was
announced. However, Jonathan Sadler raised an important concern that the drafts did not
sufficiently capture the notion of subnetwork opacity. This was picked up by a number of
people attending the meeting and it was immediately agreed that a gathering of the design
team, working group chairs and other interested parties should be held at once. Although
the process had already been completed with ample chance for the authors, the design team
and external reviewers to discover and raise this point, the gathering agreed that
Jonathan should be deputed to review the drafts in the light of his concerns and raise any
specific issues with me.

Over the next couple of months, Jonathan raised a few points with me and I passed them on
to the design team and to the CCAMP mailing list. A quick analysis revealed that only a
very minor change was required. This was agreed upon by the design teams and the drafts
were published.

The drafts are now on their way to the IESG for review.

It is worth pointing out that the two design teams concerned are joint design teams of the
IETF's CCAMP working group and the ITU-T's SG15. The reason for having a joint design team
is so that the work progresses faster and in tandem. One might reasonably assume that the
SG15 members of the team were regularly reporting back to the ITU-T on the progress of the
drafts, as the CCAMP members were required by the working group to do. So, while the
liaison process was useful for collecting together the formal review comments, it was
somewhat secondary to the joint development of the drafts by members of both groups.

Now to your specific email.

> We very much appreciate to continue the process of exchange and liaison with CCAMP.

Thank you. On the whole I think it has been valuable and has ensured that the two groups
are in synch with regard to the requirements on GMPLS networks for the support of ASON.
Certainly, given the unanimity of support in the design teams for the two drafts, we have
been successful.

Of course, i am considerably concerned by the extremely long time that it has taken to
produce this relatively simple draft. Truly, design by committee is a long-winded process.
But, in this case, it has been worth it to ensure the complete agreement that we have
achieved.

> The second paragraph of your email however reminds me that these
> drafts have not been formally liaised to SG15 yet.

This is so, and I am surprised that you expect any different. Certainly the ITU-T is not
in the habit of liaising its draft recomendations to the IETF and gaiting their progress
pending a response.

But recall that the previous version of the draft was liaised ot SG15, and SG15 reviewed
it thoroughly and rseponded fully.
Since the review comments were significantly incorporated, a further liaison of the drafts
was clearly unnecessary. In any case, the design teams had had ample oportunity to review
the drafts, and many members of the SG15 community had also been afforded that oportunity
through the normal open and public IETF process.

>It also reminds me that the Q14/15 Liaison Statement from the
> Februrary 2004 Chicago meeting to CCAMP
>
> has never been responded by CCAMP yet.

That is true.

I'm afraid that I was not aware that a response was either required or desired (although I
admit that it would have been polite if Kireeti and I had acknowledged the receipt). This
may be due to the fact that I do not understand ITU-T phrasing, because I see that the
liaison is marked as "For: Action" with "Deadline: 12th April 2004". This was interpretted
as meaning that SG15 would like CCAMP and the design teams to act on the liaison before
12th April - which they did.

Had there been a direct request for a response we would have endeavored to reply in the
specified timescale. (Although we are all human, and have day jobs, so sometimes these
things do get dropped.)

If you feel that it would be helpful for CCAMP to generate a liaison about these drafts,
please let me know and we will be glad to supply one.

The paragraph from my email that you cite reads as follows.

> > 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
> > addressed immediately before the San Diego IETF, but the
> > editors just missed the publication deadline.

I think you will agree that the liaison process for these drafts has been very full.
Probably more extensive than any for a long time. And the fact that the drafts were
authored by design teams deliberately picked to include members of both groups is evidence
of the lengths to which this process was taken.

I hope this answers all of your questions, but please do let me know if there is more
information that would help you.

Regards,
Adrian