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:ramon.casellas@xxxxxxx] > Sent: Monday, August 24, 2015 5:37 AM > To: ccamp@xxxxxxxx > Cc: ietf@xxxxxxxx; 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:adrian@xxxxxxxxxxxx] > >> 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