Subject: FW: [Idr] draft-ietf-as-pathlimit-02

From: Tony Li <[email-masked]>
Date: Fri, 15 Dec 2006 14:33:54 -0800

Hi all,

Sorry about the long response time.

>>> I have a couple of questions regarding this draft.
>>>
>>> 1. Section 5.1 states that the route's AS_PATHLIMIT MUST NOT be
>>> modified.  Section 5.2 talks about attaching an AS_PATHLIMIT
>>> attribute but doesn't say anything about being permitted
>>>
> to remove
>
>>> it.  Am I permitted to 'change' a received AS_PATHLIMIT by
>>> deleting and re-adding?  Some email exchanges in the
>>>
> archive would
>
>>> seem to suggest the answer to this is yes.
>>>
>
> My personal view is that it ought to be possible to remove an
> AS_PATHLIMIT attribute as part of the normal application of local
> policy within an AS, and that the draft should be modified to make
> this more clear.
>
> [If you can do it with other, similar attributes (e.g. the
> NO_ADVERTISE and NO_EXPORT community string attributes) it makes no
> sense to me to prohibit this with AS_PATHLIMIT.]
>
> It follows that removing an AS_PATHLIMIT attribute which is already
> present and then adding a replacement AS_PATHLIMIT attribute
> ought to
> be possible.

I'm fine with this approach.  Unless there are objections, I'll add  
explicit text in -03 to this effect.  If anyone care to propose text,  
please email me.

>>> 2. With respect to the use of the ATOMIC_AGGREGATE.  Maybe I'm
>>> missing something here and I think that this has already been
>>> mentioned on the list before but it appears that the specified
>>> behaviour matches the old BGP RFC and not the latest RFC?  Are
>>> folks happy with the path-limit specification adopting the old
>>> style behaviour?  Actually I'd really appreciate it if someone
>>> could explain why this is required at all! :)
>>>
>
>     BGP requires that a BGP speaker that advertises a less specific
>     prefix, but not a more specific prefix that it is using, must
>     advertise the less specific prefix with the ATOMIC_AGGREGATE
>     attribute.  BGP speakers that do not advertise a more specific
> prefix
>     based on the AS_PATHLIMIT must comply with this rule and advertise
>     the less specific prefixes with the ATOMIC_AGGREGATE
> attribute.  To
>     help ensure compliance with this, sites that choose to
> advertise the
>     AS_PATHLIMIT path attribute should advertise the ATOMIC_AGGREGATE
>     attribute on all less specific covering prefixes.
>
> I think I'd be happy with removing this paragraph altogether,
> although it's before 9am and I have not yet reached my preferred
> caffeine levels so I reserve the right to disagree with myself at
> some later date. :-)

Well, my reading of 4271 is that ATOMIC_AGGREGATE is not yet  
deprecated, and that deaggregation is still permissible if  
ATOMIC_AGGREGATE is not set.  Am I confused?

Tony

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

---

From: Neil Matthew <[email-masked]>
Date: Mon, 18 Dec 2006 10:37:50 +0000

Hi

I'll see if I can think of some replacement text.

As far as the ATOMIC_AGGREGATE is concerned, regardless of the intent, 
the draft is incorrect since RFC 4271 does not state the requirement as 
currently worded.  If this is a requirement for this draft then I guess 
the wording should be along the lines of "Section 5.1.6 of [RFC 4271] is 
replaced with the following text".  Except the "following text" will 
basically be a cut and paste of RFC 1771.  I wasn't working on BGP back 
then but I guess the text was altered for a reason?

Also, is the intent that this is really a 'MUST'?  I ask because RFC 
1771 uses a lower case 'shall'.  Is the use of this attribute more of a 
safeguard than anything else and if so then could we use MAY?

Cheers

Neil

---

From: Tony Li <[email-masked]>
Date: Mon, 18 Dec 2006 09:14:47 -0800

Neil,

> I'll see if I can think of some replacement text.

Thanks.

> As far as the ATOMIC_AGGREGATE is concerned, regardless of the  
> intent, the draft is incorrect since RFC 4271 does not state the  
> requirement as currently worded.  If this is a requirement for this  
> draft then I guess the wording should be along the lines of  
> "Section 5.1.6 of [RFC 4271] is replaced with the following text".   
> Except the "following text" will basically be a cut and paste of  
> RFC 1771.  I wasn't working on BGP back then but I guess the text  
> was altered for a reason?

Maybe I'm missing something.  I'm not trying to change overall  
behavior with AS_PATHLIMIT.  Where do you see the inconsistency?  The  
point of that paragraph was to remind folks that are dropping paths  
due to AS_PATHLIMIT that they need to be careful.

> Also, is the intent that this is really a 'MUST'?  I ask because  
> RFC 1771 uses a lower case 'shall'.  Is the use of this attribute  
> more of a safeguard than anything else and if so then could we use  
> MAY?

At least as of 1771, using ATOMIC_AGGREGATE was intended to be a  
strict requirement.  I don't think that case has ever been the sole  
indication that something was strictly required or not.  Case was  
added just to highlight the requirements.  1777 certainly uses  
'shall' liberally and the intent was that it was semantically  
equivalent to 'must'.

AFAIK, ATOMIC_AGGREGATE is still a hard requirement.  If an aggregate  
with a truncated AS path is subsequently deaggregated, then it  
generates a longer prefix.  If one of those truncated prefixes is  
distributed back across the AS path of the aggregate, in the portion  
that was truncated, then it could easily be selected and you have a  
static forwarding loop.

The only difference is that 4271 has explicitly called out the  
requirement that the AS path be truncated before there's an issue.   
This is a good clarification.  I can certainly add that, if that  
would be help.

Tony

>> I'm fine with this approach.  Unless there are objections, I'll  
>> add  explicit text in -03 to this effect.  If anyone care to  
>> propose text,  please email me.
>>
>>

---

From: Tony Li <[email-masked]>
Date: Mon, 18 Dec 2006 11:12:31 -0800

Neil,

Thanks.

Maybe I'm missing something.  I'm not trying to change overall  
behavior with AS_PATHLIMIT.  Where do you see the inconsistency?  The  
point of my paragraph was to remind folks that are dropping paths due  
to AS_PATHLIMIT that they need to be careful.

The only difference is that 4271 has explicitly called out the  
requirement that the AS path be truncated

Tony

---

From: Neil Matthew <[email-masked]>
Date: Tue, 19 Dec 2006 09:17:06 +0000

Hi

OK, can we agree that the text in section 5.1.6 ATOMIC_AGGREGATE as it 
appears in RFC 4271 is different to the text found in the same section 
of RFC 1771?  Further can we agree that section 5.1 of the AS_PATHLIMIT 
draft refers to the earlier text?  From section 5.1 of the AS_PATHLIMIT 
draft:

   "BGP requires that a BGP speaker that advertises a less specific
   prefix, but not a more specific prefix that it is using, must
   advertise the less specific prefix with the ATOMIC_AGGREGATE
   attribute. "

This is not what appears in section 5.1.6 of the latest BGP draft but 
words to this effect do appear in RFC 1771.  This is a tad confusing.

In the latest BGP RFC the focus is on the node performing the 
aggregation - this is a controlled point with configured aggregation 
policy.  This is referred to in the AS_PATHLIMIT draft in the following 
text (the end of the last paragraph of section 5.1):

   To help ensure compliance with this, sites that choose to advertise the
   AS_PATHLIMIT path attribute should advertise the ATOMIC_AGGREGATE
   attribute on all less specific covering prefixes.

Cool.  What concerns me is the bit that comes before:

   BGP speakers that do not advertise a more specific prefix
   based on the AS_PATHLIMIT must comply with this rule and advertise
   the less specific prefixes with the ATOMIC_AGGREGATE attribute.

This seems to reference the earlier BGP RFC.  So the idea is that if the 
originating node 'forgot' to attach the ATOMIC AGGREGATE then it is a 
'must' requirement that some later node 'fix' up the situation?  I am 
concerned this is a non-trivial and processor intensive requirement 
hence my labouring of the point!  I'd just like clarification.

Cheers

Neil

Tony Li wrote:

>> draft then I guess the wording should be along the lines of  "Section 
>> 5.1.6 of [RFC 4271] is replaced with the following text".   Except 
>> the "following text" will basically be a cut and paste of  RFC 1771.  
>> I wasn't working on BGP back then but I guess the text  was altered 
>> for a reason?
>
>
>
>> 1771 uses a lower case 'shall'.  Is the use of this attribute  more 
>> of a safeguard than anything else and if so then could we use  MAY?
>
>
>

---

From: Tony Li <[email-masked]>
Date: Tue, 19 Dec 2006 08:58:00 -0800

Neil,

> OK, can we agree that the text in section 5.1.6 ATOMIC_AGGREGATE as  
> it appears in RFC 4271 is different to the text found in the same  
> section of RFC 1771?

Of course.

> Further can we agree that section 5.1 of the AS_PATHLIMIT draft  
> refers to the earlier text?

Well, it wasn't meant to.  It was meant to be consistent with both  
1771 and 4271, but wasn't meant to refer specifically to either.

> From section 5.1 of the AS_PATHLIMIT draft:
>
> This is not what appears in section 5.1.6 of the latest BGP draft  
> but words to this effect do appear in RFC 1771.  This is a tad  
> confusing.

Sorry.

> aggregation - this is a controlled point with configured  
> aggregation policy.  This is referred to in the AS_PATHLIMIT draft  
> in the following text (the end of the last paragraph of section 5.1):
>
> This seems to reference the earlier BGP RFC.  So the idea is that  
> if the originating node 'forgot' to attach the ATOMIC AGGREGATE  
> then it is a 'must' requirement that some later node 'fix' up the  
> situation?  I am concerned this is a non-trivial and processor  
> intensive requirement hence my labouring of the point!  I'd just  
> like clarification.

Got it, thanks for clarifying your concern.

 From my reading of 4271, I'm not sure that you can transfer all  
responsibility to the node that originated the aggregate.  Recall  
Postel's robustness principle: "Be conservative in what you do; be  
liberal in what you accept from others."

This implies that a node other than the originating node that saw  
both the aggregate and the more specific should, in being liberal,  
accept both regardless of ATOMIC_AGGREGATE.  Since that same node can  
(albeit painfully) detect that it has an aggregate without  
ATOMIC_AGGREGATE, it has a responsibility, in being conservative, to  
rectify the situation or at least not propagate the error.

That said, that's all about 4271 and is completely orthogonal to  
AS_PATHLIMIT.  As I said before (and I really meant), I'm not trying  
to change the semantics of 4271.  What I'd like to do then is to  
morph the AS_PATHLIMIT text to address your concern.  Let me propose  
a replacement to the entire paragraph:

	To ensure loop prevention, BGP requires that all aggregate routes  
with truncated
	AS paths be originated with the ATOMIC_AGGREGATE attribute.  To help  
ensure
	compliance with this, sites that choose to advertise the  
AS_PATHLIMIT path attribute
	should advertise the ATOMIC_AGGREGATE on all less specific covering  
prefixes.

Does that work for you?

Ob. overhead: I currently have a draft out to my co-editors.   
Assuming that you agree to this and my co-editors have no objections,  
this can get rolled into -03.

Tony

---

From: Neil Matthew <[email-masked]>
Date: Tue, 19 Dec 2006 17:54:18 +0000

Hi Tony

<snip>

>     AS paths be originated with the ATOMIC_AGGREGATE attribute.  To 
> help  ensure
>     should advertise the ATOMIC_AGGREGATE on all less specific 
> covering  prefixes.
>
> Does that work for you?

Yes.  Thanks.

Cheers

Neil

---

From: "tom.petch" <[email-masked]>
Date: Wed, 20 Dec 2006 12:07:48 +0100

Sorry to be late for this particular party but I think the text still misses the
point; see below.

Tom Petch

----- Original Message -----
From: "Tony Li" <[email-masked]>
To: "Neil Matthew" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, December 19, 2006 5:58 PM
Subject: Re: [Idr] draft-ietf-as-pathlimit-02

> To ensure loop prevention, BGP requires that all aggregate routes  with
truncated
> AS paths be originated with the ATOMIC_AGGREGATE attribute.  To help  ensure
> compliance with this, sites that choose to advertise the  AS_PATHLIMIT path
attribute
> should advertise the ATOMIC_AGGREGATE on all less specific covering

No!  RFC4271 does NOT talk about truncated AS paths, it says
"  If an aggregate excludes at least some of the AS numbers present in
   the AS_PATH of the routes that are aggregated as a result of dropping
   the AS_SET ..."

that is, it is not specific to truncation, it is whenever as AS number is
omitted and the thrust of RFC4271 is that may occur due to an AS_SET being
omitted.

Your text is about truncation only and that I think is wrong.

So I think you need text along the lines of

To ensure loop prevention, BGP recommends {SHOULD not MUST} that when an
aggregated route does not include all the AS numbers that were present in the
more specific routes, then the ATOMIC_AGGREGATE attribute SHOULD be present.

Tom Petch

---

From: Tony Li <[email-masked]>
Date: Wed, 20 Dec 2006 13:17:45 -0800

Tom,

> Sorry to be late for this particular party but I think the text  

Welcome to the party.  Better late than never.  Don't worry, the  
food's not gone...  ;-)

>> with

So, dropping an AS_SET is one mechanism for truncating the AS_PATH,  
yes?  It's certainly the most likely one to happen at aggregation  
time, but you can imagine that there might be a host of other  
(possibly future) mechanisms that truncate the AS path.

> Your text is about truncation only and that I think is wrong.

I'm trying to think more generally than what 4271 says.  The problem  
that ATOMIC_AGGREGATE 'fixes' is a combination of truncation of the  
AS_PATH in conjunction with deaggregation.

> more specific routes, then the ATOMIC_AGGREGATE attribute SHOULD be  

By the rules on aggregation, shouldn't the only way that AS number  
might not be present in the aggregate's AS path be due to dropping  
the AS_SET?  In other words, isn't your text semantically identical  
to what I proposed?

Tony

---

From: "tom.petch" <[email-masked]>
Date: Fri, 22 Dec 2006 12:52:00 +0100

No:-( see inline

Tom Petch

----- Original Message -----
From: "Tony Li" <[email-masked]>
To: "tom.petch" <[email-masked]>
Cc: "Neil Matthew" <[email-masked]>; <[email-masked]>
Sent: Wednesday, December 20, 2006 10:17 PM
Subject: Re: [Idr] draft-ietf-as-pathlimit-02

> the AS_SET?  In other words, isn't your text semantically identical

I think not.  Truncation in my vocabulary is about lopping off the end so
1, 3, (345, 324, 319), 2, 29, 416
might be truncated to
1, 3, (345, 324, 319), 2
but changing it to
1, 3, 345, 2, 29, 416
does not come within the semantics of truncation.

So I agree that we should allow for more cases than RFC4271 does but see
truncation as the wrong word.  Omit, remove, excise, drop, exclude ... lots of
alternatives but not truncation.

---

From: Tony Li <[email-masked]>
Date: Fri, 22 Dec 2006 08:14:21 -0800

Tom,

> I think not.  Truncation in my vocabulary is about lopping off the  

Ok, I don't want to quibble here.  Revised text:

	To ensure loop prevention, BGP requires that all aggregate routes
	with AS paths that omit any AS number from the AS_PATHs being
         aggregated be originated with the ATOMIC_AGGREGATE
	attribute.  To help ensure compliance with this, sites that choose
	to advertise the AS_PATHLIMIT path attribute SHOULD advertise the
	ATOMIC_AGGREGATE on all less specific covering prefixes.

Does that work for you?

Tony

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 22 Dec 2006 11:12:33 -0500

> Tom Petch

Let me just check on my understanding of ATOMIC_AGGREGATE, legal AS
Path changes, and de-aggregation.  See below.

> I think not.  Truncation in my vocabulary is about lopping off the end so

Please excuse me for also joining late and maybe not paying enough
attention to this thread up to now.

My read of RFC4271 concludes:

  1.  De-aggregation MUST NOT be done under any circumstance.

     In 9.1.4:

       With the elimination of IP routing protocols that do not
       support classless routing, and the elimination of router and
       host implementations that do not support classless routing,
       there is no longer a need to de-aggregate.  Routes SHOULD NOT
       be de-aggregated.  In particular, a route that carries the
       ATOMIC_AGGREGATE attribute MUST NOT be de-aggregated.

     Since there hasn't been a classfull host or router sighted in
     nearly 10 years (I had a Cisco IGS in my basement but that got
     recybcled :), this is effectively a MUST NOT.

  2.  The only time it is legal to truncate an AS path is when forming
      an ATOMIC_AGGREGATE.  RFC4271 is not clear about what changes to
      the AS_PATH is legal at this point, just that things can be
      omitted.

  3.  The common procedure for truncating the AS path when forming an
      ATOMIC_AGGREGATE is to drop the whole thing and advertise it out
      with only the AS of the aggregator in the AS Path.

  4.  The only other legal changes to the AS_PATH (besides prepending
      your own AS) are information reduction, forming AS_SET as
      described in 9.2.2.1 and aggregation as described in 9.2.2.2.

Also important but not in RFC4271 (me thinks):

  5.  In practice, forming an ATOMIC_AGGREGATE from a set of routes
      which include one or more that is as specific as the aggregate
      has proven to be potentially harmful.  Maybe this should have
      been noted in RFC4271 but it is not (unless I missed it).

Since the common practice is "drop the whole AS_PATH", leaving some
information on the AS_PATH when forming an ATOMIC_AGGREGATE should be
fine.  I think you'll have the same potential looping problems with or
without AS_PATHLIMIT if you ignore item #5 above.

Now back to the subject line (which is wrong, the draft name is
draft-ietf-idr-as-pathlimit-02.txt, note that the idr is missing).

The draft specifies limiting the scope of the more specific routes.
(Seems like a good idea.  Why all the fuss? :)

In this draft, Section "5.1.  Operations" warns to add
ATOMIC_AGGREGATE when forming an aggregate containing AS_PATHLIMIT.

If an aggregate is formed, limiting the more specific has no adverse
effect in terms of reachability as long as the more specific can reach
the aggregator.

If no aggregate is formed, which might be the case for anycast, then
the scope of the anycast address is limited, which besides information
reduction is the purpse of doing as-pathlimit for anycast.

If an aggregator drops the AS_PATH or any part of it, adds
ATOMIC_AGGREGATE, but does not form a less specific prefix, then a
loop is possible, but that was always the case with or without
AS_PATHLIMIT.

Whether to do creative AS_PATH manipulations and which ones are legal
and/or safe is not directly relevant to the draft (unless as is
sometimes the case and could be again, I'm missing something due to
skimming a long thread without reading every word).  It seems to me
that creative uses of AS_PATHLIMIT and ATOMIC_AGGREGATE and AS_PATH
changes beyond what is described in the draft is interesting but
should be out of scope and better saved for a new "creative uses"
draft to follow if we want to pursue it further.

So should we move forward with this draft, or did I miss something?

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 22 Dec 2006 12:40:15 -0500

> 	ATOMIC_AGGREGATE on all less specific covering prefixes.

   To help ensure compliance with this, sites that choose to advertise
   the AS_PATHLIMIT path attribute SHOULD advertise the
   ATOMIC_AGGREGATE on all less specific covering prefixes.

Add to that "without changing the AS_PATH when adding
ATOMIC_AGGREGATE.  Just truncating and advertising the same prefix
adding ATOMIC_AGGREGATE is already known to cause loops.

Curtis

---

From: "tom.petch" <[email-masked]>
Date: Sat, 23 Dec 2006 12:14:11 +0100

----- Original Message ----- 
From: "Tony Li" <[email-masked]>
To: "tom.petch" <[email-masked]>
Cc: "Neil Matthew" <[email-masked]>; <[email-masked]>
Sent: Friday, December 22, 2006 5:14 PM
Subject: Re: [Idr] draft-ietf-as-pathlimit-02

> ATOMIC_AGGREGATE on all less specific covering prefixes.
Yes, that works for me (but I am still digesting Curtis's message)

Tom Petch

---

From: Curtis Villamizar <[email-masked]>
Date: Sat, 23 Dec 2006 10:53:19 -0500

> Yes, that works for me (but I am still digesting Curtis's message)

Tony, Tom,

I think we are all in agreement here with the addition of the caveat
that you can't safely stuff a ATOMIC_AGGREGATE on a prefix and drop
part of the AS_PATH.  If routes with AS_PATHLIMIT are originated with
both AS_PATHLIMIT and ATOMIC_AGGREGATE then any aggregate formed has
to have ATOMIC_AGGREGATE.  

If routes with AS_PATHLIMIT are originated with ATOMIC_AGGREGATE then
no AS is lost from the path unless someone uses this prefix to form
another ATOMIC_AGGREGATE aggregate with the same prefix length and
drops all or part of the AS_PATH in doing so.  That we could agree is
a problem but out of scope for this document since it relates to the
general harmfulness of this sort of "aggregation".

Curtis

ps - If you keep adding capabilities such as this to BGP you'll
someday catch up to the functionality defined for the IRR in the RPS
WG about 10 years ago, and largely implemented (the aggregation limits
were defined but not implemented though, but they were more functional
indicating which set of AS a prefix should be limited to, not just
distance).  The difference was that it is here a local matter and
carried by protocol bits (bloating the advertisements) and there (IRR)
it was for the world to see in the registry (allowing others to
identify problems) and enforced by machine generated configuration.
To each his own preference.  Keep up the good work.  :-)

---

From: Tony Li <[email-masked]>
Date: Sat, 23 Dec 2006 09:51:50 -0800

Curtis,

>>> ATOMIC_AGGREGATE on all less specific covering prefixes.

So are you on-board with this text or not?

> To each his own preference.  Keep up the good work.  :-)

As I believe the text of the draft says itself, I was very hopeful  
that this functionality would not be necessary as a general sense of  
cleanliness.  I was wrong.  Having the functionality implement in the  
IRR clearly hasn't sufficed either.  As a practical matter, I'm  
simply trying to find something that works.

Regards,
Tony

---

From: Curtis Villamizar <[email-masked]>
Date: Sat, 23 Dec 2006 14:25:45 -0500

> So are you on-board with this text or not?

Not quite strong enough.  IMHO.

You should put ATOMIC_AGGREGATE on any prefix that has AS_PATHLIMIT so
that any downstream aggregator is forced to form an aggregate with
ATOMIC_AGGREGATE by virtue of the rule in BGP that if a component of
the aggregate has ATOMIC_AGGREGATE then any less specific aggregate
formed using it must have ATOMIC_AGGREGATE.

I suppose the reason for using SHOULD is that eventually aggregators
that don't understand AS_PATHLIMIT should go away and with it the need
for these extra ATOMIC_AGGREGATE.

We're being a bit pedantic about this whole topic if we look at this
from a practical standpoint since a long time ago we concluded that
providers were all using ATOMIC_AGGREGATE and tossing the entire
AS_PATH when forming an aggregate.  Since ATOMIC_AGGREGATE is
informational in the absense of de-aggregation this is not terribly
important.

The only thing that people were doing that was potentially dangerous
was combining a /x and /y where x<y and forming a new /x and tossing
the AS_PATH and adding ATOMIC_AGGREGATE.  That was safe in some
topologies but generally a vary bad practice.

Do you agree with that?

Curtis

---

From: Tony Li <[email-masked]>
Date: Sat, 23 Dec 2006 12:15:10 -0800

> formed using it must have ATOMIC_AGGREGATE.

Ok, next try:

	To ensure loop prevention, BGP requires that all aggregate routes
	with AS paths that omit any AS number from the AS_PATHs being
         aggregated be originated with the ATOMIC_AGGREGATE
         attribute.  To help ensure compliance with this, sites that  
choose
         to advertise the AS_PATHLIMIT path attribute SHOULD  
advertise the
         ATOMIC_AGGREGATE on all less specific covering prefixes as  
well as
         the more specific prefixes.

> informational in the absense of de-aggregation this is not terribly

Agreed.

> topologies but generally a vary bad practice.

Yes.  I'm much rather see people generate the AS_SET properly, and  
not drop AS's.  To me, loop avoidance is paramount.

Tony

---

From: Curtis Villamizar <[email-masked]>
Date: Sat, 23 Dec 2006 17:54:17 -0500

In message <[email-masked]>
Tony Li writes:
>    aggregated be originated with the ATOMIC_AGGREGATE attribute.  To
>    help ensure compliance with this, sites that choose to advertise
>    ATOMIC_AGGREGATE on all less specific covering prefixes as well as

Fine.  If this it the only thing that needs fixing the draft is in
great shape.  Seems simple enough.

Curtis

---

From: "tom.petch" <[email-masked]>
Date: Wed, 27 Dec 2006 18:15:18 +0100

I am ok with the original issue but a related one I have yet to get my mind
around.

RFC4271 9.1.4 says

" If a BGP speaker receives overlapping routes, the Decision Process
   MUST consider both routes based on the configured acceptance policy.
   If both a less and a more specific route are accepted, then the
   Decision Process MUST install, in Loc-RIB, either both the less and
   the more specific routes or aggregate the two routes and install, in
   Loc-RIB, the aggregated route, provided that both routes have the
   same value of the NEXT_HOP attribute."

cf this I-D

"If the number of ASes in the AS_PATH exceeds the value of
   the AS_PATHLIMIT attribute, then the route MUST be ignored without
   further processing."

so what happens if the more specific NEXT_HOP is different?  Presumably this I-D
wins but what is the risk that 9.1.4 seeks to forestall?

In theory, by the time AS_PATHLIMIT bites, the NEXT_HOP should be the same but I
do not think we should be relying on that.

Tom Petch

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 27 Dec 2006 17:13:31 -0500

In message <006701c729dd$56493ce0$0601a8c0@pc6>
"tom.petch" writes:
> so what happens if the more specific NEXT_HOP is different?
> Presumably this I-D wins but what is the risk that 9.1.4 seeks to
> forestall?

Same thing that happens if policy does not accept the route.

> In theory, by the time AS_PATHLIMIT bites, the NEXT_HOP should be the
> same but I do not think we should be relying on that.

Not necessarily true.  The more specific could produce a more optimal
next hop and the less specific gets you there.  If the less specific
doesn't get you there, then AS_PATHLIMIT has to be increased.

> Tom Petch

An example might be a route to the far east or australia where an
aggregate and some more specifics are multihomed.  There might be a
slight advantage to a provider from Europe taking one US provider or
another but both should get there.

Curtis