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:adrian(_at_)olddog(_dot_)co(_dot_)uk]
Sent: Monday, August 03, 2015 1:38 PM
To: Black, David; zhangfatai(_at_)huawei(_dot_)com;
fu(_dot_)xihua(_at_)zte(_dot_)com(_dot_)cn;
daniele(_dot_)ceccarelli(_at_)ericsson(_dot_)com;
ihussain(_at_)infinera(_dot_)com; 'General Area Review
Team'
Cc: ccamp(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org
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."