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

[Roque Gagliano <roque@lacnic.net>]

Hi Eduardo,

Thanks for your comments. Please see my responses inline.


On Jan 29, 2010, at 4:10 AM, Eduardo Ascenço Reis wrote:

> Hi Roque,
> 
> 2010/1/28 Roque Gagliano <roque@lacnic.net>:
>> 
>> (Roque) Eduardo, the problem is with downstream ISP customer's.
>> 
>> IXP ---- ISP1 --- ISP2
>> 
>> ISP2 implements uRPF, in order to help him with troubleshooting without breaking uRPF the ISP1 announce the IXP LAN.
> 
> Are you saying that ISP1 should advertise (BGP) the IPv6 Prefix
> corresponding to IXP LAN to ISP2?

(Roque)
I am not saying that it should or should not but that it a common practice to avoind the mentioned problem. This is the correspondent text in the document:

(Section 3)

"In this configuration
      participants may route these prefixes inside their networks (e. g.
      using BGP no-export communities or routing the IXP LANs within the
      participants' IGP) to perform fault management. "

This specific text was extensively discussed in this WG, please see the following messages:

http://ops.ietf.org/lists/v6ops/v6ops.2009/msg00682.html
http://ops.ietf.org/lists/v6ops/v6ops.2009/msg00680.html
http://ops.ietf.org/lists/v6ops/v6ops.2009/msg00694.html
http://ops.ietf.org/lists/v6ops/v6ops.2009/msg00530.html

Do you have any specific improvement to the text?


> I understand that we are discussing about the case when IPv6 IXP LAN
> is not globally routed. Considering that ISP1 is not IXP
> owner/operator it has no authority to generate an IPv6 prefix on its
> BGP Internet table, neither advertise it to outside its domain.

(Roque)
This practice has to do with its customers (downstream), not globally advertisement.

Funny that you mentioned authorization, because this issue came out in the SIDR mailing list a couple of month ago about how to handle this problem. The conclusion was that IXP operators would have to authorize each participant to originate the IXP LAN prefix issuing a ROA for each participant ASN.

You can read the thread at:
http://www.ietf.org/mail-archive/web/sidr/current/msg00975.html

> 
>> 
>> (Roque) In the previous example, for each traceroute passing by the IXP LAN, the packet with source IP in the IXP LAN will be discarded thanks to uRPF.
>> 
> 
> This is true for test from ISP2 to others IXP participants and if ISP2
> has uRPF on its link to ISP1.
> 
> But ISP2 is not an IXP participant and the IPv6 IXP LAN is not
> globally routed. So that is it.
> 
>>> 
>>> I understand that the fundamental routing point about this discussion
>>> is if the IPv6 prefixes learned by a participant AS have NEXT_HOP
>>> attribute reachable for the AS BGP enable routers, which may be done
>>> by routing the IPv6 IXP netblock inside the AS IGP or changing the
>>> prefixes NEXT_HOP for an AS internal IPv6 address (e.g. loopback from
>>> router connect to IXP).
>> 
>> I do not get your point here. Are we still talking about the IXP LAN prefix?
>> 
> 
> Sure. We are discussing about Multilateral Peering Agreements, when
> participants normally establish their BGP sessions using IXP IPv6 LAN
> address and it is not globally routed.
> 
> Considering that and in order for IPv6 prefixes learned from IXP
> peering sessions to be reachable inside their networks, participants
> AS have basically two options:
> 1. Route IPv6 IXP LAN into their IGP.
> 2. Change NEXT_HOP attribute to something reachable and under its
> domain (e.g. a /128 from one of its IPv6 netblocks).
> 

(Roque) So, you are basically talking about the configuration of the iBGP sessions from the router to its own network. I do not think this belongs to this document.

Roque.


> I still prefer the second option and recommend that to be included in
> this document as an alternative approach.
> 
> Thanks,
> 
> -- 
> 
> Eduardo Ascenço Reis