Subject: [Idr] draft-rosen-idr-aigp-00

From: Robert Raszuk <[email-masked]>
Date: Tue, 24 Mar 2009 09:14:30 -0700

All,

I would like to support the suggestion made yesterday by Enke Chen, 
Keyur Patel and Danny which suggested to make a good analysis for using 
MED + Cost Community which are an already existing tools to achieve the 
same functionality as the draft proposed via a definition of a new AIGP 
attribute.

In fact the problem described in the draft is a very good example where 
practical problem can be solved using the above two solutions combined 
together.

It can be a very good motivation for restarting work on cost community 
itself which were last posted draft-retana-bgp-custom-decision-00. There 
are apparently practical cases which this draft has a potential to solve 
and IMHO there is a saving to implement something once and then reuse 
for various applications as opposed to implementing separate attributes 
which would at the end result in more burden to BGP and deployment 
difficulties.

Cheers,
R.

---

From: "Pradosh Mohapatra (pmohapat)" <[email-masked]>
Date: Tue, 24 Mar 2009 10:49:51 -0700

Hi Robert,

Thanks for the comments. Inline:

| I would like to support the suggestion made yesterday by Enke 
| Chen, Keyur Patel and Danny which suggested to make a good 
| analysis for using MED + Cost Community which are an already 
| existing tools to achieve the same functionality as the draft 
| proposed via a definition of a new AIGP attribute.

Here are the replies I made during the WG discussion for these
questions:

1) MED alone is not a good tool since the MED comparison step
   is after AS_PATH length comparison.
2) Cost community is an extended community which is optional
   transitive. We want to make the attribute non-
   transitive to restrict its scope of propagation.

- Pradosh

| 
| In fact the problem described in the draft is a very good 
| example where practical problem can be solved using the above 
| two solutions combined together.
| 
| It can be a very good motivation for restarting work on cost 
| community itself which were last posted 
| draft-retana-bgp-custom-decision-00. There are apparently 
| practical cases which this draft has a potential to solve and 
| IMHO there is a saving to implement something once and then 
| reuse for various applications as opposed to implementing 
| separate attributes which would at the end result in more 
| burden to BGP and deployment difficulties.
| 
| Cheers,
| R.
| 
| _______________________________________________
| Idr mailing list
| [email-masked]
| https://www.ietf.org/mailman/listinfo/idr
|

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 24 Mar 2009 10:55:29 -0700

Hi Pradosh,

 >    is after AS_PATH length comparison.

Correct. That is why I proposed to use it along with cost communities.

 >    transitive to restrict its scope of propagation.

Transitiveness should be discussed in the scope. Ext community attribute 
is transitive within the domain. Inter-domain high-order type field 
decides if this should be transitive or not at the AS boundary.

Cost community is not transitive.

Exactly as required :).

The BGP Cost Community

    The BGP Cost Community is an Opaque Extended Community [EXT_COMM]
    defined as follows:

       Type Field:

          The value of the high-order octet of the extended Type Field is
          0x43, which indicates it is non-transitive. The value of the
          low-order octet of the extended type field for this community
          is TBD.

Cheers,
R.

---

From: "Pradosh Mohapatra (pmohapat)" <[email-masked]>
Date: Tue, 24 Mar 2009 11:05:22 -0700

|  > 1) MED alone is not a good tool since the MED comparison step
|  >    is after AS_PATH length comparison.
| 
| Correct. That is why I proposed to use it along with cost communities.
| 
|  > 2) Cost community is an extended community which is optional
|  >    transitive. We want to make the attribute non-
|  >    transitive to restrict its scope of propagation.
| 
| Transitiveness should be discussed in the scope. Ext 
| community attribute is transitive within the domain. 
| Inter-domain high-order type field decides if this should be 
| transitive or not at the AS boundary.
| 
| Cost community is not transitive.
| 
| Exactly as required :).
| 
| The BGP Cost Community
| 
|     The BGP Cost Community is an Opaque Extended Community [EXT_COMM]
|     defined as follows:
| 
|        Type Field:
| 
|           The value of the high-order octet of the extended 
| Type Field is
|           0x43, which indicates it is non-transitive. The value of the
|           low-order octet of the extended type field for this 
| community
|           is TBD.

Understood. The extended community is an optional transitive attribute.
What if a router doesn't understand extended community at all? It would
pass along the cost community, wouldn't it?

- Pradosh

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 24 Mar 2009 11:13:29 -0700

Hi Pradosh,

 > Understood. The extended community is an optional transitive
 > attribute. What if a router doesn't understand extended community at
 > all? It would pass along the cost community, wouldn't it?

Let's be practical ....

Is there any router on the market, used in the production at the AS 
boundary as an ASBR which does not understand ext communities ?

In any case to assure that using cost community would be safe the 
function under discussion will not be used by default. So in any transit 
AS it would just propagate.

If you have to upgrade your ASBR to understand AIGP new attribute you 
may as well upgrade it to the image which also understands ext 
communities :). Then you are 100% safe.

Cheers,
R.

---

From: "UTTARO, JAMES, ATTLABS" <[email-masked]>
Date: Sat, 28 Mar 2009 12:54:28 -0400

I do not agree. MED is a tool that is used to signal preference between
two AS domains... The idea of overloading for this purpose would require
knobs and hacks like "always-compare MED" and accumulating MED etc....
Cost Community would also have to be modified. It is better to create an
attribute whose functionality is clear. Use MED and Cost Community for
the problems the were designed to solve.

Jim Uttaro

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Robert Raszuk
Sent: Tuesday, March 24, 2009 12:15 PM
To: idr
Subject: [Idr] draft-rosen-idr-aigp-00

All,

Cheers,
R.

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

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 28 Mar 2009 17:47:33 -0700

Hi Jim,

I think there are few things which would be great to keep in mind no 
matter how this proposal will move forward.

* I think that making new attribute is clean indeed, but a bit risky to 
touch your best path selection algorithm each time new attribute is 
invented to influence best path decision.

* As defined today AIGP attribute carries an unreferenced sigma of 
metrics. In my opinion it should be referenced by the start point of the 
accumulation which most obviously would be the originator next hop. Best 
path should compare only those AIGP attributes with original next hop 
attached to be equal. Otherwise in deployments in other customer 
networks when AIGP support is partial in the mesh of ASes it is quite 
obvious that it may lead to permanent loops. Any encapsulation (even 
mpls) on a per AS basis will not be a cure at all.

* And to the point you made ... cost community where designed to be 
common tool to modify the best path selection on as needed basis. Do you 
have a different opinion on cost community applicability ? Their design 
is exactly as you require in your case. Yes it would need to accumulate 
MEDs metrics on the AS boundaries, but this is the same as adding new 
values to the new to be deployed AIGP attribute.

Best regards,
R.

---

From: Danny McPherson <[email-masked]>
Date: Sun, 29 Mar 2009 19:34:19 -0600

On Mar 28, 2009, at 10:54 AM, UTTARO, JAMES, ATTLABS wrote:

> two AS domains...

It's a really bad idea to compare MEDs between two
different "AS domains", for many reasons.  Perhaps
most important, is that if IGP metrics aren't normalized
(which they'll never be unless you own all the domains)
between them then you'll end up always picking one
peer for all path selections.

This was especially obvious when IS-IS had only 10 bits
of path metric space, while OSPF had ++32 - and MEDs were
adapted from cumulative IGP link metrics - the big guys
that ran IS-IS picked up all the traffic by default.

Ohh, and MEDs are broken for MANY other reasons, e.g.:

www.tcb.net/Apricot-2004/Apricot-2004-MEDS.ppt

-danny

---

From: Enke Chen <[email-masked]>
Date: Sun, 29 Mar 2009 21:47:48 -0700

Hi, folks:

I do not think that the suggestion is for comparing MEDs from different 
ASes in general.  Here we are talking about the case where several ASes 
act like one entity.  There should be config knobs to make the MEDs 
accumulative, and also comparable within the entity.

-- Enke

---

From: Danny McPherson <[email-masked]>
Date: Sun, 29 Mar 2009 23:48:50 -0600

On Mar 29, 2009, at 10:47 PM, Enke Chen wrote:

> Hi, folks:
>
> I do not think that the suggestion is for comparing MEDs from  
> different ASes in general.  Here we are talking about the case where  
> several ASes act like one entity.  There should be config knobs to  
> make the MEDs accumulative, and also comparable within the entity.

Yes, I agree with you recommendation Enke.

-danny

---

From: Jeff S Wheeler <[email-masked]>
Date: Mon, 30 Mar 2009 03:10:20 -0400

> invented to influence best path decision.
How do you propose to make the algorithm aware of future attributes that
have not been invented yet?  If I want to do bestpath decision based on
who has the coolest ASCII-art in their advertisement, just assuming that
I have an army of stick-man art critics in my basement, how can you
write spec or software to anticipate that need until I thought of it?

> values to the new to be deployed AIGP attribute.
This is kinda being done on an inter-domain basis by some at least one
major tier-2 today (you know who you are, and may have already taken
credit for it on the list without my notice.)  Some vendors support
bestpath comparisons based on med+igp with arithmetic knobs now.  And as
we all know, there is the always-compare-med feature.

> accumulative, and also comparable within the entity.
There are on some platforms, see above.  I think IOS-XR is one platform
where this is possible, in fact.  JUNOS can do it.

 _____________________________________________________
/ Jeff S Wheeler <[email-masked]> +1-212-981-0607 \
\ Sr Network Operator  /  Innovative Network Concepts /
 ----------------------------------------------------- 
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 30 Mar 2009 00:14:07 -0700

Hi Jeff,

> write spec or software to anticipate that need until I thought of it?

http://tools.ietf.org/html/draft-retana-bgp-custom-decision-00

    This document defines a new Extended Community [EXT_COMM], called the
    Cost Community, which may be used in tie breaking during the best
    path selection process.  The end result is a local custom decision
    process.

...

    The network administrator may use the Cost Community to assign a
    value to a path originated or learned by a peer in any part of the
    local domain. The Point of Insertion may also be specified using the
    values defined in the IANA registry [BGP_PAR] or this document.

    If a BGP speaker receives a path that contains the Cost Community, it
    MUST consider its value at the Point of Insertion specified, when
    calculating the best path [RFC1771].

R.

---

From: Eric Rosen <[email-masked]>
Date: Mon, 30 Mar 2009 10:30:13 -0400

> cost community  where designed to be  common tool to modify  the best path
> selection on as needed basis 

The Cost Community  i-d expired about six years ago, so  I really don't know
why it's being brought up.  

However,  I will  say that  I think  the idea  of having  a "common  tool to
modify the  best path selection on  an as needed  basis" is not a  very good
idea.

> a bit  risky to  touch your  best path selection  algorithm each  time new
> attribute is invented

Yes, much less risky to allow arbitrary changes by allowing new values to be
inserted at any arbitrary place ;-) 

Maybe we should  generalize more and use the "advisory message"  to pass a C
program specifying a new decision process ;-)

> Yes it would need to accumulate MEDs metrics on the AS boundaries

Really,  the MED  has  enough  problems as  it  is, it  doesn't  need to  be
overloaded with yet more functions.

I do not think it simplifies  things to take a well-defined function and try
to achieve  it by using an ad  hoc combination of other  attributes that are
already known to be problematic.

> in deployments in other customer 
> obvious that it may lead to permanent loops

Please give an example of such a loop.

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 30 Mar 2009 07:56:09 -0700

Hi Eric,

> why it's being brought up.  

While the draft did in fact expired there is at least one major 
shipping implementations utilizing it today.

> program specifying a new decision process ;-)

LOL !

> overloaded with yet more functions.

I did not think MED needs to be modified. It would just need to pass 
it's carried metric into ext community. Such community would have 
exactly the same properties as AIGP attribute.

> already known to be problematic.

And I don't think we need to invent new tools if existing tools can do 
the same job. At min I would expect a paragraph in the spec explaining 
the choice of new clean AIGP attribute as opposed to use combination of 
existing tools.

> Please give an example of such a loop.

If you set AIGP attribute outside of specified rules (ie for example 
after reviving given prefix on EBGP session due to misconfig or bug) it 
is pretty trival to see the loop.

Rather then shipping the fragile attribute I was just suggesting to add 
4 more octets of either src rtr_id (the one which at the redistribution 
   appends AIGP attribute) or src AS number.

An additional rule in the best path run would be to only compare AIGP 
attributes for a given net with equal such 4 octet field. IMHO that 
could make the feature more robust.

Cheers,
R.

---

From: Eric Rosen <[email-masked]>
Date: Mon, 30 Mar 2009 12:13:17 -0400

> is pretty trival to see the loop.

Please provide an example.

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 30 Mar 2009 10:33:21 -0700

Hi Eric,

Apologies for my ASCII art :(

> Please provide an example.

For example:

ASBR3a --1--ASBR3b
   |   \ _1_/    |
   1   _/        |
   |  /  \       |
ASBR2    x      x
   |  \    \     |
  10   x_   \    |
   |     \_  \   |
ASBR1a ---- ASBR1b
         |
        A/z

Let's assume the above.

AS3 represented by ASBR3a & 3b are setting AIGP attribute to 1 on 
reception of advertisements from ASBR1b.

Since having the sttribute set is per specification by default better 
from not having the attribute at all ASBR3a/3b as well as is above local 
preference check in the best path between ASBR3a/3b/2 the loop will form.

If we would add the validation that only AIGP values originated from the 
same AS are comparable and if not they are not to be considered at all 
it would make the feature safer to deploy and use.

The proposed placement of AIGP best path influence check above local 
pref makes it pretty much an absolute criteria. Especially that even 
EBGP vs IBGP check which is much lower would be skipped.

Cheers,
R.

---

From: Eric Rosen <[email-masked]>
Date: Mon, 30 Mar 2009 14:16:45 -0400

> reception of advertisements from ASBR1b.

Section 3.3.1: 

   A BGP speaker MUST NOT add the AIGP attribute to any route whose path
   leads outside the AS to which the BGP speaker belongs.

Section 4.1:

   the AS_PATH continues to be used to prevent
   consideration of routes that traverse an AS more than once.

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 30 Mar 2009 11:23:16 -0700

Eric,

 > leads outside the AS to which the BGP speaker belongs.

You are quoting the spec .. I read it. I was talking about 
misconfiguration and bugs. In the other emial I said:

"If you set AIGP attribute outside of specified rules (ie for example 
after reviving given prefix on EBGP session due to misconfig or bug) it 
is pretty trival to see the loop."

I agree we should not get into every corner case paranoia, but making 
protocol robust for basic potential problems seems for me like not a big 
incremental effort.

 >    consideration of routes that traverse an AS more than once.

I don't understand this one. If AIGP is above local pref and local pref 
is step #2 in best path once we tie break at AIGP how do we continute to 
compare AS_PATH ?

Cheers,
R.

---

From: Eric Rosen <[email-masked]>
Date: Mon, 30 Mar 2009 14:52:13 -0400

> I was talking about misconfiguration and bugs

I'm not sure I see how a  misconfiguration by itself can cause a loop.  It's
always possible to imagine a bug that will cause a loop.

> If AIGP is above local pref and local pref is step #2 in best path once we
> tie break at AIGP how do we continue to compare AS_PATH ?

The intention is that (a) AIGP trumps AS_PATH length, but (b) if a route has
an AS_PATH  indicating a  loop, then  the route is  not considered.   (It is
possible that a least latency path will exit an AS and then re-enter it, but
the intention  is not to  use such  paths.)  Do you  think this needs  to be
clarified in the spec?

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 30 Mar 2009 12:02:25 -0700

Hi Eric,

> always possible to imagine a bug that will cause a loop.

If appending AIGP can be done by policy misconfig could hurt as well.

> the intention  is not to  use such  paths.)  Do you  think this needs  to be

But that has nothing to do with best path selection ... Looped paths are 
not even considered for best path comparison. From some vendor's public 
document:

"Paths from an external BGP (eBGP) neighbor if the local autonomous 
system (AS) appears in the AS_PATH:

Such paths are denied upon ingress into the router and are not even 
installed in the BGP Routing Information Base (RIB). The same applies to 
any path that is denied by a routing policy that is implemented via 
access, prefix, AS_PATH, or community lists, unless you have configured
soft−reconfiguration inbound for the neighbor."

So I think spec should remove the AS_PATH section from 4.1 to make it 
clear and to match the common implementations practices.

Cheers,
R.