Subject: AD-review comments on draft-ietf-ccamp-gmpls-g709

From: Alex Zinin <[email-masked]>
Date: Fri, 27 Aug 2004 12:50:59 -0700

Adrian, Kireeti, Dimitri-

Please find comments below. I'd like to understand the answer to the meta
question before sending this to the WG.

Thanks.

Alex

Meta: this draft talks about the signaling component, what about
      the routing part of the story?

Ed: please use the new ID boilerplates

> 3.1.1 LSP Encoding Type
...
> 
>    Therefore, the current "Digital Wrapper" code-point defined in
>    [RFC3471] can be replaced by two separate code-points:

What does "replaced" mean here?

>        - code-point for the G.709 Digital Path layer
>        - code-point for the non-standard Digital Wrapper layer
> 
> 
>    In the same way, two separate code-points can replace the current
>    defined "Lambda" code-point:
>       - code-point for the G.709 Optical Channel layer
>       - code-point for the non-standard Lambda layer (also referred to
>         as Lambda layer which includes the pre-OTN Optical Channel
>         layer)

ditto

>    Consequently, the following additional code-points for the LSP
>    Encoding Type are defined:
> 
> 
>         Value           Type
>         -----           ----
>          12             G.709 ODUk (Digital Path)
>          13             G.709 Optical Channel
> 
> 
>    Moreover, the code-point for the G.709 Optical Channel (OCh) layer
>    will indicate the capability of an end-system to use the G.709 non-
>    associated overhead (naOH) i.e. the OTM Overhead Signal (OOS)
>    multiplexed into the OTM-n.m interface signal.

Given we're talking about label request parameters here, how could a value
in the requested LSP type indicate a capability?

> 3.1.2 Switching Type
...
>    Moreover, in a strict layered G.709 network, when a downstream node
>    receives a Generalized Label Request including one of these values
>    for the Switching Type field, this value SHOULD be ignored.

What about other values? Should the field be ignored all together?

> 4.1 ODUk Label Space
...
>    1. t1 (1-bit):
>         - t1=1 indicates an ODU1 signal.
>         - t1 is not significant for the other ODUk signal types (t1=0).

"not significant" meaning it should be set to 0?

> 
>    2. t2 (3-bit):
>         - t2=1 indicates an ODU2 signal that is not further sub-
>           divided.
>         - t2=2->5 indicates the tributary slot (t2th-2) used by the
>           ODU1 in an ODTUG2 mapped into an ODU2 (via OPU2).
>         - t2 is not significant for an ODU3 (t2=0).

ditto

> 
>    3. t3 (6-bit):
>         - t3=1 indicates an ODU3 signal that is not further sub-
> 
> 
> D.Papadimitriou (Editor) et al. - Expires September 2004            10
> draft-ietf-ccamp-gmpls-g709-07.txt                           March 2004
> 
> 
> 
>           divided.
>         - t3=2->17 indicates the tributary slot (t3th-1) used by the
>           ODU1 in an ODTUG3 mapped into an ODU3 (via OPU3).
>         - t3=18->33 indicates the tributary slot (t3th-17) used by the
>           ODU2 in an ODTUG3 mapped into an ODU3 (via OPU3).

Ed: value ranges would be easier to read if put as "[n..m]"

> 
>    Note: in case of ODU2 into ODU3 multiplexing, 4 labels are required
>    to identify the 4 tributary slots used by the ODU2; these tributary
>    time slots have to be allocated in ascending order.

The section should define the behavior of the receiver for the cases
where e.g. both t1 and t2 are !=0.

> 
> 4.2 Label Distribution Rules
> 

This section below talks about lists of labels and sets of labels, however
it does not clarify how those are encoded.

>    In case of ODUk in OTUk mapping, only one of label can appear in the
>    Generalized Label.
> 
> 
>    In case of ODUj in ODUk (k > j) multiplexing, the explicit ordered
>    list of the labels in the multiplex is given (this list can be
>    restricted to only one label when NMC = 1). Each label indicates a
>    component (ODUj tributary slot) of the multiplexed signal. The order
>    of the labels must reflect the order of the ODUj into the multiplex
>    (not the physical order of tributary slots).
> 
> 
>    In case of ODUk virtual concatenation, the explicit ordered list of
>    all labels in the concatenation is given. Each label indicates a
>    component of the virtually concatenated signal. The order of the
>    labels must reflect the order of the ODUk to concatenate (not the
>    physical order of time-slots). This representation limits virtual
>    concatenation to remain within a single (component) link. In case of
>    multiplexed virtually concatenated signals, the first set of labels
>    indicates the components (ODUj tributary slots) of the first
>    virtually concatenated signal, the second set of labels indicates
>    the components (ODUj tributary slots) of the second virtually
>    concatenated signal, and so on.
> 
> 
>    In case of multiplication (i.e. when using the MT field), the
>    explicit ordered list of all labels taking part in the composed
> 
> 
> D.Papadimitriou (Editor) et al. - Expires September 2004            11
> draft-ietf-ccamp-gmpls-g709-07.txt                           March 2004
> 
> 
> 
>    signal is given. The above representation limits multiplication to
>    remain within a single (component) link. In case of multiplication
>    of multiplexed/virtually concatenated signals, the first set of
>    labels indicates the components of the first multiplexed/virtually
>    concatenated signal, the second set of labels indicates components
>    of the second multiplexed/virtually concatenated signal, and so on.

> 8. IANA Considerations
> 
> 
>    Two values have to be defined by IANA for this document:
> 
> 
>    Two RSVP C-Types in registry:
> 
> 
>              http://www.iana.org/assignments/rsvp-parameters
> 
> 
>              - A G.709 SENDER_TSPEC object: Class = 12, C-Type = 5
>                (Suggested value, TBA) - see Section 6.
> 
> 
>              - A G.709 FLOWSPEC object: Class = 9, C-Type = 5
>                (Suggested value, TBA) - see Section 6.
> 
>
>    IANA is also requested to track the code-point spaces extended
>    and/or updated by this document. That is:
>    - LSP Encoding Type
>    - Generalized PID (G-PID)

What does the last para mean to IANA? Is this a request to create
new registries? If so, more info needs to be given, e.g.:

 - name of the registry
 - format
 - allocation policy
 - initial values

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 28 Aug 2004 12:18:34 +0100

Thanks Alex,

Some comments in-line. Dimitri will probably want to comment, too.

A couple of editorial nits.
- Please run the IDnits script over the draft to clean it up.
- Please insert page break characters.

Cheers,
Adrian

>       the routing part of the story?

No different to any G-PID or encoding type. That is, end-point capabilities are not
currently advertised in GMPLS routing. Some people see this as a failing, others say that
since you are attempting to open an end-to-end connection, you are presumably trying to
contact a known (called) party and it would be usual to have either:
- some understanding of the capablities of the person you are trying to reach
or
- limited capablities, yourself.

Anyway, this draft is simply extending the list of encodings and G-PIDs to cover G.709.
Endocings and G-PIDs are signaled quantites that are not advertised.

> What does "replaced" mean here?

Good question. Presume that we can't obsolete "Digital Wrapper" without some care. So we
need text to describe how it is handled.

> in the requested LSP type indicate a capability?

"Requested capability"

> it does not clarify how those are encoded.

Yup. There is precedent and "common knowledge" for how concatenated labels are encoded,
but I think Alex is right that this draft should re-state the point for clarity and
consistency.

> new registries? If so, more info needs to be given, e.g.:

Hmmm. Probably my fault since I asked for this.
Encodigng type and G-PID would, indeed, be two new registries. Primarily they are defined
in RFC3471, but this draft introduces some new values and the values should be tracked and
monitored.

So, yes, this is a request for two new registries. The info provided to IANA should also
point at all existing definitions.

---

From: dimitri papadimitriou <[email-masked]>
Date: Sat, 28 Aug 2004 18:24:23 +0200

alex, adrian,

> Some comments in-line. Dimitri will probably want to comment, too.

thanks for the input, here below a bunch of additional comments

> Endocings and G-PIDs are signaled quantites that are not advertised.

as for sdh/sonet a couple of technology specific extensions where 
initiated early 2000 and took a more stable form end of 2002, that would 
have taken one of the following form: add. sub-TLV or extension of the 
technology specific part of the ISC sub-TLV descriptor for intra-domain 
TE and that would have included specific  end-point capabilities, 
however since so far they've never been considered as working group item 
(stayed at the individual submission level)

note: G-PIDs are not advertized but encodings are as part of the ISC sub-TLV

> need text to describe how it is handled.

here the issue is a timing problem, as G.709 was issued by the time  RFC 
3471 went out, combined with a formulation problem, as we can safely 
assume that the digital wrappers that were already available by that 
time were not fully G.709 compliant -> so it would be better to speak 
about a rename of the existing RFC 3471 value and add-on of a new value

>>in the requested LSP type indicate a capability?

it is part of the "data plane" assignment to dedicate a channel 
multiplexed into the bearier signal for the non-associated overhead 
transport, so it is as indicated by adrian part of the "request"

>>What about other values? Should the field be ignored all together?

the "field" SHOULD be ignored, if not (and in this case, thus simply 
used as an indication of the LSP class), the value of this field MUST be 
either of type TDM or LSC depending of the Signal Type value

>>"not significant" meaning it should be set to 0?

true, in this case "t1 SHOULD be set to 0"

>>>        - t2 is not significant for an ODU3 (t2=0).

true, in this case "t2 SHOULD be set to 0"

>>Ed: value ranges would be easier to read if put as "[n..m]"

ok

> but I think Alex is right that this draft should re-state the point for clarity and

see below

>>>   In case of ODUk in OTUk mapping, only one of label can appear in the

add "The unique is encoded as single 32 bit label value (as defined in 
Section 4.1) of the GENERALIZED_LABEL object (Class-Num = 16, C-Type = 2)"

>>>   (not the physical order of tributary slots).

add "This ordered list of labels is encoded a sequence of 32 bit label 
values (as defined in Section 4.1) of the GENERALIZED_LABEL object 
(Class-Num = 16, C-Type = 2)"

ditto

ditto

> point at all existing definitions.

in this case, i would also then suggest to create an entry for the 
switching type values the document will include the required information 
for each of them

thanks,
- dimitri.

---

From: Alex Zinin <[email-masked]>
Date: Tue, 31 Aug 2004 16:14:33 -0700

Dimitri, Adrian-

> note: G-PIDs are not advertized but encodings are as part of the ISC sub-TLV

To make sure we have the bottom line right: is the routing part a required
piece for the implementations of gmpls-g709 to interoperate?

> about a rename of the existing RFC 3471 value and add-on of a new value

The question here is whether the original "Digital Wrapper" code point
has been used or not, and how safe it is change the semantics vs defining
a new value for g.709.

> either of type TDM or LSC depending of the Signal Type value

Well, you guys need to pick whether you're going to ask the implementor
to ignore the field, or to check it for a specific value. In the latter
case, you also need to specify what to do if the check fails.

> ditto

Pardon if I sound ignorant... Are both sets (the first and the second) encoded
together in the same GEN_LABEL object? How does one tell "the first set of
labels" from "the second"?

> switching type values the document will include the required information 

As long as we provide proper instructions to IANA--I'm fine.

Thanks.

Alex

---

From: dimitri papadimitriou <[email-masked]>
Date: Wed, 01 Sep 2004 11:50:00 +0200

> piece for the implementations of gmpls-g709 to interoperate?

there is no additional TE routing information exchange strictly 
*required* from what has been already provided in GMPLS routing to 
interoperate (also one can make use of signaling part without any TE 
routing exchange as long as the corresponding information is made 
available by other means)

> has been used or not, and how safe it is change the semantics vs defining

it has been already used for proprietary implementations of the wrapper 
layer, this is why a new value has been proposed to not jeopardize them

> case, you also need to specify what to do if the check fails.

in trying to address the discussion point, i would suggest the following 
text for this section (in compliance with RFC 3473 - note: it is 
impossible for a given implementation to encompass all the different 
pieces of processing that have been devised over years for this field) 
so picking up the following is the most straightforward:

"The Switching Type indicates the type of switching that should be
performed at the termination of a particular link (see [GMPLS-RTG]).

Here, no additional Switching Type values are to be considered in order 
to accommodate G.709 switching types since an ODUk switching (and so
LSPs) belongs to the TDM class while an OCh switching (and so LSPs)
to the Lambda class (i.e. LSC).

Intermediate and egress nodes MUST verify that the value indicated in 
the Switching Type field is supported on the corresponding incoming 
interface. If the requested value can not be supported, the node MUST 
generate a PathErr message with a "Routing problem/Switching Type" 
indication."

add "This ordered list of labels is encoded a sequence of 32 bit label 
values (as defined in Section 4.1) of the GENERALIZED_LABEL object 
(Class-Num = 16, C-Type = 2). In case of ODUk virtual concatenation, the 
number of label values is determined by the NVC value. Multiplexed ODUk 
virtual concatenation additionally uses the NMC value to determine the 
number of labels per set (equal in size)."

> labels" from "the second"?

alex, sensible question does also apply to the previous case

add "This ordered list of labels is encoded a sequence of 32 bit label 
values (as defined in Section 4.1) of the GENERALIZED_LABEL object 
(Class-Num = 16, C-Type = 2). In case of multiplication of (equal) ODUk 
virtual concatenated signals, the number of label values per signal is 
determined by the NVC value. Multiplication of (equal) multiplexed ODUk 
virtual concatenation additionally uses the NMC value to determine the 
number of labels per set (equal in size)."

> As long as we provide proper instructions to IANA--I'm fine.

ok - will do so in the updated version

thanks,
- dimitri.

---

From: dimitri papadimitriou <[email-masked]>
Date: Sun, 12 Sep 2004 14:19:29 +0200

hi alex, adrian, would it be possible to know whether the below 
responses address the review comments so that i can issue a new version 
of this document (and move forward) ?

thanks,
- dimitri.

-----

thanks,
- dimitri.

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 18 Sep 2004 13:47:59 +0100

Dimitri,

> of this document (and move forward) ?

Small comments in line.

Thanks for pushing on with this. Please make your updates and re-publish.

Cheers,
Adrian

> available by other means)

I think we can say something slightly stronger.
GMPLS-G.709 implementations will successfully interoperate without further additions to
GMPLS routing.

The issue of end-point capabilities is related, but not a dependency.
Further, the issue of end-point capablities extends across the whole of GMPLS, and is not
limited to G.709.
Thus, this draft brings G.709 up to the same level as many other GMPLS-related
technologies.

> layer, this is why a new value has been proposed to not jeopardize them

Good.
OK, please don't say "replace".
Instead, please use text that describes the behavior with all three values.
- Never generate old value.
- What to do when receiving old value.

> generate a PathErr message with a "Routing problem/Switching Type"

That looks good.

> number of labels per set (equal in size)."

Good.

> number of labels per set (equal in size)."

OK

---

From: dimitri papadimitriou <[email-masked]>
Date: Sun, 19 Sep 2004 13:16:59 +0200

hi adrian, thanks for the pointers here below - i will provide the 
update and re-submit

thanks,
- dimitri.

Adrian Farrel wrote:

>>>>>currently advertised in GMPLS routing. Some people see this as a failing, others say
> 
> that
> 
>>>>>since you are attempting to open an end-to-end connection, you are presumably trying
> 
> to
> 
>>>>>Anyway, this draft is simply extending the list of encodings and G-PIDs to cover
> 
> G.709.
> 
>>>>>Good question. Presume that we can't obsolete "Digital Wrapper" without some care. So
> 
> we
> 
>>>>>Encodigng type and G-PID would, indeed, be two new registries. Primarily they are
> 
> defined
> 
>>>>>in RFC3471, but this draft introduces some new values and the values should be
> 
> tracked and
> 
>>>>>monitored.
>>>>>
>>>>>So, yes, this is a request for two new registries. The info provided to IANA should
> 
> also
> 
> .