[CCAMP] RtgDir Review: "Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN Networks"

[Acee Lindem <[e-mail]>]

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please seehttp://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-ccamp-ospf-g709v3-09.txt
Reviewer: Acee Lindem
Review Date: October 15th, 2013
IETF LC End Date: October 16, 2013
Intended Status: Proposed Standard

Summary: The document is missing some key sections and requires some clarification prior to publication.

Comments:

Major Issues: The document lacks several critical pieces of information.

                 1. There is no discussion of OSPF scaling or flooding frequency. Even if it not expected that G709
                      GMPLS signaling will not present any problems, this needs to be stated and justified. Refer to
                      section 8 in RFC 6827 for an example of such a discussion.
                 2. The document includes lots of normative text indicating precisely how sub-TLVs MUST be
                      formatted. However, there is no indication of what the action to be taken if the TLVs do
                      not follow the strict conventions.
                 3. The document jumps down into details of G.709 technology without adequate
                       explanation (particularly in the examples). Either these details need to be removed or a
                      statement of prerequisite knowledge is required.

Minor Issues: The document had a large number of editorial errors.

                 1. The bit numbering on all the figures was off by 1 column. If you look at RFC 4203,
                      this will be obvious.
                 2. The table on page 7 is incomprehensible with the given columns and headings. Spaces
                      rather than commas in numbers are annoying.
                 3. The distinction between TLVs and sub-TLVs is not consistent throughout the document.
                      Again, refer to RFC 6827 for an example of consistent referral.
                 4. Figures 8 and 9 have the T and S fields offset from the bit numbering. Also, it took
                      some time to realize that T1 meant a value of 1.
                 5. Figures 11-15 are very inconsistent in that these are examples yet the values for T, S, and
                      sometime TSG are not specified. Rather, the example includes the letters.
                 6. Security section - RFC 2154 is an experimental RFC that has heretofore never been
                      commercially implemented or deployed. It is time to quit referencing it in draft
                      "Security Considerations".

  Nits:
                 1. The proper punctuation is "i.e., " and "e.g. ,".  Also, sentences should not start with either.
                      See http://www.rfc-editor.org/rfc-style-guide/rfc-style
                 2. Page 7, "Switching Capability-Specific Information (SCSI)?
                 3. Suggest formatting the document so that the figures are on separate pages rather than
                      split across pages.
                 4. Replace all occurrences of "non " with "non-" and do not end lines with "non ".
                 5. I thought the examples included many run-on sentences that were hard to parse and lacked
                      needed punctuation. I tried to edit but I'm not even sure if I retained the same meaning. You
                      can get a flavor for what I mean by the diffs below.

Thanks,
Acee
132,133c132,133
<    Routing information for Optical Channel Layer (OCh) (i.e. wavelength)
<    is out of the scope of this document.  Please refer to [RFC6163] and
---
>    Routing information for Optical Channel Layer (OCh) (i.e., wavelength)
>    is beyond the scope of this document.  Please refer to [RFC6163] and
157c157
<    As discussed in [OTN-FWK] and [OTN-INFO], OSPF-TE must be extended so
---
>    As discussed in [OTN-FWK] and [OTN-INFO], OSPF-TE must be extended
159c159
<    related to each different ODUj and ODUk/OTUk (Optical Transport Unit)
---
>    of each different ODUj and ODUk/OTUk (Optical Transport Unit)
176c176
<    In the following we will use ODUj to indicate a service type that is
---
>    In the following, we will use ODUj to indicate a service type that is
179c179
<    the OTUk.  Moreover ODUj(S) and ODUk(S) are used to indicate ODUj and
---
>    the OTUk.  Moreover, ODUj(S) and ODUk(S) are used to indicate ODUj and
184c184
<    multiplexing levels.  In the following the term "multiplexing tree"
---
>    multiplexing levels.  In the following, the term "multiplexing tree"
191c191
<    If for example a multiplexing hierarchy like the following one is
---
>    For example, If a multiplexing hierarchy like the following one is
251c251
<    one hop case multiple hop TE-links advertise ODU switching capacity.
---
>    one hop case, multiple hop TE-links advertise ODU switching capacity.
296,297c296,297
<    Both for fixed and flexible ODUs the same switching type and encoding
<    values MUST be used.  When Switching Capability and Encoding fields
---
>    The same switching type and encoding values must be used for both fixed
>    and flexible ODUs.  When Switching Capability and Encoding fields
303,304c303,304
<    The MAX LSP Bandwidth field is used according to [RFC4203]: i.e. 0 <=
<    MAX LSP Bandwidth <= ODUk/OTUk and intermediate values are those on
---
>    The MAX LSP Bandwidth field is used according to [RFC4203]: i.e., 0 <=
>    MAX LSP Bandwidth <= ODUk/OTUk, and intermediate values are those on
306,307c306,307
<    E.g. in the OTU4 link it could be possible to have ODU4 as MAX LSP
<    Bandwidth for some priorities, ODU3 for others, ODU2 for some others
---
>    For example, in the OTU4 link it could be possible to have ODU4 as MAX LSP
>    Bandwidth for some priorities, ODU3 for others, ODU2 for some others,
397,398c397,398
<    Procedure-Frame mapped (GFP-F) resizable and 22 - ODUflex (GFP-F) non
<    resizable.  Each MUST always be advertised in separate Type 2 TLVs as
---
>    Procedure-Frame mapped (GFP-F) resizable and 22 - ODUflex (GFP-F)
>    non-resizable.  Each MUST always be advertised in separate Type 2 TLVs as
400c400
<    both GFP-F resizable and non resizable (i.e. 21 and 22) are
---
>    both GFP-F resizable and non-resizable (i.e. 21 and 22) are
535c535
<       (i.e. a non OTN client).
---
>       (i.e., a non-OTN client).
540c540
<       - Priority (8 bits): a bitmap used to indicate which priorities
---
>       - Priority (8 bits): A bitmap used to indicate which priorities
542,543c542,543
<       leftmost bit representing priority level 0 (i.e. the highest) and
<       the rightmost bit representing priority level 7 (i.e. the lowest).
---
>       leftmost bit representing priority level 0 (i.e., the highest) and
>       the rightmost bit representing priority level 7 (i.e., the lowest).
666c666
<       Figure 5: Example 1 - MAX LSP Bandwidth fields in the ISCD @T0
---
>       Figure 5: Example 1 - MAX LSP Bandwidth fields in the ISCD at T0
676,678c676,678
<    At time T1 an ODU3 at priority 2 is set-up, so for priority 0 the MAX
<    LSP Bandwidth is still equal to the ODU4 bandwidth, while for
<    priorities from 2 to 7 (excluding the non supported ones) the MAX LSP
---
>    At time T1, an ODU3 at priority 2 is set-up, so for priority 0 the
>    MAX LSP Bandwidth is still equal to the ODU4 bandwidth, while for
>    priorities from 2 to 7 (excluding the non-supported ones) the MAX LSP
680c680
<    next supported ODUj in the hierarchy is ODU3.The advertisement is
---
>    next supported ODUj in the hierarchy is ODU3. The advertisement is
710c710
<       Figure 6: Example 1 - MAX LSP Bandwidth fields in the ISCD @T1
---
>       Figure 6: Example 1 - MAX LSP Bandwidth fields in the ISCD at T1
712,714c712,714
<    At time T2 an ODU2 at priority 4 is set-up.  The first ODU3 is no
<    longer available since T1 as it was kept by the ODU3 LSP, while the
<    second is no more available and just 3 ODU2 are left in it.  ODU2 is
---
>    At time T2, an ODU2 at priority 4 is set-up.  The first ODU3 is no
>    longer available since T1, as it was kept by the ODU3 LSP, while the
>    second is no more available and just 3 ODU2s are left in it.  ODU2 is
758c758
<       Figure 7: Example 1 - MAX LSP Bandwidth fields in the ISCD @T2
---
>       Figure 7: Example 1 - MAX LSP Bandwidth fields in the ISCD at T2
762c762
<    In this example an interface with Tributary Slot Type 1.25Gbps and
---
>    In this example, an interface with Tributary Slot Type 1.25Gbps and
766c766
<    switched or terminated, the ODU2 can only be terminated and the ODU1
---
>    switched or terminated, the ODU2 can only be terminated, and the ODU1
768c768
<    advertised to support ODU0 the value of is "ignored" (TS
---
>    advertised to support ODU0, the value of is "ignored" (TS
770c770
<    interface a single ISCD is used and its format is as follows:
---
>    interface, a single ISCD is used and its format is as follows:
819c819
<    In this example two interfaces with homogeneous hierarchies but
---
>    In this example, two interfaces with homogeneous hierarchies but
822,824c822,824
<    one a G.709-2012 interface with fallback procedure disabled (TS
<    granularity=3).  Both of them support ODU1->ODU2->ODU3 hierarchy and
<    priorities 0 and 3.  T and S bits values are not relevant to this
---
>    one supports G.709-2012 interface with fallback procedure disabled
>    (TS granularity=3).  Both of them support ODU1->ODU2->ODU3 hierarchy
>    and priorities 0 and 3.  T and S bits values are not relevant to this
826,827c826,827
<    interfaces two different ISCDs are used and the format of their SCSIs
<    is as follows:
---
>    interfaces, two different ISCDs are used and the format of their
>    SCSIs is as follows:
903,908c903,908
<    with different exported TS granularity MUST be considered as non
<    homogenous hierarchies is the case in which an H-LPS and the client
<    LSP are terminated on the same egress node.  What can happen is that
<    a loose Explicit Route Object (ERO) is used at the hop where the
<    signaled LSP is nested into the Hierarchical-LSP (H-LSP) (penultimate
<    hop of the LSP).
---
>    with different exported TS granularity MUST be considered as
>    non-homogenous hierarchies. This is the case in which an H-LPS and
>    the client LSP are terminated on the same egress node.  What can
>    happen is that a loose Explicit Route Object (ERO) is used at the
>    hop where the signaled LSP is nested into the Hierarchical-LSP (H-LSP)
>    (penultimate hop of the LSP).
912,915c912,915
<    if2.  In case the H-LSP on if1 exports a TS=1.25Gbps and if2 a
<    TS=2.5Gbps and the service LSP being signaled needs a 1.25Gbps
<    tributary slot, only the H-LSP on if1 can be used to reach node E.
<    For further details please see section 4.1 of the [OTN-INFO].
---
>    if2.  In this case, the H-LSP on if1 exports a TS=1.25Gbps, if2 a
>    TS=2.5Gbps, the service LSP being signaled needs a 1.25Gbps
>    tributary slot, and only the H-LSP on if1 can be used to reach node E.
>    For further details, please see section 4.1 of the [OTN-INFO].
939,943c939,943
<    In this example the advertisement of an ODUflex->ODU3 hierarchy is
<    shown.  In case of ODUflex advertisement the MAX LSP Bandwidth needs
<    to be advertised and in some cases also information about the
<    Unreserved bandwidth could be useful.  The amount of Unreserved
<    bandwidth does not give a clear indication of how many ODUflex LSP
---
>    In this example, the advertisement of an ODUflex->ODU3 hierarchy is
>    shown.  In the case of ODUflex advertisement, the MAX LSP Bandwidth
>    needs to be advertised and, in some cases, information about the
>    Unreserved bandwidth could also be useful.  The amount of Unreserved
>    bandwidth does not give a clear indication of how many ODUflex LSPs
959,962c959,962
<    Bandwidth equal to 10 Gbps each.  In case 50Gbps of Unreserved
<    Bandwidth are available on Link A, 10Gbps on Link B and 3 ODUflex
<    LSPs of 10 GBps each, have to be restored, for sure only one can be
<    restored along Link B and it is probable (but not sure) that two of
---
>    Bandwidth equal to 10 Gbps each.  In the case where 50Gbps of Unreserved
>    Bandwidth are available on Link A, 10Gbps on Link B, and 3 ODUflex
>    LSPs of 10 GBps each have to be restored, for sure only one can be
>    restored along Link B and it is probable, but not certain, that two of
966c966
<    In the case of ODUflex advertisement the Type 2 Bandwidth TLV is
---
>    In the case of ODUflex advertisement, the Type 2 Bandwidth TLV is
1073c1073
<    simplicity we assume that also in this case only priorities 0 and 3
---
>    simplicity, we also assume that only priorities 0 and 3
1294c1294
<    In this example 2 OTU4 component links with the same supported TS
---
>    In this example, 2 OTU4 component links with the same supported TS
1388c1388
<    In this example 2 OTU4 component links with the same supported TS
---
>    In this example, 2 OTU4 component links with the same supported TS
1506c1506
<    All implementations of this document MAY support also advertisement
---
>    All implementations of this document MAY also support advertisement
1518c1518
<    based on policy and is out of scope of the document.  This enables
---
>    based on policy and beyond the scope of this document.  This enables
1537c1537
<    [RFC5920] .
---
>    [RFC5920].