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(_dot_)casellas(_at_)cttc(_dot_)es]
Sent: Monday, August 24, 2015 5:37 AM
To: ccamp(_at_)ietf(_dot_)org
Cc: ietf(_at_)ietf(_dot_)org; 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(_at_)olddog(_dot_)co(_dot_)uk]
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