[GHPN-WG] Feedback Stitching Framework

[Victor Reijs (work)]

Hello Freek,

Thanks for making this list of the GHPN group. Really appreciated and I 
also want to thanks the opportunity to be able to present it. Below is 
my feedback.

Freek Dijkstra wrote:
> 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?

The SF (Stitching Framework) says that are each others Peering domains 
need to decide together to take part or not. So they do it in pairs!

Physical parameters most of the time end at the next (Neighboring) 
domain in the path, but higher layer parameters can end up in other 
domains (multiple hops further away in the path).

In the prototype implementation: If one of the peering domains in a pair 
does not take part, the participating domain will get a warning that no 
peering domain has been found.

As the SF can't find out where the other peering domain is (as a Peering 
domain can be anywhere in a path), such a warning ends up in a non 
implementable path.

At present SF definition can only work if both parties in a peering 
relation take part or both don't take part.
If if both peering domain (remember Peering domains pair exist at 
multiple layers)

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

In the present form if the SF, the parameters are not send to the a 
domain in the path, but are send to a central entity (which can be any 
where):  Stitching Engine: SE. In the document it is proposed that the 
Home domain (where a user below to) coordinates this SE activity. The 
Home domain does not have to take part in the realisation of the path of 
course.

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

Just a small thing: there is no negotiations between domains. Each 
domain tells the central entity what its capabilities are and then the 
central entity choices a working option (if possible). If the full path 
is a feasible path, then the SE will confirm to each domains what 
parameter option are to be implemented/reserved.

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

Correct. As the SF does not know the meaning of parameter's Data (or the 
Type), it will end up indeed as you say. It only matches the unique 
combination Name.Type.

 > I think this is wrong, should be detected as an erroneous negotiation.

If the SF would indeed know that physical means directly connected and 
if it assumes it is essential, then indeed it could generate an error 
message.

So like with your first question (Deployment); "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):" can only be done on 
a mutual/peering basis. So *peering* is essential/holy in SF!

That peering is *holy* in SF, assumes that indeed certain domains want 
to work together. Without that assumption no interworking is possible 
(in any way or the boots trapping becomes very difficult)).

This might be something where the general XML/WS activities become 
important: How do you find a services and how to you generate complete 
request?

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

Remember that dependency of layers is *not* inherent (layers don't exist 
in SF). In the SF it is tried to minimize dependencies.

But your proposal might work for this kind of cases. It would make it 
more dependanble on more rules (and thus open for change in rules in the 
future). This would need more study indeed.

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

There is an attribute 'Default' that is/was reserved for this. To be 
honest I have not looked in to this.
As the Peering domain is essential in SF and if *both* are found for a 
parameter, than Default might work. So *both* peering domains have to 
say they are peering (and in that case Default attribute might be useable).

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

Value of an attridute can be a list of options, so that allows for 
havign a chopice (and by the way the more optiosn provided by the 
domains, the easiest for the SE to come to a feasible path).

It is possible to use the 'Dependency' attribute for making 
dependencies, *But* this will need more study if it works indeed for all 
circumstance. Again dependencies make it more difficult and perhaps it 
would remove the advantages.

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

I think that when using tunneling, there is a differentiation of 
parameters: say a) certain physical parameters will not tunnel, also b) 
a tunnel might also introduce new parameters (tunnel related parameters 
that need to be used to demultiplex at the other peering end).
So I don't think that this issues will pop up.
More worked out examples would help here, to check indeed if no problems 
happen with tunnels.

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

No problem, you can define any string of letters you want;-) It is up to 
the technology experts to define these strings of letters.
<by the way: I can understand your point;-)>

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

It would be great to get more input on this. I think indeed that the SF 
does something very basic (as all negotiations work in some in that way: 
one defines mutually the terminology and then defines rules around them: 
humans also do this;-).

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

A good question!!! I think before working on the protocol, we need to 
make sure that all the point you brought up above are indeed solvable 
(so we need to tease things out a little more). HEAnet/GN3-JRA2-T2 are 
willing to work on that, hopefully with some other people.

I think also that we need to have a working sample (and not only a 
Visual BASIC prototype;-). We are working on that with GN3.

Making it a standardized protocol (*plus* guidelines, best practices, 
etc.): is a more difficult question. It at least needs that all the 
above things are satisfactory do-able.  It would be great to have a 
PhD/student working on this?
I think it is a worthwhile ideas certainly if it can help the WS framework.

Thanks again for putting down all these points.

All the best,


Victor


-- 
Victor Reijs, Network Development Manager
HEAnet Limited, Ireland's Education and Research Network
1st Floor, 5 George's Dock, IFSC, Dublin 1
Registered in Ireland, no 275301
tel: +353-1-660 9040  fax: +353-1-660 3666
web: http://www.heanet.ie/