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

[Ramon Casellas <[e-mail]>]

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:[e-mail]]
>> 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