[GHPN-WG] Feedback Stitching Framework

[Freek Dijkstra]

Hi Victor,

Traveling back from München I found some time to write feedback on the
stitching framework. I tried to be complete, listing both comments made
by others and myself during the gphn session.

Please keep GHPN <ghpn-wg at ogf.org> in the loop for replies (I'm not sure
if you are subscribed; if not: http://www.ogf.org/mailman/listinfo/ghpn-wg)

Regards,
Freek


1. Deployment
If this framework is deployment, must all domains along a path
participate? What happens if one domain has decided not to deploy it?
Would it still be usable for the other domains?


2. Transparency
Must a domain tell its direct neighbours all details, also if those
details are only relevant for domains further along the path?


3. Layer Dependencies
In the current proposal, each domain announces the different Types it
wants to negotiate, e.g. "IP", "Ethernet", "Physical", "UserSLS", and
"energy". Some of these types represent a certain technology (IP, SDH,
Ethernet, Physical), but _there is no order between these types_. This
is fine in the following scenario (as you had on your slides):

    Type        Domain 1    Domain 2    Domain 3
    IP               *                   *
    Ethernet         *       *   *       *
    Physical         *       *   *       *

(a star means the domain announces/supports that specific type.)
This leads to the following negotiation between the domains:

    Type        Domain 1    Domain 2    Domain 3
    IP               * <---------------> *
    Ethernet         * <---> *   * <---> *
    Physical         * <---> *   * <---> *

Which is great. However, what if domain 2 decides no longer to negotiate
the Physical type (perhaps because it thinks it is nonsense because it
is static anyway):

    Type        Domain 1    Domain 2    Domain 3
    IP               *                   *
    Ethernet         *       *   *       *
    Physical         *                   *

In that case, the stitching framework still sees no problem, and will
initiate the following parameter negotiations:

    Type        Domain 1    Domain 2    Domain 3
    IP               * <---------------> *
    Ethernet         * <---> *   * <---> *
    Physical         * <---------------> *

I think this is wrong, should be detected as an erroneous negotiation.
I believe this problem can easily be solved by introducing an "(layer)
depency" that is _optionally_ announced by every domain. In this case,
domain 3 would announce a dependency from Ethernet on Physical, meaning
that the Peering domain of the Physical type must either be the same as
the Peering domain of the Ethernet type, or closer in the path. For a
dependency from IP on Ethernet, this is true (the Ethernet peering
domain is closer in the path than the IP peering domain), but for a
dependency from . Because the dependency is announced by the domains,
instead of an inherent property of the type, this allows flexibility and
easy introduction of new types later.


4. Optional Types
Is it possible to announce an "optional" type? For example, a domain may
announce that it is willing to negotiate about "Energy" type or the
"userSLS" type, but it fine to forfeit the parameter negotiation of this
particular type if the Peer Domain is not willing or capable to perform
the negotiations?

(I have the impression that you already gave this some though, so there
might be another way how this is already solved in the current proposal.
However, I don't see it yet.)


5. Adaptation
The current example describe types as different technologies, contacts
or link weight parameters. It does not describe the relationship between
technologies. This might -falsely- be interpreted that the framework
also does not support negotiation of different adaptation parameters
(which tie technologies together on the data plane). I think it does,
but it might be helpful to include this as a particular example.

Let's say you have 10 gigabit/s Ethernet, and want to negotiate a
possible PMD (adaptation to the physical layer), and you can choose
between these 8 (of the 12 that 802.3 defines): 10GBASE-KR, 10GBASE-LRM,
10GBASE-SR, 10GBASE-LR, 10GBASE-ER, 10GBASE-SW, 10GBASE-LW, or 10GBASE-EW.


6. Tunnels
One of the strengths of the stitching framework is that it does not
enforce a certain ordering of the layer, so it supports a tunnel with
Ethernet over IP. However, what if I have a tunnel with IP over Ethernet
over IP over Ethernet over Physical, and I like to negotiate parameters
for all of them. In that case, there are two sets of parameters for the
types "IP" and "Ethernet". Is the stitching framework capable of making
sure that the one set of parameters is properly negotiated with the
correct other set, or is it random which set is chosen?


7. Physical
The physical type is IMHO an ill-defined type. The parameter negotiation
differ wildly depending if the physical layer is electrical or optical.
I recommend to change this to change the example to an Electrical and
Optical type.


8. WS-Agreement
It seems that this framework could very well make use of WS-Agreement,
which apparently provides a exchange mechanism to negotiate on certain
parameters.


9. Who?
Who has the time and willingness to pull the effort of making the ideas
into a protocol?


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 20090316 stitching framework.txt
Url: http://www.ogf.org/pipermail/ghpn-wg/attachments/20100319/0e46bf5a/attachment.txt