Fair enough.
In this case, what I was refering to is the combination of two
preorpties of the encoding of paths.
On teh one hand, it is extraordinarily flexible in being able to
represent a broad range of delegated choices (as well as allowing the
controller to advertise very specific things.
At the same time, it has no explanations for which ways of using those
tools will or will not work, are intended to work, or should not be used.
One example is the quesiton i raised on the list is an SFP with two SFF
each of which has two different SF types, A and B. That seems like a
natural thing to do, given the coding. It is extremely unlikely to
produce a desirable result in reality.
There is significant value in a flexible represent. There is also
significant danger if the users can not figure out what will and will
not work. Or if they can not tell if the necessary external properties
can be met.
Yours,
Joel
On 11/12/16 5:32 PM, Adrian Farrel wrote:
Joel said...
One of my concerns with the proposed BGP encoding is that it can represent
many things that will not work. This seems to make it fragile.
Joel, if I may, can I call you out on that generalisation?
I don't find anything in your statement that I can discuss or debate. Perhaps you could
help with an example of what thing you might encode that "will not work".
Thanks,
Adrian
PS I have cross-posted this mail to SFC and BESS as requested by the AD
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
