Re: [CCAMP] I: [RTG-DIR] R: RtgDir review: draft-ietf-ccamp-otn-g709-info-model-11.txt

["Joel M. Halpern" <[e-mail]>]

While I tend to think of optimizations and gaps as very different 
things, I can live with the text changes.
Yours,
Joel

On 10/1/13 8:26 AM, Lou Berger wrote:
> Daniele,
>
>> Sounds reasonable?
>
> While I still like option 3, I can live with the revised text.
>
> Joel,
>
> Is the revised text acceptable?
>
> Lou
>
> On 10/01/2013 03:40 AM, Daniele Ceccarelli wrote:
>> Hi Lou,
>>
>> No no no, no OSPF discussion reopening. The OSPF drafts clearly states that only supported priorities must be advertised, what does not say is why (i.e. for optimization).
>> With section 8 and section 10 modified as below, there is no need to modify OSPF as the "why" is stated in the gap-analysis draft.
>>
>> Trying to summarize.
>> Section 8 as you proposed:
>>> 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.
>>
>> Section 10 (as per your last proposal)
>>> "[RFC4202] defines 8 priorities for resource availability
>>> and usage. As defined, each is advertised independent of the number
>>> of priorities supported by a network, and even unsupported
>>> priorities are included.. 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."
>>
>> Sounds reasonable?
>> BR
>> Authors
>>
>>> -----Original Message-----
>>> From: Lou Berger [mailto:[e-mail]]
>>> Sent: lunedì 30 settembre 2013 23:39
>>> To: BELOTTI, SERGIO (SERGIO)
>>> Cc: Joel M. Halpern; [e-mail]; CCAMP WG; draft-ietf-ccamp-otn-g709-
>>> [e-mail]; [e-mail]
>>> Subject: Re: I: [RTG-DIR] R: [CCAMP] RtgDir review: draft-ietf-ccamp-otn-
>>> g709-info-model-11.txt
>>>
>>> Sergio,
>>> 	See below.
>>>
>>> On 9/30/2013 11:15 AM, BELOTTI, SERGIO (SERGIO) wrote:
>>>> Lou,
>>>> our answer in line marked "authors"
>>>>
>>>> Thanks
>>>>
>>>> Authors
>>>>
>>>>
>>>> ----------------------------------------------------------------------
>>>> -----------------
>>>> Daniele,
>>>>
>>>> On 09/30/2013 09:59 AM, Daniele Ceccarelli wrote:
>>>>> 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:
>>>>
>>>> Well, there's also the option of dropping the sections.
>>>>
>>>> Authors> as already said 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.). So, in our
>>>> opinion, no dropping.
>>>>
>>>>
>>>>> 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?
>>>>
>>>> Authors> "[RFC4202] defines 8 priorities for resource availability
>>>> and usage. As defined, each is advertised independent of the number of
>>>> priorities supported by a network vs. to advertise only the
>>>> information related to the really supported priorities as possible
>>>> optimization improvement. 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."
>>>>
>>>
>>> How about:
>>> OLD
>>>    As defined, each is advertised independent of the number
>>>    of priorities supported by a network vs. to advertise only the
>>>    information related to the really supported priorities as possible
>>>    optimization improvement.
>>> NEW
>>>    As defined, each is advertised independent of the number
>>>    of priorities supported by a network, and even unsupported
>>>    priorities are included.
>>>
>>>
>>>>> 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?
>>>>>
>>>> Authors> No, it doesn't.
>>>
>>> So the OSPF draft currently says that all priorities are advertised?
>>> Really????  If so adding this new text does little to change this.  Are you really
>>> advocating reopening discussion on the OSPF draft in addition to this one?
>>>
>>> Lou
>>>
>>>> ... Text proposed is the old one that totally address explanation in our view
>>> :" [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.
>>>>
>>>> Thanks,
>>>> Lou
>>>>
>>>>> Re all the other comments/suggestion we're ok and will fix them as
>>> suggested.
>>>>>
>>>>> BR
>>>>> Authors
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Lou Berger [mailto:[e-mail]]
>>>>>> Sent: venerdì 27 settembre 2013 21:55
>>>>>> To: Joel M. Halpern
>>>>>> Cc: [e-mail]; CCAMP WG; draft-ietf-ccamp-otn-g709-info-
>>>>>> [e-mail]; BELOTTI, SERGIO \(SERGIO\);
>>>>>> [e-mail]
>>>>>> Subject: Re: [RTG-DIR] R: [CCAMP] RtgDir review:
>>>>>> draft-ietf-ccamp-otn-g709- info-model-11.txt
>>>>>>
>>>>>> Great. So you and I are in agreement. We'll see what the authors
>>>>>> have to say...
>>>>>>
>>>>>>
>>>>>> On 3:26pm, September 27, 2013, Joel M. Halpern wrote:
>>>>>>> The proposed alternative text would suffice, although personally I
>>>>>>> would just remove the two sections.
>>>>>>>
>>>>>>> Yours,
>>>>>>> Joel
>>>>>>>
>>>>>>> On 9/27/13 3:00 PM, Lou Berger wrote:
>>>>>>>> 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:
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>> On 9/27/13 1:37 PM, Lou Berger wrote:
>>>>>>>>>> Joel/Authors,
>>>>>>>>>>
>>>>>>>>>> I thought I might jump in on two points:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 9/26/2013 4:50 AM, BELOTTI, SERGIO (SERGIO) wrote:
>>>>>>>>>>> Hello Joel,
>>>>>>>>>>>
>>>>>>>>>>> thanks for your comments.
>>>>>>>>>>> Below in line our reply, marked "authors".
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ...
>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>>>> 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 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?
>>>>>>>>>>
>>>>>>>>>>> ...
>>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>>>> Authors> 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,
>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>
>