Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control
draft-ietf-ccamp-gmpls-g709-09

IANA Comments:
Upon approval of this document the IANA will register 2 RSVP C-Types.
There is also some code point tracking, however it is not clear in which registries these are located.  Or if they are new, where should they be located? Clarification for the IANA is needed.

[Ballot comment]
For clarity, all the documents should reference Extra Data as
in the terminology doc  (they vary among Extra data, extra-data, Extra Data,
and extra data) and the first use of the term should reference the terminology
doc.

[Ballot comment]
Reviewed by Spencer Dawkins, Gen-ART

His review:

This document is almost ready for publication as Proposed Standard. I
have one question, in 4.1:


- In 4.1, some of the "not significant" bits "SHOULD be set to 0" -
  don't we usually "MUST be set to 0, SHOULD ignore on receipt" in
  similar cases?

Minor Nits:

- The first paragraph of section 2 dumps a BUNCH of unexpanded
  acronyms on the reader! Some are expanded two or three sentences
  later, but the effect is confusing. Maybe a list of acronyms and
  expansions as part of the first sentence? I hate to inflict a
  request for ASCII art on the editor at last call time, but if these
  entities could be presented as a protocol stack (at least some are
  described as "protocol layers"), that would help, too.

- In 4.2, s/only one of label can appear/only one label can appear/

Spencer got feedback from the authors; from the dialogue, I conclude that the issues are not show-stoppers.

[Ballot discuss]
Assignments for G-PID in this doc seem to update RFC3471,
which says (page 9):
      Generalized PID (G-PID): 16 bits
  Value  Type                                  Technology
  -----  ----                                  ----------
    0    Unknown                                All
    ...
    32    ATM mapping                            SDH
    33    Ethernet                              SDH, Lambda, Fiber
    34    SONET/SDH                              Lambda, Fiber
    35    Reserved (SONET deprecated)            Lambda, Fiber

while this document claims:
  The following table summarizes the update of the G-PID values
  defined in [RFC3471]:

  Value    G-PID Type                LSP Encoding Type
  -----    ----------                -----------------
    32      ATM Mapping                SDH, G.709 ODUk
    33      Ethernet PHY              SDH, G.709 OCh, Lambda, Fiber
    34      Sonet/SDH                  G.709 OCh, Lambda, Fiber
    35      Reserved (SONET Dep.)      G.709 OCh, Lambda, Fiber

So should this doc have a "Updates RFC3471" tag on front page?

It would at least be good to state in the IANA considerations that the values
32-35 have been Updated by this doc as opposed to claim "defined in sec 3.1.3"

This doc is also updating the "IANA assignment policy" for multipel namespaces
defined in RFC3471, so that is another reason to make it clear that this doc "Upates RFC3471".

----

It would be good to have an explicit statement that this doc has been reviewed by the appropriate ITU-T studygroup (is it 15?)

[Ballot comment]
In Section 3.2.1, the draft gives the following table:

3.2.1 Signal Type (ST)

  This field (8 bits) indicates the type of G.709 Elementary Signal
  that comprises the requested LSP. The permitted values are:

    Value    Type
      -----    ----
        0      Irrelevant
        1      ODU1 (i.e. 2.5 Gbps) 
        2      ODU2 (i.e. 10  Gbps)   
        3      ODU3 (i.e. 40  Gbps)
        4      Reserved (for future use) 
        5      Reserved (for future use)
        6      OCh at 2.5 Gbps
        7      OCh at 10  Gbps 
        8      OCh at 40  Gbps
        9-255  Reserved (for future use)

This does not seem to match anything in the IANA consideration section;
I assume this is because these are defined by the ITU spec.  It might be
worth making that explicit; I believe we also tend to use "ignored" rather
than irrelevant.

[Ballot comment]
If revisions are required, section 3.1 should gain an explanation of
why a technology-dependent spec needs to revise the
technology-independent part of GMPLS.  I assume there is a good reason
for this and so will not hold up the document only on this issue.

[Ballot comment]
Please move the note about not replicating the content of the ITU-T
  OTN Recommendations in this document out of the abstract.  Please
  put it the introduction.

  Section 7 says:
  >   
  > This draft introduces no new security considerations to [RFC3473].
  > GMPLS security is described in section 11 of [RFC3471] and refers
  > to [RFC3209] for RSVP-TE.
  >
  The first reference is needed.  However, references to RFC 3471 and
  RFC 3209 are quite indirect.  The security considerations in these
  documents point to other documents without adding much else.  Perhaps
  the level of indirection can be removed.

[Ballot comment]
Please move the note about not replicating the content of the ITU-T
  OTN Recommendations in this document out of the abstract.  Please
  put it the introduction.

  Section 7 says:
  >   
  > This draft introduces no new security considerations to [RFC3473].
  > GMPLS security is described in section 11 of [RFC3471] and refers
  > to [RFC3209] for RSVP-TE.
  >
  The first reference is needed.  However, references to RFC 3471 and
  RFC 3209 are quite indirect.  The security considerations in these
  documents point to other dicuments without adding much else.  Perhaps
  the level of indirection can be removed.

AD-review comments sent to the WG chairs:

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