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

[Daniele Ceccarelli <[e-mail]>]

Hi Acee,

Please find the version solving (hopefully) the last issues attached. It will be updated on Nov 4th.

Also, please find my comments in line.

Many thanks
Daniele


From: Acee Lindem
Sent: lunedì 28 ottobre 2013 17:01
To: Daniele Ceccarelli
Cc: [e-mail]; [e-mail]; CCAMP; [e-mail]
Subject: Re: RtgDir Review: "Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN Networks"

Hi Daniele,
I looked at the update and it is greatly improved. I'd still recommend the following issues be addressed.


1.      In section 4, you state the malformed LSA, TLV, or Sub-TLV  is ignored. Since this specification describes sub-TLVs, does that imply that only the sub-TLVs are ignored when malformed? This is how I'd interpret it.


[[DC]] correct. Fixed as you suggested below in 369,373c367,370, just changed a bit to reflect the fact that only sub-TLVs are defined in this document:

    When a received LSA includes a sub-TLV not formatted accordingly to the precise
    specifications in this document, the problem SHOULD be logged
    and the wrongly formatted sub-TLV MUST NOT be used for
    path computation.




2.      In examples where you used "X" to denote that the field is not applicable, you should state that. Or at least state it somewhere.



[[DC]] OK.

T, S and TS granularity fields are not relevant to this example (filled with Xs)

Also some edits on the new text:


130c130,131
<    provided in [OTN-INFO].
---
>    provided in [OTN-INFO].  The reader is assumed to be familiar with
>    both of these documents.
136,138d136
<    The reader is supposed to be familiar with OTN framework [OTN-FWK]
<    and GMPLS evaluation against OTN [OTN-INFO].
<
320c318
<    is shown in the table below (please note that there are 1000 bits in
---
>    are shown in the table below (please note that there are 1000 bits in
369,373c367,370
<    In case a recived LSA is not formatted accordingly to the
<    requirements indicated in this document, the problem SHOULD be logged
<    and the wrongly formatted LSA, TLV or Sub-TLV MUST NOT be used for
<    the path computation until a newer version correctly formatted is
<    received.
---
>    When a received LSA is not formatted accordingly to the precise
>    specifications in this document, the problem SHOULD be logged
>    and the wrongly formatted LSA, TLV, or Sub-TLV MUST NOT be used for
>    path computation.
1561c1558
<    flooding frequency.  Moreover the design of the encoding has been
---
>    flooding frequency.  Moreover, the design of the encoding has been
1573c1570
<       priorities is advertised
---
>       priorities are advertised.
1575,1578c1572,1575
<       - With respect of fixed containers, only the number of available
<       containers is advertised instead of available bandwidth so to use
<       only 16 bits per container instead of 32 (as per former GMPLS
<       encoding
---
>       - With respect to fixed containers, only the number of available
>       containers is advertised instead of available bandwidth so that
>       only 16 bits per container are used instead of 32 (as per the
>       former GMPLS encoding).
1580c1577
<    In order to further reduce the amount of data advertised it is
---
>    In order to further reduce the amount of data advertised, it is


Thanks,
Acee
P.S. I still think it would be better not to reference RFC 2154 in the "Security Considerations". RFC 6837 has a much better example for OSPF TE than RFC 3630.
[[DC]] Reference to RFC2154 removed but I think  RFC6837 is not the one you wanted to point to (A Not-so-novel Endpoint ID (EID) to Routing Locator (RLOC) Database).

On Oct 21, 2013, at 10:29 AM, Daniele Ceccarelli wrote:


Hi Acee,

Since today it is the deadline for draft submission we uploaded a version with the changes agreed up to now and the ones proposed in line below. Further modifications, if needed, will be deferred to a new version on Monday Nov 4th.

Thanks once again for your review

Daniele + Co-authors.

From: Acee Lindem
Sent: mercoledì 16 ottobre 2013 22:20
To: Daniele Ceccarelli
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; CCAMP; [e-mail]<mailto:[e-mail]>
Subject: Re: RtgDir Review: "Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN Networks"

Hi Daniele,
See inline.

On Oct 15, 2013, at 4:21 AM, Daniele Ceccarelli wrote:



Hi Acee,

Thanks for the careful review and please find comments/replies in line.

BR
Daniele (&co-authors)

From: Acee Lindem [mailto:[e-mail]]
Sent: mercoledì 9 ottobre 2013 03:41
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; CCAMP; [e-mail]<mailto:[e-mail]>
Subject: RtgDir Review: "Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN Networks"

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.
[[Authors]] How about adding a section saying:
OSPFv2 scalability considerations and requirements are in line with section 8 of [RFC6827]. In addition please note that OTN extensions in this document have been designed taking into consideration optimization criteria identified in [OTN-INFO]

It isn't obvious to me that these two extensions are comparable. I think a separate section pertaining to the OTN extensions would make more sense.

[[DC]] The following section has been added:


This document does not introduce OSPF scalability issues with respect
   to existing GMPLS encoding and does not require any modification to
   flooding frequency.  Moreover the design of the encoding has been
   carried out taking into account bandwidth optimization, and in
   particular:



      - Only unreserved and MAX LSP Bandwidth related to supported
      priorities is advertised

      - With respect of fixed containers, only the number of available
      containers is advertised instead of available bandwidth so to use
      only 16 bits per container instead of 32 (as per former GMPLS
      encoding

   In order to further reduce the amount of data advertised it is
   RECOMMENDED to bundle component links with homogeneous hierarchies as
   described in [RFC4201] and illustrated in Section 5.6.




                 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.
[[Authors]] Good comment. Looking at previous OSPF and OSPF-TE drafts we didn't find any text on handling of bad TLV formatting. Any suggestion on how to deal with that is more than welcome.

In the past, I've stated that the problem should be logged and the LSA, TLV, or Sub-TLV MUST NOT be used for TE/GMPLS path computation. It all depends on what makes sense for the encoding violation and at what level it should be resolved. One generic solution would be to NOT use any LSAs with encoding violations for GMPLS path computation.


[[DC]] This piece of text has been added at the end of section 4:

           In case a recived LSA is not formatted accordingly to the requirements indicated in
           this document, the problem SHOULD be logged and the wrongly formatted LSA, TLV or Sub-TLV MUST NOT
              be used for the path computation until a newer version correctly formatted is received.



                 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.
[[Authors]] The reader is supposed to have read [OTN-FWK] and [OTN-INFO]. We can add a sentence at the end of the abstract or intro.

This is the minimum.




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.
[[Author]] Correct. Fixed.
                 2. The table on page 7 is incomprehensible with the given columns and headings. Spaces
                      rather than commas in numbers are annoying.


[[Author]] Spaces substituted with commas. As per comment above having read [OTN-FWK] and [OTN-INFO] is a prerequisite.

Does it add anything to this document if one needs to look at OTN-FWK and OTN-INFO anyway? It is much less relevant than, say, a discussion of advertisement and scaling ;^)

For example, what does 239/238 mean? Is this 239 or 238 separate tributary slots - why is it variable? What does GFP-F mean - it is not defined here.


[[DC]] Table 7 is needed to fill the common header of the ISCD. E.g. when indicating ODU4, the related max lsp bandwidth in the common header of the ISCD needs to be filled with  0x504331E3.

The first and third columns of the table are needed for that, while the second one explains how the value is Byte/sec is retrieved (i.e. the nominal bit rate of each ODU). The "239/238" does not mean 239 OR 238 but means 239 divided by 238.

The meaning of GFP-F is explained in the fwk document (defined in G.7041) and stands for Generic Framing Procedure. In addition to the various ODUs there are three more ODU types that need to be advertised, namely: i) ODUflex for CBR client signals, ii) ODUflex for GFP-F mapped client signal and iii) ODU flex resizable.

                 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.
[[Authors]] Good catch. We're defining only sub-tlvs. Fixed.
                 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.
[[Authors]] T and S were left intentionally to make the reading easier but maybe it's not the case. Only 0 and 1 are there now.
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.

[[Authors]] The focus of those examples is not T,S and TSG but e.g. ODUflex advertisement, single stage muxing etc. For each example there is a disclaimer saying: "T, S and TS granularity fields are not relevant to this example".

Then wouldn't X's be more relevant than missing discrete values and field labels in the same figure?

[[DC]] OK. X's used.




                 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".
[[Authors]] How about the following?
OLD

    [RFC3630<http://tools.ietf.org/html/rfc3630>] suggests mechanisms such as [RFC2154<http://tools.ietf.org/html/rfc2154>] to protect
   the transmission of this information...
NEW

    [RFC3630<http://tools.ietf.org/html/rfc3630>] suggests mechanisms to protect
   the transmission of this information...

It would be great with me. There are plenty of reviewers who will nit pick the security section...





  Nits:
1.       The proper punctuation is "i.e., " and "e.g. ,".
[[Authors]] OK
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)?
[[Authors]] OK
                 3. Suggest formatting the document so that the figures are on separate pages rather than
                      split across pages.
[[Authors]] I don't know how to do that with the .xml file. Maybe this is a comment we can leave for the RFC editor?

Ok. I have been able to do this with

<vspace blankLines="100" />


[[DC]] It works fine with all figures except fig 14. It's longer than a page.



3.       Replace all occurrences of "non " with "non-" and do not end lines with "non ".
[[Authors]] OK
                 4. 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.
[[Authors]] OK to all. All modifications you suggest have been implemented.

Thanks - I'll look for the update.

Thanks,
Acee






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