Re: draft-ietf-v6ops-v6inixp-04.txt WGLC

[Roque Gagliano <roque@lacnic.net>]

Hi Pekka,
Thanks again for your comments.I believe we came up to one section to be improved. 

Here is the proposed text for section 2 using your feedback:

---------------------
2.  Switch Fabric Configuration

   An Ethernet based IXP switch fabric implements IPv6 over Ethernet as
   described in [RFC2464].  Therefore, the switching of IPv6 traffic
   happens in the same way as in IPv4.  However, some management
   functions may require explicit IPv6 support (such as switch
   management, SNMP [RFC3411] support and flow analysis exportation) and
   this should be assessed by the IXP operator.

   There are two common configurations of IXP switch ports to support
   IPv6:

   1.  dual-stack LAN (Local Area Network): when both IPv4 and IPv6
       traffic share a common LAN.  No extra configuration is required
       in the switch.

   2.  independent VLAN (Virtual Local Area Network): when an IXP
       logically separates IPv4 and IPv6 traffic in different VLANs.

   In both configurations, IPv6 and IPv4 traffic can either share a
   common physical port or use independent physical ports.  The use of
   independent ports can be more costly in both capital expenses (as new
   ports are needed) and operational expenses.

   When using the same physical port for both IPv4 and IPv6 traffic,
   some changes may be needed at the participants' interfaces
   configurations.  If the IXP implements the "dual-stack
   configuration", IXP participants will configure dual-stack
   interfaces.  On the other hand, if the IXP implements the
   "independent VLAN configuration", IXP participants are required to
   pass one additional VLAN tag across the interconnection.  In this
   case, if the IXP did not originally use VLAN tagging, VLAN tagging may to
   be established and previous use may continue untagged as a "native
   VLAN" or be transitioned to a tagged VLAN.  The "independent VLAN"
   configuration provides a logical separation of IPv4 and IPv6 traffic,
   simplifying separate statistical analysis for IPv4 and IPv6 traffic.
   Conversely, the "dual-stack" configuration (when performing separate
   statistical analysis for IPv4 and IPv6 traffic) would require the use
   of flows techniques such as IPFIX [RFC5101] to classify traffic based
   on the different ether-types (0x0800 for IPv4, 0x0806 for ARP and
   0x86DD for IPv6).

   The only technical requirement for IPv6 referring link MTUs is that
   they need to be greater than or equal to 1280 octets [RFC2460].  The
   MTU size for every LAN in an IXP should be well known by all its
   participants.

---------------------

Roque


On Feb 3, 2010, at 7:59 AM, Pekka Savola wrote:

> 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