recommendation for iBGP multipath plus IGP multipath

Hello all,

I'm searching drafts, papers, presentation slides, etc. in regard to
the recommendation for traffic dividing under iBGP multipath plus IGP
multipath environment, because I have observed different behaviours
through my test with some production routers. Would you please give
me any information of this case if you have?

Best regards,
--

-- 
Tomohiko Kurahashi <kura <at> iij.ad.jp>

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr

Re: BGP issues

Hi Iljitsch,

As we are discussing BGP i am redirecting this to idr list for IDR WG to 
comment or work on.

>> But I would like to also see the real list of what are the issue in 
>> BGP we are trying to address ... Is this point-to-point model, is this 
>> TCP transport, is this update format ... No one yet stated what is 
>> broken. And when we do not know what is broken .. or which link of BGP 
>> chain is fragile it is quite a challenge to design new thing around 
>> the unknown.
> 
> In addition to the fact that it's possible to configure iBGP such that 
> you can have routing loops?

Could you provide an example ?

> it suffers from some of the problems inherent to distance vector
> routing, such as slow convergence

BGP can converge today in subseconds. More over BGP routes with correct 
implementation may converge in prefix independent manner. It is not that 
BGP is slow. The vast majority of end to end convergence is a product of 
failure localization, failure detection time and failure propagation 
time. BGP can be made even today to propagate more then one path within 
given AS when best external functionality is in place. Ask your 
favourite vendor for details. More over there are also proposals 
discussed at IDR to send more then best path in BGP.

 > Another problem area for

Re: BGP issues

On 9 jan 2008, at 14:02, Robert Raszuk wrote:

> As we are discussing BGP i am redirecting this to idr list for IDR  
> WG to comment or work on.

Ah, I saw that you wrote a reply but I couldn't find it at first.  

>> In addition to the fact that it's possible to configure iBGP such  
>> that you can have routing loops?

> Could you provide an example ?

R1e - R2i - R3i - R4e

If R1 and R4 both prefer their eBGP path towards a certain destination  
and then R2 prefers the path over R4 while R3 prefers the path over  
R1, packets will loop between R2 and R3. Note that this configuration  
only happens when applying policy to iBGP sessios or in unfortunate  
route reflector placement.

>> it suffers from some of the problems inherent to distance vector
>> routing, such as slow convergence

> BGP can converge today in subseconds.

Sure, but it can also take many minutes, especially with a min-route- 
advertisement timer in effect in many places and if the update is a  
withdrawl. Now I've argued that this shouldn't be too problematic  
because if you're revoking your advertisement that means you're  
unreachable anyway, but not everyone agrees with that. (Not good if  

Re: BGP issues

Hi Iljitsch,

>>> In addition to the fact that it's possible to configure iBGP such 
>>> that you can have routing loops?
> 
>> Could you provide an example ?
> 
> R1e - R2i - R3i - R4e
> 
> If R1 and R4 both prefer their eBGP path towards a certain destination 
> and then R2 prefers the path over R4 while R3 prefers the path over R1, 
> packets will loop between R2 and R3. Note that this configuration only 
> happens when applying policy to iBGP sessios or in unfortunate route 
> reflector placement.

Altering best path selection on IBGP routers is a bad idea when you have 
hop by hop switching.

>> BGP can converge today in subseconds.
> 
> Sure, but it can also take many minutes, especially with a 
> min-route-advertisement timer in effect in many places and if the update 
> is a withdrawl. Now I've argued that this shouldn't be too problematic 
> because if you're revoking your advertisement that means you're 
> unreachable anyway, but not everyone agrees with that. (Not good if you 
> are revoking a more specific and you want the aggregate to attract the 
> traffic.)
> 
> One reason that BGP is getting chattier is because updates tend to be 
> multiplied if there are several interconnects between two ASes.

RE: Re: BGP issues

Hi Iljitsch,

Good points. However, we should not mix up 'what's deployed' with
'what's a allowed by the protocol'.

By all means, the BGP traffic engineering and BGP deaggregation points
are worthy of further discussion. 

> worse, they can make it 65 or 67. This allows finer grained control  
> that the AS path so it reduces the need for deaggregation for TE  
> purposes.

I think that you are alluding to enabling each transient AS to attach
its relevant weight/preference for each BGP prefix. This furhter enables
each AS to get end-to-end metric for each prefix with or without the
AS_PATH. Correct?

While I agree that it may help wrt TE, but it doesn't fully solve the
deaggregation. For example, a network may advertise one chunk of
prefixes (bunch of /24s) to one AS and antoher chunk (bunch of /24s) to
another AS to receive the traffic accordingly from different Ases,
though the network could have advertised one aggregate /23 (say).

> >> There is no validation of routing
> >> information beyond the next hop.
> 
> > Are you alluding to S-BGP/so-BGP proposals ?
> 
> Yes, to their problem statement, at least. Not sure if drowning  
> everything in sticky crypto syrup is the best solution, though.

Re: Re: BGP issues

On Jan 11, 2008, at 11:29 AM, Iljitsch van Beijnum wrote:
> However, this is probably relatively easy to fix ("start now" ....  
> "forget all the prefixes that I haven't refreshed since "start  
> now"") but the fix will probably be hard to deploy.

If you squint hard enough you will realize that this is available  
today under the name "graceful restart".

--John

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr

Re: Re: BGP issues

On Fri, 11 Jan 2008, Iljitsch van Beijnum wrote:

> I would like to see a value that is increased by every AS (twice, 
> for good measure: once on reception, once on transmission),

That's one to add to the "AS_PATH reform" list possibly (encoding 
AS_PATHs as {ASN,metric} has been proposed before).

regards,
--

-- 
Paul Jakma	paul <at> clubi.ie	paul <at> jakma.org	Key ID: 64A2FF6A
Fortune:
Few things are harder to put up with than the annoyance of a good example.
 		-- "Mark Twain, Pudd'nhead Wilson's Calendar"

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr

6PE-Alt draft

Hi folks,

We have written a draft which will possibly replace the 6PE RFC. The
6PE RFC uses a label to be sent along with the prefix for each route.
This label is then used as the "VPN label" (keeping with the
terminology of BGP MPLS IP VPN RFC). However the only use the label
serves is to tell the encapsulated packet is an IPv6 packet, as well
as some additional uses as defined in the RFC.

Because a VPN label is required and its only use is to signal that the
inside packet is IPv6, we instead elegantly use the "IPv6 Explicit
NULL label". This label signals the same information. The advantage is
that labels need not be added with the routes and no such extension is
required. It also considerably simplifies the Multi AS scenarios.

The draft will soon be visible in the IETF site and is attached here. I
have removed some sections of the draft temporarily so that the mail
does not bounce from the IDR list.

Thanks,
Vishwas and Manoj

                   
Internet Engineering Task Force                           Vishwas Manral
Internet-Draft                                               Manoj Dutta
Intended status: Standards Track                        IP Infusion Inc.   
Expires: July 30, 2008                                       
                                                       January 30, 2008

Re: 6PE-Alt draft

Hi Jan,

You may be missing the scope of the document. There is a discussion in
the v6ops group too which .

The idea is simple. We do not need to define a new AFI/ SAFI
combination to achieve the 6PE functionality. We can just use the
meaning implied in the IPv6 Explicit NULL label. The 6PE RFC does talk
about allowing signaling for the Explicit NULL label in which case the
dataplane functionality becomes just the same, but in 6PE even that is
signaled using BGP extensions defined in RFC3107.

Thanks,
Vishwas

On Jan 31, 2008 2:14 AM, Jan Novak <jjjnovak <at> hotmail.com> wrote:
>
>
> Hi,
>
> Just out of curiosity - lets say you have two IPv4 VPNs with
> overlapping set of Pes and both of them want to provide 6PE
> service.
> When the explicit-null encapsulated packets from two different
> VPNs (but same PE) arrive to the other side PE - how do you
> decide which is which - e.g. which packet should be shipped to
> which VPN ??
>
> Jan
>

Re: 6PE-Alt draft

Hi Jan,

I am CC'ing the authors of the 6PE draft to get their views. Let me
explain the draft in greater detail however.

In 6PE, MP-BGP SAFI family label is used to exchange routes between 2
6PE routers (a new AFI/ SAFI combination is defined). Each route is
attached with a label (which may be the IPv6 Explicit NULL label). In
the data-plane this label is used as the inner label and the other
label is the tunnel label, which gets the packet from source PE to
destination PE. Once the packet gets to the destination PE, the inner
label is looked up and a POP operation is done on it and the IPv6
header is looked up in the routing table.

With 6PE-Alt, no additional signaling mechanism is required. All we
need to do is instead of using the signaled label as the inner label,
we use the IPv6 Explicit NULL label. The same operations happen as 6PE
without any explicit signaling of the labels with each route. It helps
prevent all the excess signaling and still providing the exact same
functionality. We are using the meaning implied in the "Explicit NULL
Label". We do not need to signal anything here.

As an alternate, if you notice in IPv6, the end sites/ devices will
become IPv6 and the network may still have IPv4. If the assumption
that each device in the IPv6 networks has a Global IPv6 address (not
that IPv6 site local has been deprecated), we can do without the
entire BGP MPLS IPv6 VPN functionality.

Thanks,
Vishwas