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

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

Hello Adrian,

Thanks for the quick response.  I'm going to split my follow-ups into two responses
- this one deals with the minor issues, another one will deal with the editorial
items and nits.

Comments on minor issues inline ... the collision on the RSA acronym looks like
the only significant open issue.

Thanks,
--David

> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]]
> Sent: Monday, August 03, 2015 1:38 PM
> To: Black, David; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; 'General Area Review
> Team'
> Cc: [e-mail]; [e-mail]
> Subject: RE: [CCAMP] Gen-ART review of draft-ietf-ccamp-flexi-grid-fwk-05
> 
> Hello David,
> 
> Responding as a contributing author who wants to see this work move forward
> promptly...
> 
> Many thanks for taking the time to review.
> 
> > Minor issues:
> >
> > [1] 3.2.5 - the last bullet item is not completely clear to me.  What
> > does it mean for two slot compositions to be the same?  Is this saying
> > that the same set of effective frequency slots need to be present
> > end-to-end for the media channel?  I suspect not, but I don't understand
> > what is intended.
> 
> I think you mean the penultimate bullet: the last one on page 9.

Yes.

> It does not mean that the same set has to be available end-to-end. As the text
> says "...the specific slots and their spacing may vary hop by hop." But it does
> mean that the composition of the media channel will be the same on each hop. So
> what is "the composition" of a media channel?  Well, as the first bullet says:
> "A composite media channel carries a group of OTSi" and you can go back one
> section to find what that means, but, in summary...
> 
> 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.

> > [2] p.21 last sentence in 1st para:
> >
> >    Regardless of the actual encoding,
> >    the LSP setup message specifies a minimum frequency slot width that
> >    needs to be fulfilled in order to successful establish the requsted
> >    LSP.
> >
> > 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.
> 
> Pedantically (and what's wrong with pedantry?), yes.
> Indeed, a user that requested a minimum frequency slot might be very disappointed.
> Thus it is taken for granted that a user requests usable bandwidth :-)
> 
> But adding "effective" would not be harmful.

That helps, thanks.

> > [3] p.21 - RSA acronym is unfortunate, due to collision w/widespread usage
> > of that acronym for a security algorithm.  I strongly suggest changing to
> > another acronym (e.g., R+SA).
> 
> Please see RFC 5513.

Right :-) :-) ...
... are there GMPLS plans to support RFC 3514 in the control plane? :-) :-)

> R+SA would be unfortunate because in this field the "+" is used to indicate a
> separation in processing whereas the concatenation shows processing as one
> piece.

And I suspect that any other punctuation character (e.g., '-') would be subject
to the same objection.

> Since the text expands and explains "RSA" I don't think a change is necessary.

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.

> > [4] 4.8.4 - The information model is informal or abstract (can't generate
> > anything from it), even though RBNF was used - this should be noted.
> 
> I am not clear why you make this assertion. It is true that I would not attempt
> to "generate" anything from the information model if, by that, we mean
> automatically using a script or compiler. But there is nothing that precludes
> someone from doing this.

I believe that sort of generation would involve "parsing" the comments and this
syntax element:

     <FS defined by (n, m) containing  contiguous available NCFs>

I'm not at all sure how feasible that is.  The intent of the model is clear,
but I was expecting something more concrete based on the use of a formal
language.  To put it a bit more bluntly, I expect the use of formal languages
to be able to drive tool-chains that yield interoperable implementations,
and I don't see that level of rigor here.  

> > [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."