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

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 16 Oct 2013 19:37:25 +0100

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: [email-masked] [mailto:[email-masked]] On Behalf Of
> Joel M. Halpern
> Sent: 02 October 2013 19:33
> To: Lou Berger
> Cc: [email-masked]; CCAMP WG; [email-masked]; draft-ietf-ccamp-otn-
> [email-masked]; 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:[email-masked]]
> >>> Sent: lunedì 30 settembre 2013 23:39
> >>> To: BELOTTI, SERGIO (SERGIO)
> >>> Cc: Joel M. Halpern; [email-masked]; CCAMP WG; draft-ietf-ccamp-otn-g709-
> >>> [email-masked]; [email-masked]
> >>> 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:[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
> >>>>>>
> >>>>>> 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
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>
> >

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 17 Oct 2013 07:37:20 +0000

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

> From: Adrian Farrel [mailto:[email-masked]]
> Sent: mercoledì 16 ottobre 2013 20:37
> To: [email-masked]
> Cc: 'CCAMP WG'
> Subject: RE: RtgDir review: draft-ietf-ccamp-otn-g709-info-model-11.txt
> 
> 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
> 
> > From: [email-masked] [mailto:[email-masked]] On
> > Behalf Of Joel M. Halpern
> > Cc: [email-masked]; CCAMP WG; [email-masked];
> > draft-ietf-ccamp-otn- [email-masked]; Daniele
> > Ceccarelli; BELOTTI, SERGIO (SERGIO)
> > Subject: Re: [RTG-DIR] I: R: [CCAMP] RtgDir review:
> > only supported priorities must be advertised, what does not say is why
> > (i.e. for optimization).
> > >>> Maximum LSP bandwidth is currently advertised per priority in the
> > >>> common part of the ISCD.  Section 5 reviews some of the
> > >>> "[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
> > >>
> > >>> Cc: Joel M. Halpern; [email-masked]; CCAMP WG;
> > >>> draft-ietf-ccamp-otn-g709- [email-masked];
> > >>> [email-masked]
> > >>> Subject: Re: I: [RTG-DIR] R: [CCAMP] RtgDir review:
> > >>> draft-ietf-ccamp-otn- g709-info-model-11.txt
> > >>>
> > >>> Sergio,
> > >>> 	See below.
> > >>>
> > >>> 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:
> > >>>>
> > >>>> Authors> as already said The basic scope of the draft is to
> > >>>> Authors> underline
> > >>>> 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
> > >>>>
> > >>>> 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,
> > >>>> should also be considered as part of the optimization effort identified
> in Section 5."
> > >>>>
> > >>>
> > >>> How about:
> > >>> OLD
> > >>> the OSPF draft (where we say e.g. that only bandwidth for
> > >>> supporter priorities need to be advertised but don't say why).
> > >>>>>
> > >>> 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
> > >>>
> > >>> :" [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
> > >>>>
> > >>>>>> Great. So you and I are in agreement. We'll see what the
> > >>>>>> authors have to say...
> > >>>>>>
> > >>>>>>
> > >>>>>>> The proposed alternative text would suffice, although
> > >>>>>>> personally I would just remove the two sections.
> > >>>>>>>
> > >>>>>>> Yours,
> > >>>>>>> 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
> > >>>>>>>>
> > >>>>>>>>>>> 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.
> > >>>>>>>>>>> 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?
> > >>>>>>>>>>
> > >>>>>>>>>> (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].
> > >>>>>>>>>>
> > >>>>>>>>>> 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
> > >>>>>>>>>>> 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,
> > >>>>>>>>>> 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.
> > >>>>>>>>>>
> > >>>>>>>>>> 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
> > >>>>>>>>>>
> > >>>>>>>>>> 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
> > >>>>>>>>>>
> > >>>>>>>>>> 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.
> > >>>>>>>>>>