Re: [Gen-art] [CCAMP] Gen-ART review of draft-ietf-ccamp-flexi-grid-fwk-05 - Minor Issues

["Black, David" <[e-mail]>]

Hello Ramon,

Well, it looks like the IESG had no problem with the RSA acronym (draft is
approved), so that issue is settled ;-).

Everything else that you've suggested looks fine - thanks for taking care of
these concerns.

Thanks,
--David

> -----Original Message-----
> From: Ramon Casellas [mailto:[e-mail]]
> Sent: Monday, August 24, 2015 5:37 AM
> To: [e-mail]
> Cc: [e-mail]; Black, David
> Subject: Re: [CCAMP] Gen-ART review of draft-ietf-ccamp-flexi-grid-fwk-05 -
> Minor Issues
> 
> Dear David, all
> 
> Many thanks for your review and comments and I apologize for the delay,
> I was on holidays.
> 
> Fortunately, Adrian and Fatai were kind enough to reply, and I am mostly
> aligned.
> 
> Please see inline for comments
> Best regards
> Ramon
> 
> El 04/08/2015 a las 16:20, Black, David escribió:
> >
> >> -----Original Message-----
> >> From: Adrian Farrel [mailto:[e-mail]]
> >> Sent: Monday, August 03, 2015 1:38 PM
> (snip)
> >>
> >> You can make an end-to-end connection from a set of parallel channels. You
> can
> >> place those channels at different spots in the spectrum from one hop to the
> >> next, but you cannot vary the number of channels from one hop to the next
> (e.g.
> >> two channels on one hop mapped to one thick channel on the next hop mapped
> to
> >> four thin channels on the next hop).
> > Part of this is definitely my lack of GMPLS familiarity.  That said,
> something
> > to make the "cannot vary the number of channels from one hop to the next"
> point
> > would be helpful to add.  Perhaps:
> >
> > OLD
> >        That is, the slot composition must be the same from one
> >        end to the other of the media channel even if the specific slots
> >        and their spacing may vary hop by hop.
> > NEW
> >        That is, the slot composition (i.e., the group of OTSi carried by
> >        the composite media channel) must be the same from one
> >        end to the other of the media channel even if the specific slot
> >        for each OTSi and the spacing among slots may vary hop by hop.
> Ramon> Changed, as per your suggestion. Thanks.
> 
> >>> [2] p.21 last sentence in 1st para:
> >>>
> >>>
> >>> Should "minimum frequency slot width" be "minimum effective frequency slot
> >>> width"?  I think it's  possible for the effective frequency slot width to
> >>> be smaller than all of the individual slot widths involved in the absence
> >>> of frequency shifters/converters.
> Ramon> Indeed, it is possible, notably when central frequencies differ.
> As Adrian mentions, adding effective is ok, will appear in next version.
> Added
> 
> 
> 
> >>> [3] p.21 - RSA acronym is unfortunate, due to collision w/widespread usage
> >>>
> >>> In most cases of acronym collision, I would not object, but RSA is unusual
> as
> >>> a very widely known security algorithm acronym (and there are a small
> number of
> >>> other acronyms, whose reuse I would find problematic, e.g., SSL and TLS).
> I
> >>> still think RSA is a rather poor choice of acronym for routing
> functionality,
> >>> no matter how well it's explained.
> Ramon> I fully understand your concerns, but I am afraid that I tend to
> disagree, the RSA acronym is also quite well understood in optical
> networking, and R&SA, RSA, R+SA, etc. can have different meanings. I am
> willing to hear other opinions, but I would not change it.
> 
> >>> [5] 5.5 - I'm surprised that the first requirement (neighbor discovery
> >>> support) is a MAY.  I wonder about its operational consequences, and at
> the
> >>> very least suggest expanding Section 8 to discuss them.  The text in 5.5
> >>> should be expanded to add some explanation of how things work when there's
> >>> no neighbor discovery support.
> >> Although some work has been done on plug and play in transport networks,
> there
> >> is also a lot of "legacy" thought with respect to plugging 100G fibers in
> at
> >> random and seeing what is connected to what today. In general, when one
> >> provisions a fiber and a pair of expensive line cards, one has a good idea
> what
> >> one is connecting and the processes that are run are validation rather than
> >> discovery.
> >>
> >> Thus the second paragraph aims for link property correlation such as is
> provided
> >> in LMP, but the first paragraph only considers the element of discovery to
> be
> >> something that someone could look at if they are really enthusiastic.
> >>
> >> Since this is pretty much established behavior across GMPLS optical
> networks,
> >> I'm not sure more needs to be said.
> > Please state that absence of neighbor discovery is "pretty much established
> > behavior across GMPLS optical networks" perhaps in the form of "not required
> > or used in common operational practice."
> Ramon> What about
> 
> OLD
> 
>     The control plane MAY include support for neighbor discovery such
>     that an flexi-grid network can be constructed in a "plug-and-play"
>     manner.
> 
> 
> NEW
> 
>     The control plane MAY include support for neighbor discovery such
>     that an flexi-grid network can be constructed in a "plug-and-play"
>     manner. Note, however, that in common operational practice validation
>     processes are used rather than automatic discovery.
> 
> 
> Related email follows on nots and editorial....
> 
> Thanks again
> Ramon