[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-v6ops-v6inixp-04.txt WGLC
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?
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) 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).
I still prefer the second option and recommend that to be included in
this document as an alternative approach.
Thanks,
--
Eduardo Ascenço Reis