[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposed response to ITU-T SG15 Questions 12 and 14 on ASON Lexicography
I don't think it is CCAMP's role to correct the English of another SDO :-)
----- Original Message -----
From: "Tom Petch" <firstname.lastname@example.org>
To: "Adrian Farrel" <email@example.com>; <firstname.lastname@example.org>
Sent: Tuesday, July 19, 2005 7:18 PM
Subject: Re: Proposed response to ITU-T SG15 Questions 12 and 14 on ASON
> I think it should be
> - CCAMP has primary responsibility for the descriptions of GMPLS terms
> Correct "
> even if that is not what SG15 said.
> Primarily (sic) CCAMP has responsibility for the specification of GMPLS,
> just its terms:-)
> Tom Petch
> ----- Original Message -----
> From: "Adrian Farrel" <email@example.com>
> To: <firstname.lastname@example.org>
> Cc: "'Kireeti Kompella'" <email@example.com>; <firstname.lastname@example.org>; "Bill
> <email@example.com>; "Scott Bradner" <firstname.lastname@example.org>
> Sent: Tuesday, July 19, 2005 1:59 PM
> Subject: Proposed response to ITU-T SG15 Questions 12 and 14 on ASON
> > Hi,
> > Please comment on this draft response liaison which I intend to send
> > Monday 25th July.
> > You can see the original incoming liaison at
> > http://www.olddog.co.uk/incoming.htm
> > Thanks,
> > Adrian
> > =====
> > To: ITU-T SG15 Questions 12 and 14
> > From: IETF CCAMP Working Group
> > Subject: Response to your liaison on GMPLS/ASON Lexicography
> > For: Action
> > Deadline: August 31st 2005
> > The CCAMP Working Group would like to thank SG15 and especially
> > 12 and 14 for the time and effort they put into providing input and
> > feedback on the GMPLS/ASON lexicography Internet-Draft that is being
> > developed by CCAMP. Much of the material supplied as direct comments
> > mark-ups to the Internet-Draft has been incorporated into the latest
> > revision which is available at
> > In your liaison you state some assumptions which we would like to
> > on as follows.
> > - The purpose of the document is to enable those familiar with ASON
> > to understand GMPLS terminology in an ASON context
> > Correct.
> > - GMPLS terms are described informally in the document in a way that
> > is generally consistent with GMPLS (existing RFCs and work in
> > While the definition of GMPLS terms would be helpful for understanding
> > GMPLS terms in a GMPLS context, that is not the purpose of this
> > - Based on these descriptions, interpretations of these GMPLS terms
> > in ASON terminology are provided
> > It is intended that the interpretation of the GMPLS terms is not based
> > these descriptions, but based on the full meaning of the GMPLS terms.
> > descriptions of the GMPLS terms are provided in this Internet-Draft
> > context and a brief summary.
> > - CCAMP has primarily responsibility for the descriptions of GMPLS
> > Correct.
> > - Q12/15 has responsibility to provide input to the GMPLS-ASON
> > interpretations (based on the descriptions in this draft)
> > We welcome this assumption of responsibility by Q12/15 to provide
> > the Internet-Draft. While the Internet-Draft remains under the overall
> > editorial control of the CCAMP working group, we hope to be able to
> > the text supplied by Q12/15 with only editorial changes.
> > Additionally, we welcome the pledge to continue work on this
> > Internet-Draft through correspondence on the Q12/15 mailing list, and
> > thank Q12/15 for assigning Ben Mack-Crane as the SG15 representative
> > this matter. Ben has proved very helpful in clarifying and developing
> > comments received from SG15.
> > We have had several email exchanges with Ben about a few of the
> > comments made in your review of the 02 revision of the Internet-Draft.
> > Although he has taken these comments to the Q12/15 mailing list no
> > response has been received, perhaps due to pressure of time. We are
> > the opportunity to restate several questions here for your convenience
> > would appreciate your answers as part of the response to this liaison.
> > 1. Definition of a Resource (section 3.2)
> > You have supplied us with the simple text that says...
> > In ASON applications:
> > A resource refers only to a link connection (e.g. VC-11,
> > VC-4 etc.).
> > We would like to clarify this because we don't understand how
> > the original text is wrong. It used to say...
> > ITU-T [should be ASON] terms for resource:
> > - Connection point (cp) in the context of link discovery
> > and resource management (allocation, binding into
> > cross-connects, etc.);
> > - Link connection or trail termination in the context of
> > routing, path computation and signaling.
> > Recall that we are talking about the ASON terms for what GMPLS
> > calls a resource. We think the following...
> > In ASON a link connection is an association of output cp on one
> > side of the link and input cp on the other side of the link. In
> > GMPLS by resource we mean in most of the cases the local end of
> > the resource (which is cp in ASON terminology). This is true in
> > the context of link discovery.
> > More importantly, this is also true in the context of a
> > signaling application. Specifically, when a GMPLS signaling
> > sub-system requests allocation of a resource, the GMPLS
> > Resource Manager allocates only the local end of the
> > resource. This happens on both sides of the link, that is, we
> > allocate input and output resources. This contrasts with ASON,
> > where there is a much more versatile LRM, and the connection
> > manager (signaling application) allocates link connections
> > only on the output side, leaving LRM to coordinate the
> > allocation with the neighbor.
> > However, in GMPLS TE advertisements we account only for
> > outgoing resources, that is, we don't advertise incoming
> > resources on the assumption that they match the outgoing
> > resources for the discovered TE links.
> > Bottom line: we believe that we should retain the previous
> > definitions, and have not made this change in the new
> > revision. We would like to discuss this point further with
> > Q12/15.
> > 2. Link ends and Data links (Section 3.5 - was section 3.4)
> > 2a.Although we understand that ASON does not require the concept
> > of a link end, GMPLS does. Therefore we should provide some
> > form of language to help people do the mapping.
> > The proposed new text from Q12/15 removes all reference to
> > link ends from the ASON section, and we feel this is a
> > mistake and propose the following text:
> > In ASON, a GMPLS unidirectional data link end is a
> > collection of connection points from the same client
> > layer that are supported by a single trail termination
> > (access point).
> > This text depends on the fact that a link end is described as
> > a set of resources that transfer traffic to a neighbor.
> > 2b.The new text from Q12/15 gives us...
> > A GMPLS data link is an ASON link supported by a single
> > server trail.
> > We are not sure that we understand this correctly. It
> > appears to say that a unidirectional data link could be
> > supported by multiple trail terminations (access points).
> > This seems to suggest that a client would have to make a
> > choice about where to send data, which seems to imply it
> > really has to choose between data links! We are confused!
> > We think some of this problem may come from the *need* in
> > GMPLS to identify data link ends. There may be some value in
> > stressing that a GMPLS link end is supported by exactly one
> > trail termination. When several trail terminations are
> > involved, we can still talk about single TE link (as a
> > bundle), but each component link will be a distinct data
> > link. We think that in ASON the SNPP (TE link in GMPLS
> > language) could be supported by multiple terminations.
> > 3. Link interfaces (section 3.6 - was 3.5)
> > The new text from Q12/15 gives us...
> > A GMPLS interface is "all the stuff between a physical
> > interface and a matrix in an ASON network element." More
> > precisely, it is a trail termination function and adaptation
> > function for which adapted client layer connection points
> > are bound to a matrix.
> > We think "physical interface" may be ambiguous in the multi-
> > layer context. We think the "stuff" should be between a link
> > and a matrix, since we are talking about links in distinct
> > layers.
> > In addition to your feedback on the specific points above, we would
> > welcome your continued comments and review of the Internet-Draft.
> > Regards,
> > Adrian Farrel and Kireeti Kompella
> > IETF CCAMP Working Group Co-chairs