[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Bad routes update

SOrry for the latency on this.

->My comments on draft-ietf-ngtrans-harden-00.txt:
->  < 3.9 Inter-site links
->  < Global IPv6 addresses must be used for the end points of
->  < inter-site links.  In particular, IPv4 compatible addresses
->  < MUST NOT be used for tunnels.
->  < Prefixes for inter-site links MUST NOT be injected in the
->  < global routing tables.
->1) I don't understand why this has to be mentioned. There may be
->a inter-site link without global addresses. I think that this is
->a matter local to the peers, and we don't have to limit possible
->2) This document focuses on prefixes so I'm not sure this should
->be included: a pTLA should use the RFC version of BGP4+ (RFC??).

I will make sure to add the RFC number. As far as comment #1, I believe that
it is technically feasible to use non-standard IPv6 address for inter-site
links. I can agree that MUST NOT may need to be changed to SHOULD NOT here.
My motiviation for this statement was from a best-practices point of view,
rather than a technically-in-order-to-work point of view, so relaxing this
si viable. Good comment.

->  < 4. Routing Policies
->3) About multi-homing. As you mentioned the current agreed IPng
->WG procedures, is limiting to /24 and /28 a requirement that
->comes from IPng WG? Or, is it expressing that 6bone doesn't
->accept any other solutions which may require even a little bit
->relaxed rules?

I can and have put some verbiage in version 01.txt for this document to
relax this, to say that we will operate within current aggregation policy
constraints, but that we may change this should it become necessary to test
the feasibility of multi-homing solutions. However, I think it very
important to operate in the aggregation scheme now, as what people are doing
on the 6bone now is NOT a viable solution, but a fundamental break in v6
routing, in order to get around a problem. 
->I personally agree to pursue solutions that conform to this
->routing policy, but I think that the discussion/deployment is
->still on-going in IPng WG. I'd like to clarify the position of