Re: I-D ACTION:draft-ietf-ccamp-gmpls-ason-lexicography-05.txt (fwd)

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

Hi,

>>> 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."
>
> [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

OK. I misunderstood your concern. I thought you were objecting to the
notation and habit of assigning a term to a specific plane. It appears
that you are more concerned that we have used a phrase not common in the
GMPLS RFCs and assigned it as the main terminology.

To handle that specific case we will rewrite the first sentence of 3.7.1
    "In GMPLS a connection is known as a Label Switched Path (LSP)"
to provide a definition of LSP (noting that there is no neat and tidy
definition that is applicable in 3031 or 3945.

Do you have any other specific cases?

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

OK. So this is the same point as before.

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

No, I don't see that text. I do see where it says that
   LSPs created in
   lower layers for the purpose of providing data links (extra network
   flexibility) in higher layers are called hierarchical connections
   or LSPs (H-LSPs)
That says that an H-LSP is a data link in a higher layer. But what is an
H-LSP in the layer where it is found? It is a trail.

> [dp] in brief, what i mean is that i find that for the "GMPLS reader"
> the reverse reading quite difficult

Right. But it is not supposed to provide the reverse reading.
This question has been discussed several times and in several places. Just
as bilingual dictionaries are published in two volumes, so we would be
open to the publication of a reverse direction lexicography if anyone
wants to work on it.
Several people have even suggested that the correct place for that work is
in the ITU-T since its purpose would be to "explain" ASON terminology to
the GMPLS-world.

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

History is being made! We are still dealing with early deployments. This
document, however, will live somewhat longer.

I will remove refernce to time from the text.

>> Would it help if we had a separate entry for LSR?
>
> [dp] yes

Done.

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

I really don't see a significant problem here.

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

Yes.
Done.

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

No. Swithiching is not termination, it is switching.

It is true that the lambda flow is terminated at this point, but not that
the content is delivered, rather that the content goes on being switched.
So this is a very limited form of expressing termination and, as you say,
it is implicit (I would rather say incidental).

The more common case is surely the last link in an LSP where there is no
continued switching of the content, but the data is delivered to another
layer or to an application. This termination capability is not currently
advertised.

As I said before...

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

Thanks,
Adrian