ietf
[Top] [All Lists]

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

2015-08-24 10:05:18
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

<Prev in Thread] Current Thread [Next in Thread>