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

["Adrian Farrel" <[e-mail]>]

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