Re: Proposed response to ITU-T SG15 Questions 12 and 14 on ASON Lexicography

["Tom Petch" <nwnetworks@dial.pipex.com>]

Adrian

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, not
just its terms:-)

Tom Petch

----- Original Message -----
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <ccamp@ops.ietf.org>
Cc: "'Kireeti Kompella'" <kireeti@juniper.net>; <zinin@psg.com>; "Bill Fenner"
<fenner@research.att.com>; "Scott Bradner" <sob@harvard.edu>
Sent: Tuesday, July 19, 2005 1:59 PM
Subject: Proposed response to ITU-T SG15 Questions 12 and 14 on ASON
Lexicography


> Hi,
>
> Please comment on this draft response liaison which I intend to send on
> 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 Questions
> 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 or as
> mark-ups to the Internet-Draft has been incorporated into the latest
> revision which is available at
>
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-03.
txt
>
> In your liaison you state some assumptions which we would like to comment
> 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 progress)
>
> While the definition of GMPLS terms would be helpful for understanding
> GMPLS terms in a GMPLS context, that is not the purpose of this document.
>
> - 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 on
> these descriptions, but based on the full meaning of the GMPLS terms. The
> descriptions of the GMPLS terms are provided in this Internet-Draft for
> context and a brief summary.
>
> - CCAMP has primarily responsibility for the descriptions of GMPLS terms
>
> 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 input to
> the Internet-Draft. While the Internet-Draft remains under the overall
> editorial control of the CCAMP working group, we hope to be able to use
> 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 on
> 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 specific
> 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 taking
> the opportunity to restate several questions here for your convenience and
> 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
>
>