Subject: [CCAMP] RtgDir review: draft-ietf-ccamp-otn-g709-info-model-11.txt

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 09 Sep 2013 08:14:52 -0400

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 see http://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-otn-g709-info-model-11.txt
Reviewer: Joel Halpern
Review Date: 9-September-2013
IETF LC End Date: 19-Sept-2013
Intended Status: Informational

Summary: I have some minor concerns about this document that I think 
should be resolved before publication.

Comments:
     In general, the document needs to be consistently clear as to what 
gaps it identifies.  Many cases are quite clear, and some are not.  I 
will try to identify the less clear cases in the comments below. The 
last paragraph of section 3.2 is clear and explicit, and what I expected 
at the end of each section.  The previous paragraph ("Specific 
information could be defined") is much less helpful.

Moderate Issues:
     It is unclear if there are gaps or requirements identified by 
sections 3.1.1 or 3.1.2.
     Given that this document is about mapping to G.709, it is unclear 
what is intended by the usage of "LSP".  My guess is that it is intended 
to mean Label Switch Paths set up by GMPLS to carry OTU/UDU elements. 
It should be stated explicitly.

Minor Issues:
     All acronyms should be expanded upon first use.
     In section 2 particularly, the OCh (Optical Channel?) should also 
be clear how that relates to the OTU and ODU being discussed.
     Figure 4 uses the abbreviation TSG, which is not defined, and not 
used elsewhere.  If it is needed in the figure, it might suffice to 
follow "TS granularity" in the caption with "(TSG)".

     Section 8 on Maximum LSP Bandwdith seems to be objecting to too 
much information leading to a "waste of bits".  While possibly of 
interest to the WG, that does not seem to fit a gap analysis.
     Similarly, section 10 on Priority Support reads as implementation 
advice rather than a gap needing protocol changes.

Nit:

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Thu, 26 Sep 2013 08:50:19 +0000

Hello Joel,

thanks for your comments.
Below in line our reply, marked "authors".

Best Regards

The authors

Belotti Sergio-  System Architect
ALCATE-LUCENT  Optics Division
via Trento 30 Vimercate (MB) - Italy
phone +39 (039) 6863033
-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Joel M. Halpern
Inviato: lunedì 9 settembre 2013 14:15
A: [email-masked]; [email-masked]; [email-masked]; CCAMP WG
Oggetto: [CCAMP] RtgDir review: draft-ietf-ccamp-otn-g709-info-model-11.txt

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 see http://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.

Summary: I have some minor concerns about this document that I think should be resolved before publication.

Comments:
     In general, the document needs to be consistently clear as to what gaps it identifies.  Many cases are quite clear, and some are not.  I will try to identify the less clear cases in the comments below. The last paragraph of section 3.2 is clear and explicit, and what I expected at the end of each section.  The previous paragraph ("Specific information could be defined") is much less helpful.

Moderate Issues:
     It is unclear if there are gaps or requirements identified by sections 3.1.1 or 3.1.2.

Authors> The scope of both paragraph are not to suggest gaps or requirements but to describe data plane characteristics that are useful in the follow of the doc. Particularly they introduce the relationship between payload type concept in OTN and the Tributary Slot granularity, and this relation is reported in the session 3.2 in which specific CP requirements are defined.

     Given that this document is about mapping to G.709, it is unclear what is intended by the usage of "LSP".  My guess is that it is intended to mean Label Switch Paths set up by GMPLS to carry OTU/UDU elements. 
It should be stated explicitly.

Authors> We can specify this as you suggest even if we considered not necessary to specify the usage of LSP in relation to data plane specific. Encoding type should cope with this issue. 

Minor Issues:

Authors> OK

     In section 2 particularly, the OCh (Optical Channel?) should also be clear how that relates to the OTU and ODU being discussed.

Authors> OK, you're right

     Figure 4 uses the abbreviation TSG, which is not defined, and not used elsewhere.  If it is needed in the figure, it might suffice to follow "TS granularity" in the caption with "(TSG)".

Authors> We can add TSG at the beginning of chapter 3.2 when TS granularity is mentioned

     Section 8 on Maximum LSP Bandwdith seems to be objecting to too much information leading to a "waste of bits".  While possibly of interest to the WG, that does not seem to fit a gap analysis.
     Similarly, section 10 on Priority Support reads as implementation advice rather than a gap needing protocol changes.

Authors> The basic scope of the draft is to underline gaps, and even if what described in Ch.8 and 10, do not prevent routing to work , it is suggested here an requirement for optimization based on OTN requirements (e.g. no need to advertise fixed ODU container Max LSP BW since implicit in the signal type.)

Nit:

_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: Lou Berger <[email-masked]>
Date: Fri, 27 Sep 2013 13:37:56 -0400

Joel/Authors,

I thought I might jump in on two points:

> Below in line our reply, marked "authors".

...

> Authors> We can specify this as you suggest even if we considered not necessary to specify the usage of LSP in relation to data plane specific. Encoding type should cope with this issue. 

Joel,

I suspect that the usage of LSP in the absence of the MPLS data plane is
what's causing confusion here.  Is this correct?

If so, I think GMPLS referencing controlled data paths (circuits) by the
common name of Label Switched Path (LSP) is sufficiently established
that this document doesn't need to revisit it.  In any case, the
document already provides context:

   GMPLS routing and signaling, as defined by [RFC4203], [RFC5307],
   [RFC3473] and [RFC4328], provides the mechanisms for basic GMPLS
   control of OTN networks based on the 2001 revision of the G.709
   specification.
and
   Background information and a framework for the GMPLS protocol
   extensions need to support [G.709-2012] is provided in [OTN-FWK].

[OTN-FWK] has the often repeated concept:

   GMPLS extends Multi-Protocol Label Switching (MPLS) to encompass time
   division multiplexing (TDM) networks (e.g., Synchronous Optical
   NETwork (SONET)/ Synchronous Digital Hierarchy (SDH), Plesiochronous
   Digital Hierarchy (PDH), and G.709 sub-lambda), lambda switching
   optical networks, and spatial switching (e.g., incoming port or fiber
   to outgoing port or fiber).  The GMPLS architecture is provided in
   [RFC3945],

If this doesn't cover the comment, can you elaborate on what you want
explicitly stated?

> ...

Authors,
	I completely agree with Joel on this point, furthermore sections 10 and
8 overlap.  One approach to address his point would be to simply drop
both sections.  An alternative is try to rephrase them to address Joel's
points.  I've taken a pass at the latter below, but won't object if the
authors prefer the former.

Here's a suggested wording change if you choose to keep the sections:
OLD:
   8. Maximum LSP Bandwidth

   Maximum LSP bandwidth is currently advertised in the common part of
   the ISCD and advertised per priority, while in OTN networks it is
   only required for ODUflex advertising.  This leads to a significant
   waste of bits inside each LSA.
and

NEW
8. Maximum LSP Bandwidth

   Maximum LSP bandwidth is currently advertised per priority in the
   common part of the ISCD.  Section 5 reviews some of the implications
   of advertising OTN network information using  ISCDs, and
   identifies the need for a more optimized solution.  While strictly
   not required, such an optimization effort should also consider the
   optimization of the per priority maximum LSP bandwidth advertisement
   of both fixed and variable ODU types.

OLD
   10. Priority Support

   [RFC4202] defines 8 priorities for resource availability and usage.
   All of them have to be advertised independently on the number of
   priorities supported by the implementation.  Considering that the
   advertisement of all the different supported signal types will
   originate large LSAs, it is advised to advertise only the information
   related to the really supported priorities.
NEW
   10. Priority Support

   [RFC4202] defines 8 priorities for resource availability and usage.
   As defined, each is advertised independent of the number of
   priorities supported by a network.  As is the case in Section 8,
   addressing any inefficiency with such advertisements is not required
   to support OTN networks.  But any such inefficiency should also be
   considered as part of the optimization effort identified in Section
   5.

Also please replace "Bw" with "Bandwidth" in the document.

Lou

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 27 Sep 2013 14:30:42 -0400

Lou, thanks for stepping in.
With your explanation I can live with the LSP text as it is.

I look forward to further conversation on the other point.

Yours,
Joel

---

From: Lou Berger <[email-masked]>
Date: Fri, 27 Sep 2013 15:00:35 -0400

Joel,
	Does the proposed altnerate text address your comment (assuming the
author's want to keep the sections)?  If not, can you suggest changes?

Thanks,
Lou

On 09/27/2013 02:30 PM, Joel M. Halpern wrote:
>>>       Given that this document is about mapping to G.709, it is
>>> unclear what is intended by the usage of "LSP".  My guess is that it
>>> is intended to mean Label Switch Paths set up by GMPLS to carry
>>> OTU/UDU elements.
>>> Authors> We can specify this as you suggest even if we considered not
>>> necessary to specify the usage of LSP in relation to data plane
>>> specific. Encoding type should cope with this issue.
>>>
>>
>> Joel,
>>
>>>       Similarly, section 10 on Priority Support reads as
>>> implementation advice rather than a gap needing protocol changes.
>>>
>>> Authors> The basic scope of the draft is to underline gaps, and even
>>> if what described in Ch.8 and 10, do not prevent routing to work , it
>>> is suggested here an requirement for optimization based on OTN
>>> requirements (e.g. no need to advertise fixed ODU container Max LSP
>>> BW since implicit in the signal type.)
>>>
>>
>> Authors,

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 27 Sep 2013 15:26:12 -0400

The proposed alternative text would suffice, although personally I would 
just remove the two sections.

Yours,
Joel

---

From: Lou Berger <[email-masked]>
Date: Fri, 27 Sep 2013 15:54:43 -0400 (EDT)

Great. So you and I are in agreement. We'll see what the authors have to say...

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 30 Sep 2013 13:59:33 +0000

Lou, Joel,

The text proposed sounds good but it only states the problem without any hint on the solutions (i.e. says there is an inefficiency but doesn’t say that advertising only supported priorities is a way to address such inefficiency).
There are two options:
1. Improve the text (the NEW one) saying e.g. only the advertisement of bandwidth for supported priorities is needed
2. Adopt the NEW text as it is and move the remaining part of the text to the OSPF draft (where we say e.g. that only bandwidth for supporter priorities need to be advertised but don't say why).

Re all the other comments/suggestion we're ok and will fix them as suggested.

BR
Authors

> -----Original Message-----
> From: Lou Berger [mailto:[email-masked]]
> Sent: venerdì 27 settembre 2013 21:55
> To: Joel M. Halpern
> Cc: [email-masked]; CCAMP WG; draft-ietf-ccamp-otn-g709-info-
> [email-masked]; BELOTTI, SERGIO \(SERGIO\); [email-masked]
> Subject: Re: [RTG-DIR] R: [CCAMP] RtgDir review: draft-ietf-ccamp-otn-g709-
> info-model-11.txt
> 
> > The proposed alternative text would suffice, although personally I
> > would just remove the two sections.
> >
> > Yours,
> > Joel
> >
> > > > > > unclear what is intended by the usage of "LSP".  My guess is
> > > > > > that it is intended to mean Label Switch Paths set up by GMPLS
> > > > > > to carry OTU/UDU elements.
> > > > > > Authors> We can specify this as you suggest even if we
> > > > > > Authors> considered not
> > > > > > necessary to specify the usage of LSP in relation to data
> > > > > > plane specific. Encoding type should cope with this issue.
> > > > > >
> > > > >
> > > > > Joel,
> > > > >
> > > > > I suspect that the usage of LSP in the absence of the MPLS data
> > > > > plane is what's causing confusion here.  Is this correct?
> > > > >
> > > > > If so, I think GMPLS referencing controlled data paths
> > > > > (circuits) by the common name of Label Switched Path (LSP) is
> > > > > sufficiently established that this document doesn't need to
> > > > > revisit it.  In any case, the document already provides context:
> > > > >
> > > > > GMPLS extends Multi-Protocol Label Switching (MPLS) to encompass
> > > > > time division multiplexing (TDM) networks (e.g., Synchronous
> > > > > Optical NETwork (SONET)/ Synchronous Digital Hierarchy (SDH),
> > > > > Plesiochronous Digital Hierarchy (PDH), and G.709 sub-lambda),
> > > > > lambda switching optical networks, and spatial switching (e.g.,
> > > > > incoming port or fiber to outgoing port or fiber).  The GMPLS
> > > > > architecture is provided in [RFC3945],
> > > > >
> > > > > If this doesn't cover the comment, can you elaborate on what you
> > > > > want explicitly stated?
> > > > >
> > > > > > ...
> > > > > >
> > > > > > Section 8 on Maximum LSP Bandwdith seems to be objecting to
> > > > > > too much information leading to a "waste of bits".  While
> > > > > > possibly of interest to the WG, that does not seem to fit a gap
> analysis.
> > > > > > Authors> The basic scope of the draft is to underline gaps,
> > > > > > Authors> and even
> > > > > > if what described in Ch.8 and 10, do not prevent routing to
> > > > > > work , it is suggested here an requirement for optimization
> > > > > > based on OTN requirements (e.g. no need to advertise fixed ODU
> > > > > > container Max LSP BW since implicit in the signal type.)
> > > > > >
> > > > >
> > > > > Authors,
> > > > > 8 overlap.  One approach to address his point would be to simply
> > > > > drop both sections.  An alternative is try to rephrase them to
> > > > > address Joel's points.  I've taken a pass at the latter below,
> > > > > but won't object if the authors prefer the former.
> > > > >
> > > > > Maximum LSP bandwidth is currently advertised in the common part
> > > > > of the ISCD and advertised per priority, while in OTN networks
> > > > > it is only required for ODUflex advertising.  This leads to a
> > > > > significant waste of bits inside each LSA.
> > > > > and
> > > > >
> > > > > NEW
> > > > > 8. Maximum LSP Bandwidth
> > > > >
> > > > > Maximum LSP bandwidth is currently advertised per priority in
> > > > > the common part of the ISCD.  Section 5 reviews some of the
> > > > > implications of advertising OTN network information using
> > > > > ISCDs, and identifies the need for a more optimized solution.
> > > > > While strictly not required, such an optimization effort should
> > > > > also consider the optimization of the per priority maximum LSP
> > > > > bandwidth advertisement of both fixed and variable ODU types.
> > > > >
> > > > > OLD
> > > > > 10. Priority Support
> > > > >
> > > > > priorities supported by the implementation.  Considering that
> > > > > the advertisement of all the different supported signal types
> > > > > will originate large LSAs, it is advised to advertise only the
> > > > > information related to the really supported priorities.
> > > > > NEW
> > > > > 10. Priority Support
> > > > >
> > > > > addressing any inefficiency with such advertisements is not
> > > > > required to support OTN networks.  But any such inefficiency
> > > > > should also be considered as part of the optimization effort
> > > > > identified in Section 5.
> > > > >

---

From: Lou Berger <[email-masked]>
Date: Mon, 30 Sep 2013 10:40:44 -0400

Daniele,

> The text proposed sounds good but it only states the problem without any hint on the solutions (i.e. says there is an inefficiency but doesn’t say that advertising only supported priorities is a wa…

Well, there's also the option of dropping the sections.

> 1. Improve the text (the NEW one) saying e.g. only the advertisement of bandwidth for supported priorities is needed

I always find it easier to make a decision when the tradeoffs are
concrete.  Can you (authors) propose revised text?

> 2. Adopt the NEW text as it is and move the remaining part of the text to the OSPF draft (where we say e.g. that only bandwidth for supporter priorities need to be advertised but don't say why).
Doesn't the OSPF draft already already do what you say, i.e., advertise
only used priorities. What specific text are you proposing to add?

Thanks,
Lou