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

Comments and questions in-line.

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.

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.

> >microsoftisms in the text

Egad, I've been brainwashed!  Tell me what they are and I will 
remove them.

> >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.

> >   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."

> >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.

> >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?

> >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.
_______________________________________________
GSMP mailing list
GSMP@ietf.org
https://www1.ietf.org/mailman/listinfo/gsmp