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

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

<inline>
Tom Petch
----- Original Message -----
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "Tom Petch" <nwnetworks@dial.pipex.com>; <ccamp@ops.ietf.org>
Sent: Wednesday, July 20, 2005 11:54 AM
Subject: Re: Proposed response to ITU-T SG15 Questions 12 and 14 on ASON
Lexicography


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

OK, but then I do not think you should reply "Correct" because IMHO it is not
correct; the response should be something about what, primarily, CCAMP is
responsible for:-)

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