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

[Lou Berger <[e-mail]>]

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