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

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

Tom,

I don't think it is CCAMP's role to correct the English of another SDO :-)

Thanks,
Adrian
----- Original Message ----- 
From: "Tom Petch" <nwnetworks@dial.pipex.com>
To: "Adrian Farrel" <adrian@olddog.co.uk>; <ccamp@ops.ietf.org>
Sent: Tuesday, July 19, 2005 7:18 PM
Subject: Re: Proposed response to ITU-T SG15 Questions 12 and 14 on ASON
Lexicography


> 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
> >
> >
>
>
>
>