Subject: Re: [Idr] Last Call: 'Autonomous System Confederations for BGP' to Draft Standard (draft-ietf-idr-rfc3065bis)

From: "Glen Kent" <[email-masked]>
Date: Fri, 11 Aug 2006 23:13:24 +0530

John,

> Thanks for pointing this out.  Since (as far as I know) nobody has an
> implementation which actually generates AS_CONFED_SETs nor does such

I am sure there are atleast two implementations that generate
CONFED_SETs, so the above statement is not really true.

> seem likely, we're thinking that we should clarify the document by
> deprecating AS_CONFED_SET.
>
> Comments from the group?  Anyone aware of any reason not to do this?

You cant deprecate this. How do you otherwise catch loops when you
aggregate the routes within a confederation?

Whats needed is some new text in the draft that describes how this
path segment should be created.

Glen.
>
> --John
>
> At 1:33 PM +0200 8/10/06, Ilya Varlashkin wrote:
> >Hello,
> ...
> >I've just went through the document and have one question. The draft
> >specifies new segment types AS_CONFED_SEQUENCE and AS_CONFED_SET, and
> >specifies how to handle AS_PATH containing such segment in received
> >UPDATEs. There is also good amount of information on how AS_SEQUENCE can
> >be introduced into AS_PATH, however it doesn't seem to be clear from the
> >document how and when AS_CONFED_SET can and should be added to AS_PATH.
> >Is it described somewhere else or is this provision for further
> >development of the protocol standard? In first case it would be nice to
> >provide reference to a document where such description could be found,
> >and in later case it might be good idea to explicitly state that
> >"introduction and update of segments of type AS_CONFED_SET is not yet
> >defined".
> >
> >Kind regards,
> >iLya
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/idr
>

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

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 11 Aug 2006 14:07:23 -0400

> path segment should be created.

It's been a while since I've done a semantic review of the update.
In a previous pass of it, we removed a lot of the modification rules.
For appending the confederation set/sequence, the behavior is
expected to be identical to that of the base BGP RFC, but with
a different type.  

One solution is to update 3065bis to be "correct" with respect
to sequences and sets.  Now that the base BGP specification is
stable, we can probably do that.  This is a "messy" operation
because of the sheer number of places sets are used  and would
need to be copy/updated into the confederation spec.

Another solution is to simply note existing base BGP behavior
and point to the places where you add AS_CONFED_[SEQUENCE|SET] 
in place of their AS_[SEQUENCE|SET] components.

I'm fine with either option.

-- Jeff

---

From: "Glen Kent" <[email-masked]>
Date: Fri, 11 Aug 2006 23:43:15 +0530

Would the following text work?

When a BGP confederation speaker aggregates several routes for the
purpose of advertisement to a particular confederation peer, the
AS_PATH of the aggregated route normally includes an AS_CONFED_SET
formed from the set of ASes from which the aggregate was formed.

Glen

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 11 Aug 2006 12:16:03 -0600

Glenn:

Suggest where you'd like it to be put in the text for context.

sue

-----Original Message-----
From: Glen Kent [mailto:[email-masked]] 
Sent: Friday, August 11, 2006 2:13 PM
To: Jeffrey Haas
Cc: John G. Scudder; [email-masked]; [email-masked]
Subject: Re: [Idr] Last Call: 'Autonomous System Confederations for BGP'
toDraft Standard (draft-ietf-idr-rfc3065bis)

Glen

---

From: "Glen Kent" <[email-masked]>
Date: Fri, 11 Aug 2006 23:55:23 +0530

Sue,

Sec 4.1 under the text for "When a BGP speaker originates a route:"

Aggregating the route is like originating a route and i think its a
proper place to put the suggested text. I have slightly modified the
text as:

d) the originating speaker that aggregates several routes for the
purpose of advertisement to a particular confederation peer SHALL
include an AS_CONFED_SET segment of the AS_PATH attribute formed from
the set of ASes from which the aggregate was formed.

Glen

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 11 Aug 2006 14:28:13 -0400

>aggregate the routes within a confederation?

By the way, this is a common fallacy.  As long as you aggregate 
(i.e., form a shorter prefix) whenever you trim the AS path, and as 
long as no de-aggregation occurs, any loop will eventually be broken. 
That's what ATOMIC_AGGREGATE is all about.

--John

---

From: "Glen Kent" <[email-masked]>
Date: Sat, 12 Aug 2006 00:05:08 +0530

John,

When you trim the AS path you lose the AS_SET and thats where you use
the ATOMIC_AGGREGATE. If thats the case then we need to deprecate
AS_SET too. Are you suggesting that the SETs have no utility at all?

---

From: "Glen Kent" <[email-masked]>
Date: Sat, 12 Aug 2006 00:01:53 +0530

llya,

> Wouldn't this leave backdoor for misinterpretation that foreign (to
> given AS) prefixes can also be aggregated this way? This is obviously

Then the text needs to be modified to say that only the routes learnt
from confederation peers should be aggregated. But is this correct? Is
this even a requirement?

Glen.

> dangerous since when such aggregate propagated outside of the AS and
> AS_CONFED_SET removed (as per this draft), then information is lost.
>
> /iLya
>

---

From: "Ilya Varlashkin" <[email-masked]>
Date: Fri, 11 Aug 2006 20:46:48 +0200

> Sent: Friday, August 11, 2006 8:32 PM
> To: Ilya Varlashkin
> Cc: John G. Scudder; [email-masked]; [email-masked]; Jeffrey Haas
> Subject: Re: [Idr] Last Call: 'Autonomous System 
> Confederations for BGP' toDraft Standard (draft-ietf-idr-rfc3065bis)
> 
> llya,
> 
> Then the text needs to be modified to say that only the 
> routes learnt from confederation peers should be aggregated. 
> But is this correct? Is this even a requirement?
> 

The first way (AS_CONFED_SET is only for AS internal routes) seems to be
easiest, but I don't know if those implementations that already use
AS_CONFED_SET would be compliant with such requirement.

If we assume that it's ok to aggregate even AS external routes, then
according to section 9.1.4 of RFC4271 (page 84, second paragraph from
the top):

"...
   If a BGP speaker chooses to aggregate, then it SHOULD either include
   all ASes used to form the aggregate in an AS_SET, or add the
   ATOMIC_AGGREGATE attribute to the route.
..."

The draft calls for simply removing AS_CONFED_SET. Would it
automatically mean (per RFC4271) that such implementation will either
translate AS_CONFED_SET to AS_SET (this operation is not defined neither
in draft nor in RFC4271) or will it set ATOMIC_AGGREGATE?

/iLya

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 11 Aug 2006 14:42:13 -0400

At 12:05 AM +0530 8/12/06, Glen Kent wrote:
>the ATOMIC_AGGREGATE.

That's one case when you use it, yes.  Technically, you use it any 
time any of the AS numbers in any constituent route isn't included in 
an aggregate.

>If thats the case then we need to deprecate
>AS_SET too.

I don't follow you.

>Are you suggesting that the SETs have no utility at all?

No, I'm not suggesting that.  I should have added the disclaimer that 
my point was tangential to the original conversation.

--John

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 11 Aug 2006 15:36:42 -0400

> from confederation peers should be aggregated. But is this correct? Is

Consider AS_PATH-A and AS_PATH-B

If some AS aggregates AS_PATH-A and AS_PATH-B, we will have a new
AS_PATH, AS_PATH-C which will include that AS as the leading AS.
Components of -A and -B will be aggregated per the RFC 4271 aggregation
rules.

If this AS is running confederations, logically aggregation of these
two paths within the confederation must, on out-of-confederation
advertisement, result in -C.  (Or, -C must be able to result from
normal aggregation.)

Aggregation-wise, this can be done by aggregating the non-confederation
and the confederation components separately. This is done using the same rules
for sets and sequences, but applying them to only the same types;
i.e.confeds with confeds, non-confeds with non-confeds.

I'll take a stab at wordsmithing something about this using
the base spec as the reference.  I'll try to finish this in the next
couple of days.

-- Jeff

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 11 Aug 2006 14:21:06 -0400

No, I think if we wanted to fully spec how to build an AS_CONFED_SET 
we'd have to do it much more completely than that -- which is why I 
like Jeff's suggestion that we simply point to the base spec.  That 
way we can write fewer words and keep the window for error much 
smaller.

--John

---

From: "Ilya Varlashkin" <[email-masked]>
Date: Fri, 11 Aug 2006 20:21:18 +0200

> Sent: Friday, August 11, 2006 8:13 PM
> To: Jeffrey Haas
> When a BGP confederation speaker aggregates several routes 
> for the purpose of advertisement to a particular 
> confederation peer, the AS_PATH of the aggregated route 
> normally includes an AS_CONFED_SET formed from the set of 
> ASes from which the aggregate was formed.
> 
Glen,

/iLya

---

From: "Manav Bhatia" <[email-masked]>
Date: Sun, 13 Aug 2006 11:39:11 +0530

Hi iLya,

> translate AS_CONFED_SET to AS_SET (this operation is not defined neither

This cant be done as you would not want to leak the member AS numbers 
outside the confederation.

> in draft nor in RFC4271) or will it set ATOMIC_AGGREGATE?

Presence of ATOMIC_AGGREGATE informs the downstream neighbors that the 
AS_PATH information may be incomplete and/or in a nonordered set. This is 
not applicable for BGP confederation speakers that strip of the AS_CONFED_* 
segments when advertising routes to non-confederation peers as these peers 
dont anyways expect to see confederation member AS numbers in the AS_PATH. 
Note that non-confed peers are unaware that the neighboring AS is running 
confederations.

There is thus no loss of any AS_PATH information here and therefore no need 
of an ATOMIC_AGGREGATE.

Manav

---

From: "Ilya Varlashkin" <[email-masked]>
Date: Sun, 13 Aug 2006 13:46:43 +0200

Hi Manav,

> This cant be done as you would not want to leak the member AS 
> numbers outside the confederation.
> 
> Presence of ATOMIC_AGGREGATE informs the downstream neighbors 
> that the AS_PATH information may be incomplete and/or in a 
> nonordered set. This is not applicable for BGP confederation 
> speakers that strip of the AS_CONFED_* segments when 
> advertising routes to non-confederation peers as these peers 
> Note that non-confed peers are unaware that the neighboring 
> AS is running confederations.
> 
> There is thus no loss of any AS_PATH information here and 
> therefore no need of an ATOMIC_AGGREGATE.
> 

All this I'm aware of. My statements were only related to situation
where and if AS_CONFED_SET is/was used while aggregating foreign
prefixes. First alternative was to forbid such use and that's where
final document seems to be going, so above described situation won't
happen and respective actions are not necessary.

Kind regards,
iLya

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 16 Aug 2006 10:50:29 -0400

> Note that non-confed peers are unaware that the neighboring AS is running 

In the instance where a set of routes are aggregated within a confederation
and ATOMIC_AGGREGATE is set for some reason, it should stay set
when readvertising the route outside of the confederation.

There is the possibility that the original contributing routes,
when aggregated at the confederation edge would not have yielded
ATOMIC_AGGREGATE.  However, we can't know this.  This is a better
safe than sorry situation.

I find it likely that people who are generating AS_CONFED_SETs aren't
likely to do lossy (AS_PATH truncation) based aggregation.  This,
however, is just an opinion.

-- Jeff