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

[Lou Berger <[e-mail]>]

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