[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[what's this?] was Re: I-D ACTION:draft-ietf-ccamp-gmpls-ason-lexicography-05.txt (fwd)
The use of brackets puzzled me for a while; nothing wrong with it as a
convention but I would suggest explaining it in a Conventions section somewhere
early on - and yes, I would change from
[] to {} or <> or ...
Tom Petch
----- Original Message -----
From: <Dimitri.Papadimitriou@alcatel.be>
To: "Adrian Farrel" <adrian@olddog.co.uk>
Cc: "Kireeti Kompella" <kireeti@juniper.net>; "Dimitri Papadimitriou"
<Dimitri.Papadimitriou@alcatel.be>; <ccamp@ops.ietf.org>
Sent: Saturday, December 17, 2005 11:57 AM
Subject: Re: I-D ACTION:draft-ietf-ccamp-gmpls-ason-lexicography-05.txt (fwd)
> hi adrian
>
> Thanks for reading.
>
> > 1. i still don't understand the need for the [ ... ] after each term -
> if
> > authors could clarify this would be helpful
>
> Hmm. Well the intention was to provide extra information in a quick way. I
> guess we could replace each [...] with a full sentence such as "This term
> applies to the control plane."
>
> I suppose that the RFC editor is going to object to our use of square
> brackets :-(
>
>
> [dp] my confusion is where it is for inst. listed in Section 3.7.1
>
> "Unidirectional connection (LSP) [data plane]" the term in GMPLS is
"Unidirectional LSP" while there is a non-GMPLS term as part of the term the
text introduces, i don't see anymore whether the text in brackets refers to as
an LSP is a representation of a data plane connection (or whatever term is
suitable here)
>
> [dp] i think in general that the GMPLS term that are listed for clarification
should make use of their exact denomination
>
>
> > 2. in general, i don't see why this document meant to clarify GMPLS
> > terms for ASON includes ASON specific terms/definitions and interpretations
> > hence the need for each "ASON terms" sub-section is unclear
>
> The intention is not just to clarify the GMPLS terms, but also to provide
> a mapping. The full purpose (of making GMPLS comprehensible to ASON
> cognoscenti) is aided by the inclusion of corresponding ASON terms. What
> we have done, therefore, is split the text into:
> - a description of the GMPLS term
> - a translation into "equivalent" ASON terms
>
> Do you have an objection to this?
>
> [dp] let's take the example of Section 3.7.2 "A GMPLS connection is an ASON
network connection" the notion of "ASON network connection" is probably
correctly interpreted if you make use of the term "GMPLS connection"
>
> [dp] the other aspect is also the "equivalence" notion leads to things a
"H-LSP is a trail" probably but the whole text coming earlier in the document
seem to refer to it as a "link"
>
> [dp] in brief, what i mean is that i find that for the "GMPLS reader" the
reverse reading quite difficult
>
> > some other specifics
> >
> > 3. " Node [Control & Data Planes] is a logical combination of a
> > transport node and the controller that manages the transport node.
> > In early deployments, all control plane and data plane functions
> > associated with a transport node were collocated in a node and
> > referred to as a Label Switching Router (LSR)."
> >
> > the second sentence is imho outside the scope of such definition
>
> Some of the GMPLS RFCs are simplified by the use of "LSR", but it has been
> pointed out on numerous occasions that this creates an impression that in
> GMPLS there is *always* a tight binding (collocation) between control and
> data plane functions. As you know, this impression is contrary to reality.
>
> A couple of questions back to you.
>
> Is what it says incorrect?
>
> [dp] yes, current deployments still make use of what you seem to refer to as
history ("in early deployments")
>
>
> Would it help if we had a separate entry for LSR?
>
> [dp] yes
>
> > 4. "3.4.1. GMPLS Terms
> >
> > Label [Control Plane] is an abstraction that provides an identifier
> > for use in the control plane in order to identify a transport plane
> > resource."
> >
> > how to interpreet an MPLS label with this definition ? or is MPLS out of
> > scope ?
>
> MPLS is out of scope because there is possible translation to ASON.
>
> Note, however, we felt it helpful to include "Packet based resource"
>
> [dp] this is also what i understood but it seems that closing the ring of
definition and interpretations is impossible; hence, my suggestion either to
have a complete definition of packet-related interpretation or no coverage at
all
>
> > 5. "3.5.1. GMPLS Terms
> >
> > Unidirectional data link end [Data Plane] is a set of resources of a
> > particular layer that belong to the same transport node and could
> > be allocated for the transfer of traffic in this layer to the same
> > neighbor in the same direction."
> >
> > what "same transport node" means here ?
>
> Erm?
>
> It means "same transport node" :-)
>
> The intention is to imply that all of the resources in the set belong to
> the same transport node.
>
> Maybe rephrase as:
>
>
> Unidirectional data link end [Data Plane] is a set of resources that
> all belong to the same transport node, all are in the same layer,
> and that could be allocated for the transfer of traffic in this
> layer to the same neighbor in the same direction."
>
>
> [dp] ok (guess you will align subsequent text along the same line)
>
>
>
> > 6. " The need for advertisement of adaptation and termination
> capabilities
> > within GMPLS has been recognized and work is in progress to determine
> > how these will be advertised. It is likely that they will be
> > advertised as a single combined attribute, or as separate attributes
> > of the TE link local end associated with the link interface."
> >
> > afaik, GMPLS is able to advertize "termination" capabilities -
>
> Does it?
>
>
>
> [dp] yes but implicitly when you have a [LSC,PSC] TE link, meaning one side
says in its interface SC descriptor TLV PSC and the other LSC, it implicitly
means the "PSC side" terminates LSC and switches at the PSC level
>
>
> It seems to me that it advertizes switching capabilities only.
> Termination, like adaptation, is not the same thing as switching
> capability.
>
> Switching capability says how the link terminates, but not whether the
> node can terminate data flows.
>
> Cheers,
> Adrian
>
>
>
>
>
>