[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-v6ops-v6inixp-04.txt WGLC
On Tue, 2 Feb 2010, Roque Gagliano wrote:
What do you think about this text?:
--------------
6. Route-Server
...
Works for me.
The exchange point addresses are intended for the peering mesh,
e.g. from RIPE document: "Many Exchange Point operators require
address space for the peering mesh that is independent from any of
the address space in use by member networks."
(http://www.ripe.net/ripe/docs/ripe-451.html)
...
(Roque) So, the changes are in the first and last paragraphs of the
section where you are adding the possibility of using PA space for
services. I have no problem with the suggestion.
My suggested version does more than just suggest PA space for
services, it also describes that it's not necessarily a good idea to
run services off the IXP fabric space. If if you're fine with the
suggested text, it's fine with me.
(Roque) Your proposal does not cover the case of maintaining separate Physical ports for v4 and v6. What about this rewording:
2. independent LAN: an exclusive IPv6 LAN is created for IPv6
traffic. If IXP already uses Virtual LAN (VLAN) tagging,
participants are only required to passing one additional VLAN
tag across the interconnection. If IXP does not use VLAN
tagging, either VLAN tagging is established (where previous use may
continue untagged as a "native VLAN" or be transitioned to a tagged VLAN)
or a separate physical port is configure for each participant IPv6 traffic.
s/passing/pass/ above (that was wrong in my suggestion above), in
priniciple I'm OK with this.
Are you aware of IXes which provide separate Physical ports for v4 and
v6? While you're technically correct, this seems like a lot of waste
and I doubt there would be interest for that approach.
If it's actually used somewhere, I'm starting to wonder if
"independent LAN" would be clearer if it was split into two different
options, "independent VLAN" and "independent port". These have so
different properties in many ways, as was shown in my next
comments that have now been adapted.
(Roque) What about the following reworking for this complete section?:
I'm fine with that text.
7. External and Internal support
Some external services that need to have IPv6 support are traffic
graphics, DNS, FTP, Web, Route Server and Looking Glass. [...]
.. I'd maybe add that "In many cases, these are subcontracted or
otherwise acquired from exchange participants or third parties."
This is the "ISP-side" of IXP business and that should be kept
distinct from the IPv6 peering fabric issues.
(Roque) I would rather not get to particulars here, the important is
that it is something to put in their "checkbox".
The reason I was saying this is that I think this isn't an IX-specific
issue. The most relevant are probably Route Server and looking glass,
but otherwise this is pretty much identical to how an enterprise or an
ISP would run its support services. As such I think adding a
statement like I suggested above would clarify to the reader that
these are not IX-specific services, and indeed, in many cases the IX
does not need to provide them on its own.
These are IMHO also not a requirement for an IX to get
globally-routable PI or PA space and that's another reason why it's
worth spelling out.
(Roque) What about this text:
This memo includes procedures for monitoring and/or avoiding
particular ICMPv6 traffic at IXPs' LANs. None of these methods prevent Ethernet loops
caused by mischief in the LAN. The document also mentions how to
limit IPv6 DoS attacks to the IXP switch fabric by not globally
announce the IXP LANs prefix.
I think the global announce text could maybe be slightly better (its
implying that the default is globally announce instead of NOT
announce), but it's not technically wrong so I'm fine with it.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings