[GSMP] RE: [Fwd: IESG comments on draft-ietf-gsmp-dyn-part-reqs]

[avri doria <[e-mail]>]

From: "Anderson, Todd A" <[e-mail]>


> 
> Comments and questions in-line.

Mine as well.

> 
> Todd
> 
>> >   o Requirements for the Dynamic Partitioning of Switching Elements 
>> >     (Informational)   
>> >           <draft-ietf-gsmp-dyn-part-reqs-02.txt>
>> >
>> >are SEs only layer 2, or can a virtual router be an SE?
> 
> Originally I think there was some "router" verbage in this draft with
> the idea that this draft be inclusive of partitioning both switches and
> routers.  I think the requirements in this draft are equally valid for
> LPM forwarding controlled by a protocol such as ForCES.  However, there
> may be requirements for forwarding devices that are not listed in this
> draft since they weren't necessary for the task at hand, namely
> partitioning of switches for GSMP.  At some point, groups like ForCES
> and PPVPN should take a look at this draft/RFC and propose any changes 
> they feel are necessary to support LPM-based forwarding devices.

Perhaps a statement similar to this should be should be put in the 
beginning of the document somewhere.

> 
> Most likely, the only effected requirement will be requirement #3 which
> states that the partitioning protocol be able to partition resources
> used by GSMP switches.  There are other resources commonly found on
> media gateways and in routers that wouldn't be included in this 
> requirement.
> 

Is there any value in generalizing the requirement a little?  One thing 
that concerns me is that should we decide to suggest GSMP as a solution 
to ForCES, something I am thinking about, it would require additions to 
these requirements.  Now, while we cannot require those yet, it might be 
reasonable to add a requirement that all future additions to the 
protocol will need to include support for their particular partitioning 
requirements.

>> >microsoftisms in the text
> 
> Egad, I've been brainwashed!  Tell me what they are and I will 
> remove them.

I think I found 4 instances:
partition's twice on page 2
controller's on page 4
PM's on page 5

[ note: I can't believe i missed them when I reviewed it during last 
call. Teaches me I must print drafts I intend to review and not just try 
and do it quickly on the screen.  Speaking of WG last calls - how are 
folks doing with 
http://www.ietf.org/internet-drafts/draft-ietf-gsmp-reqs-03.txt ?]

BTW while we are being typographical  there are also references to 
[GSMPv3]  that should be changed to [RFC3292]

> 
>> >in intro para 2, the enumeration omits the case where a single
>> >logical SE or controller might be implemented by multiple devices
> 
> The picture on page 4 indicates that multiple logical controllers can
> be attached to a single partition.  You could call this combination
> of controllers itself a logical controller if you wanted to. Likewise, 
> a logical SE could be something like the combination of two partitions 
> of two different physical SEs.
> 
> I have no objection to adding such examples to the draft.  However, I 
> think the draft as it is does not preclude someone from doing either 
> of the aforementioned aproaches.

I think that adding some of the more extreme examples is a good idea.

> 
>> >   Dynamic Partitioning 
>> >    
>> >   Static repartitioning of a SE can be a costly and inefficient 
>> >   process.  First, before static repartitioning can take place, all 
>> >   existing connections with controllers must be severed.  When this 
>> >   happens, the SE will typically release all the state 
>> configured by 
>> >   the controller.
>> >
>> >you might make clear that one or more static partitions of the SE
>> >may not be affected by the change(s) and hence would not be
>> >disturbed.  e.g. one could have an SE with O(10^3) partitions and
>> >only be mucking with a few.
> 
> Suggest a change to the following wording:
> 
> "Static repartitioning of a SE can be a costly and inefficient 
> process.  First, before static repartitioning can take place, all 
> existing connections with controllers FOR THE EFFECTED PARTITIONS
> must be severed."

I think it is Affected Partitions

> 
>> >as requirement three allows starvation, this needs to be mentioned
>> >in sec cons 
> 
> "3.	Furthermore, this mechanism MUST support the partitioning of all
> resources discoverable through GSMP (e.g., label tables).  Other resources
> used by GSMP indirectly (e.g., CPU) or resources (e.g., forwarding table
> entries) used by other types of SEs MAY be supported."
> 
> This requirement allows starvation?  If so, how?  I'm not seeing it.

I don't think this one does, but Req. 4 does.
Though I think this is covered by the requirements for authentication 
etc. ot eh PM.  but it might be worth mentioning in the security section 
that this is a possible problem that the authentication is meant to cover.

> 
>> >sec cons says
>> >
>> >   Only authorized PMs MUST be allowed to dynamically repartition a
>> >   SE
>> >
>> >etc.  but there is no hint of security relationships.  are SEs
>> >statically bound to PMs and vice verse?
> 
> This issue was never specifically discussed but based on our
> discussions I infer that we believed that the relationship could be
> dynamic and configurable based on the preferences of the owner of
> the resources.  The SE could be configured to know its PM through
> a console (physical security) or via an existing, secure configuration
> protocol...take your pick.
> 
> There might be a potential requirement here when a SE is assigned to
> a knew PM...does the SE forget all of its state or maintain its state?
> If it maintains the state then how is the new PM to discover how the
> device is currently partitioned?
> 

While we don't necessarily need to solve this now, it might be good to 
explore the problem and to add a requirement on the need to establish a 
secure process for PM discovery and binding.

>> >what are the implications of a requirements document having ipr?
> 
> I don't believe any of the authors intended to claim IPR so if that
> is implied in the draft then we can just excise that part.

Good idea.

Thanks for the comments.

To the List:  Any other comments?  Please get them in as soon as possible.

To the editors:  How soon can we get a revision.

While none of these changes are seriously technical, I believe they are 
sufficiently substantive to warrant another WG last call.  Once the new 
draft is released, I plan to schedule a 1 week last call on the changes.

a.

> _______________________________________________



_______________________________________________
GSMP mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/gsmp