I would say that the shim6 "argument" you are referencing has several
difficulties in trying to apply it.
1) It was based on a faulty understanding of shim6.
2) It was based on the premise that operators should have total and
absolute control over traffic engineering.
As I understood the argument, the claim was that shim6 "prevented"
operator traffic engineering. It didn't it restricted the scope to
engineering traffic that was explicitly addressed to given access points.
More importantly in our context, the exact same argument can be made
against CPE based LSIP, or any CPE based map-and-encaps.
In fact, given that the operator traffic engineering is typically based
on incoming traffic engineering (outbound traffic is much easier to
handle), the same "shim6 operator concern" can be applied even to PE
based LISP or map-and-encapss solutions.
Hence, if that argument is valid against host based solutions, then we
are completely out of luck.
Yours,
Joel
Scott Brim wrote:
marcelo bagnulo braun allegedly wrote on 02 16 2009 2:47 AM:
Hi Scott,
Scott Brim escribió:
A few thoughts on this quick draft:
Pure higher-layer approaches aren't acceptable:
- We knew that already, for operational reasons other than
renumbering, for example the shim6 argument.
what is the shim6 argument?
The argument that took place between the IETF and network operators when
shim6 was recommended.
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
