Subject: [Idr] Proposed change to 9.1.2.2

From: "John G. Scudder" <[email-masked]>
Date: Tue, 30 Sep 2003 11:19:23 -0400

Folks,

There is a minor bug in the MED-handling procedures (9.1.2.2) of the BGP spec:

       c) Remove from consideration routes with less-preferred
       MULTI_EXIT_DISC attributes. MULTI_EXIT_DISC is only comparable
       between routes learned from the same neighboring AS (the neighbor-
       ing AS is determined from the AS_PATH attribute). Routes which do
       not have the MULTI_EXIT_DISC attribute are considered to have the
       lowest possible MULTI_EXIT_DISC value.

       This is also described in the following procedure:

             for m = all routes still under consideration
                 for n = all routes still under consideration
                     if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m))
                         remove route m from consideration

       In the pseudo-code above, MED(n) is a function which returns the
       value of route n's MULTI_EXIT_DISC attribute. If route n has no
       MULTI_EXIT_DISC attribute, the function returns the lowest possi-
       ble MULTI_EXIT_DISC value, i.e. 0.

       Similarly, neighborAS(n) is a function which returns the neighbor
       AS from which the route was received.  If the route is learned via
       IBGP, and the other IBGP speaker didn't originate the route, it is
       the neighbor AS from which the other IBGP speaker learned the
       route. If the route is learned via IBGP, and the other IBGP
       speaker originated the route, it is the local AS.

This text assumes that it is always possible to unambiguously 
determine a unique neighbor AS for any route.  However, in principle 
this is not the case, as when a border router performs aggregation 
towards IBGP, leading to a route whose AS path begins with an AS_SET.

To correct this I propose that the following paragraph be added 
immediately following the text quoted above.

       In some cases it may not be possible to determine an unambiguous,
       unique neighbor AS, such as when the AS_PATH attribute begins with
       an AS_SET due to aggregation.  If the neighbor AS of a route cannot
       be determined, the MULTI_EXIT_DISC MUST NOT be compared with the
       MULTI_EXIT_DISC of any other route.  For the purposes of the pseudo-
       code above, this can be accomplished by considering neighborAS(n)
       to return a special distinguished "not found" value (which is not
       equal to any AS value) and MED(n) to return 0 for such routes.

I suppose it might also be worth saying (somewhere else, e.g. under 
the discussion of aggregation) that if you create an aggregated route 
which has an AS_SET as the first element in its AS_PATH, then you 
SHOULD strip the MED out.  This is just belt and suspenders though, 
and I don't much care if we do it or not.

In reality I doubt this case is ever seen in the wild, but it's good 
to have the spec right anyway.

Regards,

--John

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 30 Sep 2003 11:32:47 -0400

On Tue, Sep 30, 2003 at 11:19:23AM -0400, John G. Scudder wrote:
> SHOULD strip the MED out.

Well, this is only important if you're allowing routes to be aggregated
regardless of MED value. :-)

Good catch though.

This makes me wonder if our elders had already though of this particular
case and that was what the odd restriction of not aggregating things with
different MEDs was really for.  If you don't aggregate things with
different MEDs, you can simply check the leading set for the
presence of the AS.

-- 
Jeff Haas 
NextHop Technologies

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 30 Sep 2003 11:32:47 -0400

Good catch though.

-- 
Jeff Haas 
NextHop Technologies

---

From: Enke Chen <[email-masked]>
Date: Tue, 30 Sep 2003 09:01:55 -0700

John,

> Message-Id: <p06001a6fbb72786393ed@[64.101.214.208]>
> To: [email-masked]
> From: "John G. Scudder" <[email-masked]>
> Content-Type: text/plain; charset="us-ascii" ; format="flowed"
> Subject: [Idr] Proposed change to 9.1.2.2
> Sender: [email-masked]
> 
> Folks,
> 

I believe that an aggregated route is treated the same as an originated
route in this regard by several implementations I am familiar with. Such
treatment does make sense - a route is originated when you aggregate.

If further clarification is desired in the spec, we could revise it
like the following:

         If the route is learned via IBGP, and the other IBGP
         speaker originated the route or created the aggregate,
                                      ++++++++++++++++++++++++
         it is the local AS.

Regards, 

-- Enke

---

From: Enke Chen <[email-masked]>
Date: Tue, 30 Sep 2003 09:01:55 -0700

John,

Regards, 

-- Enke

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 30 Sep 2003 11:15:47 -0700

John,

>        equal to any AS value) and MED(n) to return 0 for such routes.

Do you have any objections if instead of the text proposed above
we'll follow Enke's suggestion ? Namely, replace

with

(especially since Enke's text reflects several implementations)

> and I don't much care if we do it or not.

In the absence of any objections I'll add this to the spec.

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 30 Sep 2003 11:15:47 -0700

John,

with

Yakov.

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 30 Sep 2003 14:21:49 -0400

>(especially since Enke's text reflects several implementations)

As does mine for that matter, but I am fine with Enke's text.  For 
one thing, it accomplishes the job using fewer words, always a good 
thing.

>In the absence of any objections I'll add this to the spec.

OK.

--John

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 30 Sep 2003 14:21:49 -0400

OK.

--John