RE: ASON Opacity

["Lam, Hing-Kam (Kam)" <hklam@lucent.com>]

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:otxchange@ftp.itu.int/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:adrian@olddog.co.uk]
> 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.
> 
> 
> 
> 
>