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

[Daniele Ceccarelli <[e-mail]>]

I was 100% sure I had uploaded it...apparently i'm one of the rare cases of "senile dementia" at the age of 32 :)

Uploaded right now.

Many thanks,
Daniele

> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]]
> Sent: mercoledì 16 ottobre 2013 20:37
> To: [e-mail]
> Cc: 'CCAMP WG'
> Subject: RE: RtgDir review: draft-ietf-ccamp-otn-g709-info-model-11.txt
> 
> It looks like everything was agreed for the next revision, but then you stalled.
> 
> Can you get a revision out really fast? If you do I can get it to the IESG before
> Vancouver. If you can't the OSPF document gets backed up behind it.
> 
> Thanks,
> Adrian
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On
> > Behalf Of Joel M. Halpern
> > Sent: 02 October 2013 19:33
> > To: Lou Berger
> > Cc: [e-mail]; CCAMP WG; [e-mail];
> > draft-ietf-ccamp-otn- [e-mail]; Daniele
> > Ceccarelli; BELOTTI, SERGIO (SERGIO)
> > Subject: Re: [RTG-DIR] I: R: [CCAMP] RtgDir review:
> > draft-ietf-ccamp-otn-g709- info-model-11.txt
> >
> > 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
> > >>>> Authors> 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
> > >>>> Authors> 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
> > >>>>>>>>>>> Authors> 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,
> > >>>>>>>>>> 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
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>
> > >