headers
Dong Jie | 1 Apr 2009 11:24
Favicon

Re: draft-marques-idr-best-external-01.txt as IDR WG doc

Hi,
I have some questions about the draft.

1. In section 4, the example of "inconsistency in routing" uses the path
selection rules of RFC1771, which has been obsoleted by RFC4271. RFC1771
specified the "internal update process" in section 9.2.1, in which BGP
elected the best path from all of the external paths for IBGP peers. IMO,
RFC1771 can provide best external path for IBGP peers, and this draft elects
the best external path with a different procedure. Is my understanding
correct?
But RFC4271 doesn't have any corresponding specification about "internal
update process". If we use the rules of RFC4271 in this example, R3 would
advertise its overall best path (b) to R4, so R4 will receive (c) from R1
and (b) from R3, then R4 would pick (b) (using the IGP cost tie-breaking)
and advertise it to AS X. In this scenario, there would be no inconsistency
between routing and forwarding. 
With respect to solving the inconsistency problem, is this draft better than
RFC4271? 

2. In section 3, it says" In order for the reflector to be able to advertise
the best external route into the cluster, it is necessary that
client-to-client reflection be disabled, since its advertisement may
otherwise contain the best route within the cluster domain. " 
Does it mean that clients need to be full-meshed when best-external is used?
If not, inconsistency between routing and forwarding can happen in some
scenarios.

Best regards,
Jie
(Continue reading)

Permalink | Reply | 2 comments |
headers
David Freedman | 1 Apr 2009 15:28

Re: draft-scholl-idr-advisory-00

So it seems to me , we have a number of differing views here.

Scholl recommends we have an unstructured payload, scoped by some
general "types" (I think this is in the -01 version, tom?), length will
be variable.

Nalawade originally recommends we have a structured payload but with the
capability to send an undefined string (see
draft-nalawade-bgp-inform-02, sec 6.1.1), this string can be of variable
length as well

Nalawade then recommends that the payload not include the freedom to
send an unspecified message (closest I could find was CEASE "5 - Other
Configuration Change" , see  draft-nalawade-bgp-soft-notify-01 sec 2.3)

Since a number of purists on here are not happy with the protocol being
"cluttered" by unspecified messages, a "middle of the road" approach
sounds like a structured payload with the ability to send an unspecified
message (without having to hide the fact), this could then be an
implementation decision.

An easy way to do this would be to place the ADVISORY payloads into
soft-notify "Event Message subcodes" (sec 2.3), they would fit quite
nicely here.

So I present the two alternatives as either

- Choose ADVISORY and don't bother with structured payloads

or
(Continue reading)

Permalink | Reply | 2 comments |
headers
Internet-Drafts | 2 Apr 2009 01:45
Picon
Favicon

I-D Action:draft-ietf-idr-flow-spec-07.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

	Title           : Dissemination of flow specification rules
	Author(s)       : P. Roque Marques, et al.
	Filename        : draft-ietf-idr-flow-spec-07.txt
	Pages           : 23
	Date            : 2009-04-01

This document defines a new BGP NLRI encoding format that can be used
to distribute traffic flow specifications.  This allows the routing
system to propagate information regarding more-specific components of
the traffic aggregate defined by an IP destination prefix.

Additionally it defines two applications of that encoding format.
One that can be used to automate inter-domain coordination of traffic
filtering, such as what is required in order to mitigate
(distributed) denial of service attacks.  And a second application to
traffic filtering in the context of a BGP/MPLS VPN service.

The information is carried via the Border Gateway Protocol (BGP),
thereby reusing protocol algorithms, operational experience and
administrative processes such as inter-provider peering agreements.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-flow-spec-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pekka Savola | 2 Apr 2009 07:34
Picon

MED in iBGP -> eBGP advertisement

Hello,

There doesn't appear to be any specification whether MED should be 
propagated from iBGP to eBGP on routes originated within the AS, 
except that about MED transitivity between ASs [1] (RFC 4271 S 5.1.4). 
See more about this below.

How should the implementation behave in this case?

This area of spec seems to be undefined, and the way MED transitivity 
is specified, it has implementation consequences.  Is this a problem?

FWIW, at least on Juniper, locally originated iBGP route MEDs are not 
propagated to eBGP unless you touch the MED explicitly in eBGP policy 
(e.g. 'metric add 0').

[1] RFC4271 S 5.1.4 says:

    "The
    MULTI_EXIT_DISC attribute received from a neighboring AS MUST NOT be
    propagated to other neighboring ASes."

This does not seem to be implementable exactly as narrowly as written. 
Consider a route 1.0.0.0/8 from AS1.  Router A at AS2 with eBGP 
session to adds MED=100.  The route is advertised to router B at AS2. 
Router B has no way of knowing whether MED attribute was added at AS2 
or AS1, and the only alternative for routes originated outside its own 
AS is to not propagate the metric.  For consistency, one could argue 
that locally origianted routes should also by default propagate the 
metric but that seems unspecified.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Pekka Savola | 2 Apr 2009 08:06
Picon

Re: MED in iBGP -> eBGP advertisement

On Wed, 1 Apr 2009, Jakob Heitz wrote:
> Now: The purpose of the MED is for the receiving AS to make
> a routing decision based upon it. Therefore, to be useful, the MED
> must be a DIFFERENT value at each point you export the route
> to the other guy. For the pedants: not the same at every point
> all the time.

That's right, but one possible way to make it different is to set a 
different MED towards different iBGP peers and as a result the 
external MED would be different.

--

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr
Permalink | Reply | 1 comment |
headers
Jakob Heitz | 2 Apr 2009 08:06

Re: MED in iBGP -> eBGP advertisement

You have two choices:
A) MED is generated at the point where a route enters the AS,
    That is either where it is originated or where it is received
    by EBGP.
B) MED is generated by each router that exports the route to a
    neighboring AS: The EBGP exit point.

Now: The purpose of the MED is for the receiving AS to make
a routing decision based upon it. Therefore, to be useful, the MED
must be a DIFFERENT value at each point you export the route
to the other guy. For the pedants: not the same at every point
all the time.

That's only going to happen with choice B.
I vote for choice B.

 From this, it follows that if a router receives a MED on IBGP,
that the MED was generated in the neighboring AS.

--
Jakob Heitz.

Pekka Savola wrote:
> Hello,
> 
> There doesn't appear to be any specification whether MED should be 
> propagated from iBGP to eBGP on routes originated within the AS, except 
> that about MED transitivity between ASs [1] (RFC 4271 S 5.1.4). See more 
> about this below.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jakob Heitz | 2 Apr 2009 08:36

Re: MED in iBGP -> eBGP advertisement

Pekka Savola wrote:
> On Wed, 1 Apr 2009, Jakob Heitz wrote:
>> Now: The purpose of the MED is for the receiving AS to make
>> a routing decision based upon it. Therefore, to be useful, the MED
>> must be a DIFFERENT value at each point you export the route
>> to the other guy. For the pedants: not the same at every point
>> all the time.
> 
> That's right, but one possible way to make it different is to set a 
> different MED towards different iBGP peers and as a result the external 
> MED would be different.

Then the MED you propagate around your own AS is your own.
That means you erased the MED your upstream sent you and
you can not make routing decisions based upon it. I guess this
is ok if you ignore received MEDs.

I can see nothing stopping you from doing it. Seems like a
simple knob to add. You would have to make sure every router
in your AS is doing it the same way though.

--

-- 
Jakob Heitz.

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

Permalink | Reply | 0 comments |
headers
Danny McPherson | 2 Apr 2009 16:36
Favicon

Re: MED in iBGP -> eBGP advertisement


On Apr 1, 2009, at 11:34 PM, Pekka Savola wrote:
>
> This does not seem to be implementable exactly as narrowly as  
> written. Consider a route 1.0.0.0/8 from AS1.  Router A at AS2 with  
> eBGP session to adds MED=100.  The route is advertised to router B  
> at AS2. Router B has no way of knowing whether MED attribute was  
> added at AS2 or AS1, and the only alternative for routes originated  
> outside its own AS is to not propagate the metric.  For consistency,  
> one could argue that locally origianted routes should also by  
> default propagate the metric but that seems unspecified.

In reality, externally announced prefixes for locally
routes are often aggregated and announced from multiple
locations in the network.  This is the "aggregation
breaks MEDs" argument and makes a case that an AS may
not want to accept MEDs from an adjacent AS for routes
that they originate, but only for routes from downstream
ASes.

This and other MEDS issues are discussed in more detail
in RFC 4451.

I would be opposed to deriving MEDs from IGP metrics as
a default behavior.

-danny
_______________________________________________
Idr mailing list
Idr <at> ietf.org
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rob Shakir | 2 Apr 2009 17:08

Re: draft-scholl-idr-advisory-00

On Wed, Apr 01, 2009 at 02:28:03PM +0100, David Freedman wrote:
> So I present the two alternatives as either
> 
> - Choose ADVISORY and don't bother with structured payloads
> 
> or
> 
> - Choose SOFT-NOTIFY and ammend it to suit the purposes of ADVISORY
> 
> Both of these cases would satisfy the operator community I believe
> (please, somebody correct me if I'm wrong)

Dave,

Thanks for this summary.

I think the major point here, from my point of view  is that we need some way to
be able to deliver a non-fatal message to our peer, to be able to react to some
anomaly, or transmit some further information in-band. I agree that a
soft-notify with some advisory-esque enhancements would deliver this, as would
Tom's draft.

As you say, either is an enhancement to the protocol. I can see both pros and
cons of the additional structure that INFORM brings, but this can also be said
for the flexibility that ADVISORY would bring. I don't have any strong
preference between the two drafts.

I think the worst case here is that we end up with neither INFORM nor ADVISORY,
and end up with two drafts that would have enhanced the operation of the
protocol being rejected.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Pradosh Mohapatra (pmohapat | 2 Apr 2009 19:41
Picon
Favicon

Re: draft-marques-idr-best-external-01.txt as IDR WG doc

Hi Jie,

| 1. In section 4, the example of "inconsistency in routing" 
| uses the path selection rules of RFC1771, which has been 
| obsoleted by RFC4271. RFC1771 specified the "internal update 
| process" in section 9.2.1, in which BGP elected the best path 
| from all of the external paths for IBGP peers. IMO,
| RFC1771 can provide best external path for IBGP peers, and 
| this draft elects the best external path with a different 
| procedure. Is my understanding correct?

That's correct. This draft defines a different procedure
based on total ordering of the paths to select and advertise
the best external path.

| But RFC4271 doesn't have any corresponding specification 
| about "internal update process". If we use the rules of 
| RFC4271 in this example, R3 would advertise its overall best 
| path (b) to R4, so R4 will receive (c) from R1 and (b) from 
| R3, then R4 would pick (b) (using the IGP cost tie-breaking) 
| and advertise it to AS X. In this scenario, there would be no 
| inconsistency between routing and forwarding. 

Right. With RFC4271 procedure, R3 would _advertise_ and _install_
the overall best path (b).

| With respect to solving the inconsistency problem, is this 
| draft better than RFC4271? 

We wouldn't consider is as solving inconsistency problem. E.g.
(Continue reading)

Permalink | Reply | 1 comment |

Gmane