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

[Daniele Ceccarelli <[e-mail]>]

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