headers
Glen Kent | 1 Sep 01:58
Picon

Re: draft-bhatia-bgp-multiple-next-hops vs draft-walton-bgp-add-paths

Curtis,

> You've just dismissed a real case above.  A minor misconfiguration
> (not setting next-hop self) could result in routes being ambiguous.

Similarly, a minor misconfiguration (of setting as-override) can
result in possible occurances of routing loops.

So whats the point?

Is BGP flawed to not inherently work with misconfigurations around? I
think its a well known that there are infinite ways to axe your foot
with BGP; not setting next-hop-self in IXes would be just one of them.

>
> > E.g. where multiple-hop "restricts" paths advertisements in
> > accordance with (destination,target), the add-path approach on the
> > other hand can make it impossible to reconcile that two paths are
> > identical[2]. In other words, add-path turns BGP into a flooding
> > protocol between contiguous sets of add-path speakers[1].
>
> Nice try but you have a clearly flawed argument.
>
> You can still compare attributes in the above RS example to reduce the
> multipath set to a minimal set when readvertising.  You can

The idea behind add-paths is to NOT to look at the path attributes.
Moreover, i did not see your views on the scenario given below where
add-paths would result in a lot many Updates?
(Continue reading)

Permalink | Reply | 4 comments |
headers
Curtis Villamizar | 1 Sep 02:40
Gravatar

Re: draft-bhatia-bgp-multiple-next-hops vs draft-walton-bgp-add-paths


In message <92c950310608311658x55877185q53061ec6f95f688a <at> mail.gmail.com>
"Glen Kent" writes:
>  
> Curtis,
>  
> > You've just dismissed a real case above.  A minor misconfiguration
> > (not setting next-hop self) could result in routes being ambiguous.
>  
> Similarly, a minor misconfiguration (of setting as-override) can
> result in possible occurances of routing loops.
>  
> So whats the point?

Unless I'm mistaken, omitting next-hop-self is the default.

> Is BGP flawed to not inherently work with misconfigurations around? I
> think its a well known that there are infinite ways to axe your foot
> with BGP; not setting next-hop-self in IXes would be just one of them.
>  
> >
> > > E.g. where multiple-hop "restricts" paths advertisements in
> > > accordance with (destination,target), the add-path approach on the
> > > other hand can make it impossible to reconcile that two paths are
> > > identical[2]. In other words, add-path turns BGP into a flooding
> > > protocol between contiguous sets of add-path speakers[1].
> >
> > Nice try but you have a clearly flawed argument.
> >
> > You can still compare attributes in the above RS example to reduce the
(Continue reading)

Permalink | Reply | 3 comments |
headers
Pedro Roque Marques | 1 Sep 02:35
Favicon

Re: Progressing draft-bhatia-bgp-multiple-next-hops-01.txt

John G. Scudder wrote:

> Also, the fact that one non-obvious casualty of using next hop as 
> identifier has been identified leads me to be concerned that others, as 
> yet unidentified, may also exist. 

I'd like to suggest that rough consensus has been reached that the 
next-hop attribute is not a viable path identifier. Except for the 
authors, is there anyone that doesn't consider this to be a "self 
evident truth" by now ?

   Pedro.

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr
Permalink | Reply | 5 comments |
headers
Curtis Villamizar | 1 Sep 03:14
Gravatar

Re: draft-bhatia-bgp-multiple-next-hops vs draft-walton-bgp-add-paths


In message <200609010040.k810eHBw052103 <at> workhorse.brookfield.occnc.com>
Curtis Villamizar writes:

In message <92c950310608311658x55877185q53061ec6f95f688a <at> mail.gmail.com>
"Glen Kent" writes:
> >  
> > Curtis,
> >  
> > > You've just dismissed a real case above.  A minor misconfiguration
> > > (not setting next-hop self) could result in routes being ambiguous.
> >  
> > Similarly, a minor misconfiguration (of setting as-override) can
> > result in possible occurances of routing loops.
> >  
> > So whats the point?
>  
> Unless I'm mistaken, omitting next-hop-self is the default.

Forgot to mention that configuring AS-override results in a violation
of the BGP spec and therefore need not be considered.  Third party
next hop is explicitly mentioned in the BGP spec in "5.1.3. NEXT_HOP"
on page 26 and it is perfectly legal to use this feature.

Curtis

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

Permalink | Reply | 0 comments |
headers
Curtis Villamizar | 1 Sep 03:18
Gravatar

multiple-next-hops vs add-paths : AS confed example


There was no response to my AS confed example probably since it was at
the end of a long message and changed the topic.  So I'm resending the
example as a separate message.

Curtis

A similar situation exists with confederations.  A route may be passed
through different private AS but with BGP confederations the next hop
is generally not changed, relying on the next hop advertised by the
router that borders the external AS and relying on the IGP rather than
the set of EIBGP advertisers.  In this case the AS Paths would be
different *until* the confederation AS were dropped before advertising
the route externally.

Consider this case.

  ASe1 - R1/NH1 -----  R3/AS65001
                 \  /             \
                   X               R5/AS65003 - R6/AS65004
                 /  \             /
  ASe2 - R2/NH2 ----  R4/AS65002

R5 gets the following routes:

   R3:  AS65001 ASexternal1  NH1
        AS65001 ASexternal2  NH2

   R4:  AS65002 ASexternal1  NH1
        AS65001 ASexternal2  NH2
(Continue reading)

Permalink | Reply | 11 comments |
headers
Enke Chen | 1 Sep 07:13
Picon
Favicon

Re: multiple-next-hops vs add-paths : AS confed example

Hi, Curtis:

I went through your example, and agreed that the (prefix, nexthop) is 
not adequate to disambiguate paths in your example.

It seems to me that there is a problem with using (prefix, nexthop) as 
key even in this simplified version:

                               |
   ASe1 - R1/NH1 |----- R3/AS65001
                               |                                    \
                               |                                     
R5/AS65003 - R6/AS65004
                               |                                     /
                               | -------  R4/AS65002 

R5 would receive paths from R3 and R4 with the same nexthop but 
different as-paths. If we were to emulate full-mesh, R5 would need to 
advertise both paths to R6, which would not be possible with (prefix, 
nexthop) as the key.

As the full-mesh is the most robust BGP configuraiton we know, it seems 
fundamental that a multi-path extension should offer the ability to 
emulate the full-mesh.

-- Enke         

Curtis Villamizar wrote:

>There was no response to my AS confed example probably since it was at
(Continue reading)

Permalink | Reply | 8 comments |
headers
Enke Chen | 1 Sep 07:22
Picon
Favicon

Re: multiple-next-hops vs add-paths : AS confed example

Well, the drawing (for the simplified version) did not come out right.  
The simplified version basically merged R2 into R1, and put R1, R3 and 
R4 on a LAN.

                       R1  -----|------- R3 ---\
                                     |                      R5 - R6
                                     |--------R4 ---/

-- Enke

Enke Chen wrote:

> Hi, Curtis:
>
> I went through your example, and agreed that the (prefix, nexthop) is 
> not adequate to disambiguate paths in your example.
>
> It seems to me that there is a problem with using (prefix, nexthop) as 
> key even in this simplified version:
>
>                               |
>   ASe1 - R1/NH1 |----- R3/AS65001
>                               |                                    \
>                               |                                     
> R5/AS65003 - R6/AS65004
>                               |                                     /
>                               | -------  R4/AS65002
>
> R5 would receive paths from R3 and R4 with the same nexthop but 
> different as-paths. If we were to emulate full-mesh, R5 would need to
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Jakma | 1 Sep 09:02
Picon

Re: multiple-next-hops vs add-paths : AS confed example

Hi Curtis,

On Thu, 31 Aug 2006, Curtis Villamizar wrote:

> A similar situation exists with confederations.  A route may be 
> passed through different private AS but with BGP confederations the 
> next hop is generally not changed, relying on the next hop 
> advertised by the router that borders the external AS and relying 
> on the IGP rather than the set of EIBGP advertisers.  In this case 
> the AS Paths would be different *until* the confederation AS were 
> dropped before advertising the route externally.

> Consider this case.
>
>  ASe1 - R1/NH1 -----  R3/AS65001
>                 \  /             \
>                   X               R5/AS65003 - R6/AS65004
>                 /  \             /
>  ASe2 - R2/NH2 ----  R4/AS65002
>
> R5 gets the following routes:
>
>   R3:  AS65001 ASexternal1  NH1
>        AS65001 ASexternal2  NH2
>
>   R4:  AS65002 ASexternal1  NH1
>        AS65001 ASexternal2  NH2
>
> It doesn't seem that based on NH there is a good way to disambiguate
> the components of this multipath.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Paul Jakma | 1 Sep 09:41
Picon

Re: draft-bhatia-bgp-multiple-next-hops vs draft-walton-bgp-add-paths

On Thu, 31 Aug 2006, Curtis Villamizar wrote:

> This is true that the two peers *can* peer with the route server 
> only.  It is common practice that major providers rely on private 
> peerings rather than get their routes for other major providers 
> from a RS.  This is not a hypothetical, it is common practice. 
> You cannot dismiss existing common practice.

That wasn't my intention.

I had meant to make it clear that this is not a subtractive addition 
to BGP. The presence of an RS does not mean these private peerings 
must stop.

The ability to allow eBGP middle-men is /additive/ to any existing 
peering.

> Or distrust of anything that could become a single point of 
> failure. Some providers have more than one router at some major IX 
> and direct peer in pairs with other major providers.

Right.

> The case is where the route is not a direct customer of the 
> provider and is not getting transit to the IX through that provider 
> but is peering with another major provider with agreement to 
> exchange all routes.

That sounds an interesting case. Could you provide a diagramme for 
clarity? Is it:
(Continue reading)

Permalink | Reply | 4 comments |
headers
Paul Jakma | 1 Sep 09:52
Picon

Re: Progressing draft-bhatia-bgp-multiple-next-hops-01.txt

Hi Enke,

On Thu, 31 Aug 2006, Enke Chen wrote:

> In draft-walton-bgp-add-paths-03.txt, there was a "Path Identifier 
> Type" defined. With the Path Identifier Type, a BGP speaker will be 
> able to tell if a path identifier is a natural id (such as 
> router-id), and will not re-generate one for ibgp.

That seems an idea.

Though, its redundant information in many cases (e.g ORIGINATOR_ID, 
NEXT_HOP).

> We will clarify this point in the next revision.

Also, all contiguous paths of add-path speakers would have to be 
configured to use the same add-path-id type.

regards,
--

-- 
Paul Jakma	paul <at> clubi.ie	paul <at> jakma.org	Key ID: 64A2FF6A
Fortune:
If it has syntax, it isn't user friendly.

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

Permalink | Reply | 0 comments |

Gmane