Subject: Re: handling unrecognized optional transitive attributes
From: Charles Lynn <[email-masked]>
To: [email-masked]
Cc: Dmitri Krioukov <[email-masked]>, Mark Mentovai <[email-masked]>, Charles Lynn <[email-masked]>
Date: Fri, 16 Feb 2001 19:21:13 +0500 (EST)

Following up on a few points...

Dima notes:
    it's easier to imagine an optional transitive attribute with
    semantics such that even if all routes being aggregated have the
    identical value of this attribute, the attribute value for the
    aggregated route is not supposed to be the same.

Yes.  Perhaps simply not aggregating routes with unknown transitive
path attributes would be better.  Andrew said that most folks upgrade
their s/w fairly often.  I suspect, but could be mistaken, that those
are the same folks that need to aggregate.  Thus specifying a behavior
that would be better in the long run (which may or may not be what
happens today) should be quickly deployed where aggregation is needed.

Mark asks:
    Are there any (real, not imaginary) used or proposed optional
    transitive attributes that would break under the "copy if all
    identical, else drop" scheme under discussion?

It depends on the definition of "break".  Lets consider the meaning
to be "would cause routes to be accepted and/or propagated that are
inconsistent with administration policy".  Here are a couple of examples
based on others' comments:

Enke commented:
    Also, it seems to me that the question of "what might happen with
    choice 1" has been answered for quite some time. The COMMUNITY
    attribute which is optional transitive was introduced and deployed
    (quite smoothly if I remember correctly).

Is the claim that when a community attribute carrying the well-known
community NO-EXPORT is dropped by an aggregating AS, that the associated
routes are not exported to other ASes?  It seems to me that dropping the
attribute would, in fact, cause something to "break".  Maybe NO-EXPORT
isn't being used; maybe it isn't being used BECAUSE folks see that the
aggregation actions currently deployed are "broken", in this situation;
maybe ASes were not doing much aggregation when the deployment happened.

Mark states:
    The proposed NEW_AS_PATH and NEW_AGGREGATOR also don't seem to pose
    a problem.

	(I am still digesting draft-ietf-idr-as4bytes-01, so please
	 correct me if my understanding is wrong...)

As I understand the rules, a 32-bit AS# capable AS that sends a route
to a 16-bit AS# AS inserts NEW_AS_PATH to carry the 32-bit AS numbers.
If the 16-bit AS# only AS then aggregates the route (given that the
AS_PATH attributes of the to be aggregated routes all have 16-bit AS#s
and the generic AS_TRANS AS# in just the right places) and drops the
NEW_AS_PATH before forwarding it on to another 32-bit AS# AS, hasn't
that "broken" AS path filtering for the receiving 32-bit AS# AS?
If so, I would call that "a problem".

	(Of course, the next version of the draft may change the way
	 things are done to address this issue, given the currently
	 deployed Choice 1.  Or maybe nobody cares about AS path
	 filtering;  or maybe the cost to fix the deployed code is
	 greater than the cost of a violated policy; or maybe ...)

One could also use a weaker definition of "break" that has semantics
of "make introduction of new capabilities, by those ASes that want to
use them, harder because doing so requires other ASes (that may not be
interested in the new capabilities) to upgrade their software".  This
difficulty potentially applies to each new capability that is introduced.

The above examples are also covered by this definition, as would be
the Secure BGP Attestation Path Attribute (to answer Mark's question
above about real, proposed optional transitive attributes).
	[Truth in advertising disclaimer: if choice 1 (drop) were
	 to be mandated, that would make the S-BGP implementation
	 and policy configuration a LOT simpler.]

What this really means, I would guess, is that the ASes that want to
use new capabilities would simply form a bi-lateral peering agreement
to bypass any ASes that do not want to support the new capabilities.
	(A "deploy from a single core outward" model instead of an
	 "interconnected islands" aka "capability-bone" deployment model.)

My opinion is that it would be better if the BGP protocol didn't
encourage even more peering sessions, or other "workarounds", because
of a misfeature in its specification.

Charlie

From: Vivek Menezes <[email-masked]>
To: "'Enke Chen'" <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: handling unrecognized optional transitive attributes 
Date: Fri, 16 Feb 2001 09:44:31 -0800
Sender: [email-masked]

Well said Enke. It looks like BGP implementations that have been
deployed (Cisco et al) work very different from the RFC. Maybe Yakov you
might consider
changing the RFC to make it more relevant.

There are a lot of people out there (in this discussion group, especially
from the
academic community) who assume that implementations are similar to the RFC.
If the RFC
is not inline with whats deployed their input would not be valuable and
improvements to
BGP would only be restricted to people working at router vendors.

Cheers,

Vivek.

-----Original Message-----
From: Enke Chen [mailto:[email-masked]]
Sent: Thursday, February 15, 2001 7:32 PM
To: Charles Lynn
Cc: Yakov Rekhter; [email-masked]
Subject: Re: handling unrecognized optional transitive attributes 

> Date:     Thu, 15 Feb 2001 21:57:27 +0500 (EST)
> From: Charles Lynn <[email-masked]>
> To: Yakov Rekhter <[email-masked]>
> Cc: [email-masked]
> Subject:  Re:  handling unrecognized optional transitive attributes
> Message-Id: <[email-masked]>
> Sender: [email-masked]
> Precedence: bulk
> 
> Re: handling of unknown optional transitive attributes by an aggregator
> 
> I agree that the WG should specify how they should be handled, and I
> think that:
> 
> 	only aggregate routes with identical attributes,
> 	setting the partial bit.
> 
> is the best of the choices being discussed.  The other alternatives
> that have been suggested include:
>  1) drop these attributes;
>  2) pick one and ignore the others; and
>  3) combinations/choices of the above.
> 
> Consider what might happen with choice 1. If one were to try to
> introduce a new attribute that carried semantics like
> ATOMIC_AGGREGATE, incremental deployment would be difficult.  There
> are cases where dropping an attribute could lead to lost traffic or
> route loops.  As has been pointed out, a drop strategy will make
> introduction of any improvements to BGP difficult.

If we were at the initial BGP deployment stage, we could as well have
a different pick. However, "Choice 1" has been deployed (although not
specified) for many years. Whatever future extensions that do not
consider this reality will have a huge transition issue.

Also, it seems to me that the question of "what might happend with
choice 1" has been answered for quite some time. The COMMUNITY attribute
which is optional transitive was introduced and deployed (quite smoothly
if I remember correctly).

-- Enke

> 
> With choice 2, the semantics of a new attribute could be attached to
> NLRI to which they do not apply.  Again, one might get dropped traffic
> or route loops.
> 
> Choice 3 is worse.  With this choice the semantics of the aggregate
> could not be known as the receiver would not know what choices the
> aggregator made (when the partial bit is set).
> 
> If any of rules 1, 2, or 3 were in place, could BGP be easily extended
> to include new attributes with, say, semantics similar to MP-REACH-NLRI,
> and have that functionality incrementally deployed throughout the net?
> 
> For these reasons, the suggested rule of only aggregating routes with
> identical attributes (and setting the partial bit) seems to be the
> best choice.
> 
> Note that, if the operators of an AS really need to aggregate routes
> with unknown attributes, they will have a good argument to present to
> its router vendors to explain why the new attribute should be
> implemented.
> 
> 
> Stepping back from the immediate question, the WG might want to
> consider a mechanism to address the problem of not knowing how to
> aggregate unknown attributes.  Yakov, Xavier, and Dima have commented
> on per-attribute semantics.  The WG could define a new attribute
> flag(s) indicating how the attribute should be handled when a route
> containing the attribute is a candidate for aggregation.  The flag
> technique has been used in other IETF protocols.  The question of
> whether the cost to implement such a mechanism would need to be
> investigated.
> 
> (For the record, I object to the proposal force speakers to drop
>  recognized optional transitive attributes from aggregated routes. :-)
> 
> Charlie
> 

Date: Fri, 16 Feb 2001 10:41:10 -0500
From: tim griffin <[email-masked]>
Reply-To: [email-masked]
Organization: at&t labs 
To: "John G. Scudder" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: BGP Route Oscillation
Sender: [email-masked]

John,

Thanks for your comments.

>Many of the papers you cite talk about discovering incommensurable
>policies, either statically or through protocol extensions.  Since
>the MED oscillation problem isn't a result of configured policy, I
>don't see how such research can directly apply.
>
>In the MED oscillation case, you can get the oscillation even if
>there is no configured policy at all.  Thus I think it's a different
>animal than the oscillation cases which have been covered in the
>literature to date.

Let's call the policies we type into a configuration file "apparent"
routing policies, and call the dynamic ranking of routes that gets
realized on a router the "actual" routing policies.  The actual
policies on a router result from a (sometimes complex) interaction
of its apparent policies, the BGP route selection process, and the
actual policies of neighboring routers.  I think most of the papers
on BGP oscillation are really about incommensurable *actual* policies,
and so they do apply.  In the MED oscillation examples routers
end up with actual policies that together have no solution.

Actual policies are in principle close to the function discussed in
draft-ietf-idr-bgp4-12.txt, Section 9.1:

   The selection process is formalized by defining a function that takes
   the attribute of a given route as an argument and returns a non-
   negative integer denoting the degree of preference for the route.
   The function that calculates the degree of preference for a given
   route shall not use as its inputs any of the following: the existence
   of other routes, the non-existence of other routes, or the path
   attributes of other routes. Route selection then consists of
   individual application of the degree of preference function to each
   feasible route, followed by the choice of the one with the highest
   degree of preference.

Perhaps MED is bad because it can make the translation from
apparent to actual policies very hard to understand. MED is special
in that it is not "compositional" like other steps in the
route selection process.  If we ignore MED, then we can think of
ranking each route independently of other routes just as implied
by the description of the ranking function in Section 9.1 quoted above.
That is, we can think of the selection process as imposing some sort
of simple lexical order on routes. But MED breaks this nice model,
since its rule is conditional -- compare MEDs only when the next hop
ASNs are the same.  Now actual policies are no longer simple and intuitive
rankings of paths.  A route's rank can now depend on the existence,
or non-existence of other routes.  But isn't this the kind of ranking
that is explicitly prohibited in Section 9.1? If so, why is it allowed
in the Phase 2 tie breaking?  I have always assumed that prohibition
of "existential criteria" was there so that human beings could understand
(and debug) the actual routing policies that result from their apparent ones.

A simple fix might be to eliminate the MED step entirely, and
add the MED value to the igp cost of a route.  I realize this will
cause other problems.  However, it is easy to understand and may
cover most of the current uses of MED just fine. It would
require more cooperation between those sending and those listening
to MEDs, which might not be a bad thing.

> [...] The difference is that it is at least
>possible to fix the policies so as to eliminate the oscillation --
>i.e., you can view the incommensurable policies as a case of
>misconfiguration.

I'm not sure that incommensurable policies will *always* be the result
of misconfiguration.  That is, I can't rule out a scenario where

   1) everyone involved is doing something locally sane,
   2) the interaction of the local policies result in protocol oscillation
   3) no one is willing to budge (change their policies). Every AS
      involved is convinced that the others are at fault.

Cheers,
Tim

To: "[email-masked]'" <[email-masked]>
From: Danny McPherson <[email-masked]>
Reply-To: [email-masked]
Subject: Re: handling unrecognized optional transitive attributes 
Date: Fri, 16 Feb 2001 09:16:13 -0700
Sender: [email-masked]

I registered my opinion in messages prior to 
this one.  Clearly, it's not a good thing, but 
I do agree that you have to draw the line
somewhere between complexity and flexibility.

-danny

> By dropping new "unknown" optional transitive attributes you make it very
> difficult to phase in 
> new attributes as the BGP protocol continues to evolve. Is this a good
> thing?

From: Ben Abarbanel <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: handling unrecognized optional transitive attributes 
Date: Fri, 16 Feb 2001 10:54:12 -0500
Sender: [email-masked]

By dropping new "unknown" optional transitive attributes you make it very
difficult to phase in 
new attributes as the BGP protocol continues to evolve. Is this a good
thing?

Ben

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Danny
McPherson
Sent: Thursday, February 15, 2001 12:18 PM
To: [email-masked]
Subject: Re: handling unrecognized optional transitive attributes 

> I think, is not realistic since it would
> lead to potentially different requirements for
> different attributes.

Yeah, this is my biggest problem with any alternative as 
well.

-danny

Date: Fri, 16 Feb 2001 08:12:33 -0500 (EST)
From: Mark Mentovai <[email-masked]>
To: Dmitri Krioukov <[email-masked]>
Cc: Charles Lynn <[email-masked]>, IDR <[email-masked]>
Subject: RE: handling unrecognized optional transitive attributes
Sender: [email-masked]

Dmitri Krioukov wrote:
>It's hard to imagine an optional transitive attribute with
>semantics similar to ATOMIC_AGGREGATE, while it's easier,
>I think, to imagine an optional transitive attribute with
>semantics such that even if all routes being aggregated
>have the identical value of this attribute, the attribute
>value for the aggregated route is not supposed to be the same.

It's hard to imagine, period.  Let's consider some real optional transitive
attributes.  I've already covered the case of AGGREGATOR.  COMMUNITIES is a
no-brainer (to me, anyway.)  The proposed NEW_AS_PATH and NEW_AGGREGATOR
also don't seem to pose a problem.  Are there any (real, not imaginary) used
or proposed optional transitive attributes that would break under the "copy
if all identical, else drop" scheme under discussion?

Mark

From: "Dmitri Krioukov" <[email-masked]>
To: "Charles Lynn" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: handling unrecognized optional transitive attributes
Date: Thu, 15 Feb 2001 23:33:49 -0500
Importance: Normal
Sender: [email-masked]

It's hard to imagine an optional transitive attribute with
semantics similar to ATOMIC_AGGREGATE, while it's easier,
I think, to imagine an optional transitive attribute with
semantics such that even if all routes being aggregated
have the identical value of this attribute, the attribute
value for the aggregated route is not supposed to be the same.
--
dima.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Charles Lynn
> Sent: Thursday, February 15, 2001 11:57 AM
> To: Yakov Rekhter
> Cc: [email-masked]
> Subject: Re: handling unrecognized optional transitive attributes
> 
> 
> Re: handling of unknown optional transitive attributes by an aggregator
> 
> I agree that the WG should specify how they should be handled, and I
> think that:
> 
> 	only aggregate routes with identical attributes,
> 	setting the partial bit.
> 
> is the best of the choices being discussed.  The other alternatives
> that have been suggested include:
>  1) drop these attributes;
>  2) pick one and ignore the others; and
>  3) combinations/choices of the above.
> 
> Consider what might happen with choice 1. If one were to try to
> introduce a new attribute that carried semantics like
> ATOMIC_AGGREGATE, incremental deployment would be difficult.  There
> are cases where dropping an attribute could lead to lost traffic or
> route loops.  As has been pointed out, a drop strategy will make
> introduction of any improvements to BGP difficult.
> 
> With choice 2, the semantics of a new attribute could be attached to
> NLRI to which they do not apply.  Again, one might get dropped traffic
> or route loops.
> 
> Choice 3 is worse.  With this choice the semantics of the aggregate
> could not be known as the receiver would not know what choices the
> aggregator made (when the partial bit is set).
> 
> If any of rules 1, 2, or 3 were in place, could BGP be easily extended
> to include new attributes with, say, semantics similar to MP-REACH-NLRI,
> and have that functionality incrementally deployed throughout the net?
> 
> For these reasons, the suggested rule of only aggregating routes with
> identical attributes (and setting the partial bit) seems to be the
> best choice.
> 
> Note that, if the operators of an AS really need to aggregate routes
> with unknown attributes, they will have a good argument to present to
> its router vendors to explain why the new attribute should be
> implemented.
> 
> 
> Stepping back from the immediate question, the WG might want to
> consider a mechanism to address the problem of not knowing how to
> aggregate unknown attributes.  Yakov, Xavier, and Dima have commented
> on per-attribute semantics.  The WG could define a new attribute
> flag(s) indicating how the attribute should be handled when a route
> containing the attribute is a candidate for aggregation.  The flag
> technique has been used in other IETF protocols.  The question of
> whether the cost to implement such a mechanism would need to be
> investigated.
> 
> (For the record, I object to the proposal force speakers to drop
>  recognized optional transitive attributes from aggregated routes. :-)
> 
> Charlie

Date: Thu, 15 Feb 2001 23:06:57 -0500
From: Andrew Partan <[email-masked]>
To: Enke Chen <[email-masked]>
Cc: Charles Lynn <[email-masked]>, Yakov Rekhter <[email-masked]>, [email-masked]
Subject: Re: handling unrecognized optional transitive attributes
Sender: [email-masked]

On Thu, Feb 15, 2001 at 07:32:19PM -0800, Enke Chen wrote:
> If we were at the initial BGP deployment stage, we could as well have
> a different pick. However, "Choice 1" has been deployed (although not
> specified) for many years. Whatever future extensions that do not
> consider this reality will have a huge transition issue.

Rolling out changed s/w is fairly doable; most folks upgrade their
s/w fairly often.  Yes, this change will not get to everyone, but
it should hit most of the net fairly quickly.

> Also, it seems to me that the question of "what might happend with
> choice 1" has been answered for quite some time. The COMMUNITY attribute
> which is optional transitive was introduced and deployed (quite smoothly
> if I remember correctly).

Communities are there, but have you ever tried to get one sent from
one side of the net to the other?  They are fairly well blocked at
AS borders.
	--asp

To: Charles Lynn <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, [email-masked]
Subject: Re: handling unrecognized optional transitive attributes 
Date: Thu, 15 Feb 2001 19:32:19 -0800
From: Enke Chen <[email-masked]>
Sender: [email-masked]

> Date:     Thu, 15 Feb 2001 21:57:27 +0500 (EST)
> From: Charles Lynn <[email-masked]>
> To: Yakov Rekhter <[email-masked]>
> Cc: [email-masked]
> Subject:  Re:  handling unrecognized optional transitive attributes
> Message-Id: <[email-masked]>
> Sender: [email-masked]
> Precedence: bulk
> 
> Re: handling of unknown optional transitive attributes by an aggregator
> 
> I agree that the WG should specify how they should be handled, and I
> think that:
> 
> 	only aggregate routes with identical attributes,
> 	setting the partial bit.
> 
> is the best of the choices being discussed.  The other alternatives
> that have been suggested include:
>  1) drop these attributes;
>  2) pick one and ignore the others; and
>  3) combinations/choices of the above.
> 
> Consider what might happen with choice 1. If one were to try to
> introduce a new attribute that carried semantics like
> ATOMIC_AGGREGATE, incremental deployment would be difficult.  There
> are cases where dropping an attribute could lead to lost traffic or
> route loops.  As has been pointed out, a drop strategy will make
> introduction of any improvements to BGP difficult.

If we were at the initial BGP deployment stage, we could as well have
a different pick. However, "Choice 1" has been deployed (although not
specified) for many years. Whatever future extensions that do not
consider this reality will have a huge transition issue.

Also, it seems to me that the question of "what might happend with
choice 1" has been answered for quite some time. The COMMUNITY attribute
which is optional transitive was introduced and deployed (quite smoothly
if I remember correctly).

-- Enke

> 
> With choice 2, the semantics of a new attribute could be attached to
> NLRI to which they do not apply.  Again, one might get dropped traffic
> or route loops.
> 
> Choice 3 is worse.  With this choice the semantics of the aggregate
> could not be known as the receiver would not know what choices the
> aggregator made (when the partial bit is set).
> 
> If any of rules 1, 2, or 3 were in place, could BGP be easily extended
> to include new attributes with, say, semantics similar to MP-REACH-NLRI,
> and have that functionality incrementally deployed throughout the net?
> 
> For these reasons, the suggested rule of only aggregating routes with
> identical attributes (and setting the partial bit) seems to be the
> best choice.
> 
> Note that, if the operators of an AS really need to aggregate routes
> with unknown attributes, they will have a good argument to present to
> its router vendors to explain why the new attribute should be
> implemented.
> 
> 
> Stepping back from the immediate question, the WG might want to
> consider a mechanism to address the problem of not knowing how to
> aggregate unknown attributes.  Yakov, Xavier, and Dima have commented
> on per-attribute semantics.  The WG could define a new attribute
> flag(s) indicating how the attribute should be handled when a route
> containing the attribute is a candidate for aggregation.  The flag
> technique has been used in other IETF protocols.  The question of
> whether the cost to implement such a mechanism would need to be
> investigated.
> 
> (For the record, I object to the proposal force speakers to drop
>  recognized optional transitive attributes from aggregated routes. :-)
> 
> Charlie
> 

Date:     Thu, 15 Feb 2001 21:57:27 +0500 (EST)
From: Charles Lynn <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject:  Re:  handling unrecognized optional transitive attributes
Sender: [email-masked]

Re: handling of unknown optional transitive attributes by an aggregator

I agree that the WG should specify how they should be handled, and I
think that:

	only aggregate routes with identical attributes,
	setting the partial bit.

is the best of the choices being discussed.  The other alternatives
that have been suggested include:
 1) drop these attributes;
 2) pick one and ignore the others; and
 3) combinations/choices of the above.

Consider what might happen with choice 1. If one were to try to
introduce a new attribute that carried semantics like
ATOMIC_AGGREGATE, incremental deployment would be difficult.  There
are cases where dropping an attribute could lead to lost traffic or
route loops.  As has been pointed out, a drop strategy will make
introduction of any improvements to BGP difficult.

With choice 2, the semantics of a new attribute could be attached to
NLRI to which they do not apply.  Again, one might get dropped traffic
or route loops.

Choice 3 is worse.  With this choice the semantics of the aggregate
could not be known as the receiver would not know what choices the
aggregator made (when the partial bit is set).

If any of rules 1, 2, or 3 were in place, could BGP be easily extended
to include new attributes with, say, semantics similar to MP-REACH-NLRI,
and have that functionality incrementally deployed throughout the net?

For these reasons, the suggested rule of only aggregating routes with
identical attributes (and setting the partial bit) seems to be the
best choice.

Note that, if the operators of an AS really need to aggregate routes
with unknown attributes, they will have a good argument to present to
its router vendors to explain why the new attribute should be
implemented.

Stepping back from the immediate question, the WG might want to
consider a mechanism to address the problem of not knowing how to
aggregate unknown attributes.  Yakov, Xavier, and Dima have commented
on per-attribute semantics.  The WG could define a new attribute
flag(s) indicating how the attribute should be handled when a route
containing the attribute is a candidate for aggregation.  The flag
technique has been used in other IETF protocols.  The question of
whether the cost to implement such a mechanism would need to be
investigated.

(For the record, I object to the proposal force speakers to drop
 recognized optional transitive attributes from aggregated routes. :-)

Charlie

To: Yakov Rekhter <[email-masked]>
Cc: "Dmitri Krioukov" <[email-masked]>, [email-masked]
Subject: Re: handling unrecognized optional transitive attributes 
Date: Thu, 15 Feb 2001 11:30:46 -0800
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Yakov,
Another data pointer: I belive that the deployed base operates on
the "dropping" model for "unrecognized transitive attributes" in
aggregation, which might present another huddle for any alternative.

-- Enke

> Message-Id: <[email-masked]>
> To: "Dmitri Krioukov" <[email-masked]>
> Cc: [email-masked]
> Subject: Re: handling unrecognized optional transitive attributes 
> In-Reply-To: Your message of "Thu, 15 Feb 2001 12:15:47 EST."
>              <[email-masked]> 
> MIME-Version: 1.0
> Content-Type: text/plain; charset="us-ascii"
> Content-ID: <[email-masked]>
> Date: Thu, 15 Feb 2001 09:31:11 -0800
> From: Yakov Rekhter <[email-masked]>
> Sender: [email-masked]
> Precedence: bulk
> 
> Dima,
> 
> > I'd say that the discussion of the AGGREGATOR
> > example suggests "MUST drop" unless you want
> > to depend on semantics of a given attribute,
> > which, I think, is not realistic since it would
> > lead to potentially different requirements for
> > different attributes.
> 
> Even more important, since the BGP speaker doesn't recognize the
> attribute, handling of this attribute by the speaker can't depend 
> on the semantics of this attribute (as handling of this attribute
> based on the semantics assumes that the speaker knows the semantics
> of this attribute, and therefore assumes that the speaker recognizes it, 
> which contradicts the premise that the speaker doesn't recognize it).
> 
> Yakov.
> 
> > --
> > dima.
> > 
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]On Behalf Of Danny
> > > McPherson
> > > Sent: Thursday, February 15, 2001 11:15 AM
> > > To: [email-masked]
> > > Subject: Re: handling unrecognized optional transitive attributes 
> > > 
> > > 
> > > 
> > > > So, let's say that out of three routes to be aggregate two
> > > > routes contain an unrecognized optional transitive attribute.
> > > > What would you expect happen in this case ?
> > > 
> > > Based on the wording I provided a moment ago .. drop it.  If all 
> > > three contain the unrecognized optional transitive attribute 
> > > then the attribute MUST (or SHOULD?) be passed along to other 
> > > BGP peers and the Partial bit set to 1.
> > > 
> > > While I agree with you in general, dropping the attribute just 
> > > doesn't make sense to me if ALL the subsets of a given aggregate
> > > contain an identical optional transitive attribute. 
> > > 
> > > Of course, this model is a bit more complex, especially when one 
> > > considers what now needs to be done if the value of that one more-
> > > specific's optional transitive attribute changes (be it in either 
> > > case) .. as such, I don't have _strong feelings either way.
> > > 
> > > -danny
> > > 
> > 
> 

To: [email-masked]
From: Danny McPherson <[email-masked]>
Reply-To: [email-masked]
Subject: Re: BGP Route Oscillation 
Date: Thu, 15 Feb 2001 11:20:03 -0700
Sender: [email-masked]

Thanks for the pointers Tim, I'm sure many will find them 
interesting. 

JSYK, the next version of the draft do indeed talk more about
the general problem here.  Obviously, once it's submitted your 
feedback regarding additional clarifications is welcome.

-danny

> It may help to identify the root cause of the
> oscillation problem.  To me the problem is inherent in
> the way BGP works --- locally defined routing policies may
> conflict globally, and certain types of conflicts can
> cause persistent oscillation of the protocol.

Date: Thu, 15 Feb 2001 12:14:09 -0500
From: tim griffin <[email-masked]>
Reply-To: [email-masked]
Organization: at&t labs 
To: [email-masked], [email-masked]
Subject: Re: BGP Route Oscillation
Sender: [email-masked]

draft-mcpherson-bgp-route-oscillation-00.txt states (page 15) :

>>   It should be stated that protocol enhancements regarding this problem
>>   must be pursued.  Imposing network design requirements such as those
>>   outlined above are clearly an unreasonable long-term solution.  Prob-
>>   lems such as this should not occur under 'default' configurations.

It may help to identify the root cause of the
oscillation problem.  To me the problem is inherent in
the way BGP works --- locally defined routing policies may
conflict globally, and certain types of conflicts can
cause persistent oscillation of the protocol.
Given current practices, we happen to see
the problem manifest itself in the context of
MED + route reflectors or confederations.  But simple
examples can be constructed using only e-BGP and local pref.
Although these examples currently don't seem to arise in
practice, one can imagine that in the future they could
in any number of ways (say a fancy use of extended communities
to implement interdomain traffic engineering or QoS routing).

Perhaps a generic mechanism is required to detect protocol
oscillations dynamically. I've attached a list of recent
research papers concerned with BGP persistent oscillation.
I hope these will be useful. Paper [5] does define
a mechanism for dynamic detection of protocol oscillation,
but I'll be the first to admit that it does this only for an
idealized version of BGP and that it is not yet clear if
this model could serve as a basis for a practical extension
to real world BGP.

Tim Griffin
[email-masked]
http://www.research.att.com/~griffin

---------------------------------------------------------------
Recent research papers on BGP persistent oscillation.
---------------------------------------------------------------
[1] Persistent Route Oscillations in Inter-Domain Routing.
Kannan Varadhan, Ramesh Govindan, and Deborah Estrin.
Computer Networks, Jan. 2000.
http://www.elsevier.nl/gej-ng/10/15/22/45/25/27/article.pdf
Also USC Tech Report CS TR 96-631, Feb. 1996,
Department of Computer Science, University of Southern California.

     This was the first article to point out that fact
     that conflicting routing policies may cause persistent
     oscillations with BGP. Examples can be constructed using
     only e-BGP and local preference.

[2] An Architecture for Stable, Analyzable Internet Routing.
Ramesh Govindan, Cengiz Alaettinoglu, George Eddy,
David Kessens, Satish Kumar, and WeeSan Lee.
IEEE Network Magazine, Jan-Feb 1999.
ftp://ftp.isi.edu/pub/govindan/ieeeNetwork99.ps.gz.

     Describes the router registries (IRR) and a language
     for defining interdomain routing policies (RPSL).
     As does [1], proposes that BGP persistent oscillation
     can be avoided by analysis of stored routing policies.

[3] An Analysis of BGP Convergence Properties.
Timothy G. Griffin and Gordon Wilfong.
SIGCOMM 1999
http://www.acm.org/sigcomm/sigcomm99/papers/session8-1.html.

     Shows that the type of static analysis of routing
     policies suggested in [1][2] is NP-complete.

[4] Policy Disputes in Path Vector Protocols.
Timothy G. Griffin, F. Bruce Shepherd, and Gordon Wilfong.
ICNP'99.
http://www.research.att.com/~griffin/icnp1999.html.

[5] A Safe Path Vector Protocol.
Timothy G. Griffin and Gordon Wilfong.
INFOCOM 2000.
http://www.ieee-infocom.org/2000/papers/99.ps.

     Papers [4] and [5] introduce a simple model, called
     the Stable Paths Problem (SPP), that is to BGP what
     the Shortest Paths Problem is to OSPF and RIP.
     They also define a Simple Path Vector Protocol (SPVP),
     and idealized BGP-like protocol that attempts to
     solve an instances of the SPP. A sufficient condition
     is given that guarantees that an instance of SPP
     has a unique solution and that the SPVP protocol
     will always converge. [5] introduces an extension to
     to SPVP that dynamically detects persistent oscillations.
     More work is needed to determine if this could be the
     basis of a practical extension to BGP.  See also the NANOG talk,
     http://www.nanog.org/mtg-0002/griffin.html

[6] Stable Internet routing without global coordination.
Lixin Gao and Jennifer Rexford.
SIGMETRICS 2000.
http://www.research.att.com/~jrex/papers/sigmetrics00.ps.

     Shows that if all ASes have customer/provider and
     peer/peer relationships, and all routing is based on
     preferring customers over peers and providers, then
     BGP will not diverge if there are no customer/provider
     cycles.  In other words, current practices
     seem to go a long way in explaining why we do not see
     interdomain persistent oscillations.

[7] Inherently Safe Backup Routing with BGP.
Lixin Gao, Timothy G. Griffin, and Jennifer Rexford.
to appear at INFOCOM 2001.
http://www.research.att.com/~jrex/papers/infocom01.ps.

    Uses the theoretical framework of [4][5] to extend the
    results of [6] to include backup routing similar to that
    outlined in RFC 1998.

Date: Thu, 15 Feb 2001 12:43:34 -0500
From: Xavier Briard <[email-masked]>
Organization: Tenor Networks
To: [email-masked]
Cc: [email-masked]
Subject: Re: handling unrecognized optional transitive attributes
Sender: [email-masked]

> I see, you want an "Optional [transitive] attribute" .. sounds
> familiar.   Then you're back to the same problem of what to do when
> it's unrecognized or and/or only present in a subset of the routes
> that comprise the aggregate.

Not exactly. I meant more some aggregation rules LOCALLY configurable
PER code type (this code type being a LOCALLY unrecognized optional
attribute).

The foundation of those STANDARD rules could look like:
- rule 0 (default): drop
- rule 1: drop unless all subsets present the EXACT same attribute value
- rule 2: extend BGP path attribute encoding to find a way to
concatenate all values...

BTW, in all cases (except 0) set the partial bit.

> The general goal, and presumably, the reason it was asked, was to keep
> things as simple as possible while providing as much flexibility as
> possible.
> 

Agreed. "always dropping" is simple and does not require to monitor if
the value of any subset happens to change over the life time of the
aggregated route. The solution suggested above is fully flexible. It's
almost a new feature: "aggregating rules for unrecognized optional
transitive". It can help deployement of new such attributes. But is it
worth it? not sure!

BTW leaving the thread.
Xavier

To: "Dmitri Krioukov" <[email-masked]>
Cc: [email-masked]
Subject: Re: handling unrecognized optional transitive attributes 
Date: Thu, 15 Feb 2001 09:31:11 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Dima,

> I'd say that the discussion of the AGGREGATOR
> example suggests "MUST drop" unless you want
> to depend on semantics of a given attribute,
> which, I think, is not realistic since it would
> lead to potentially different requirements for
> different attributes.

Even more important, since the BGP speaker doesn't recognize the
attribute, handling of this attribute by the speaker can't depend 
on the semantics of this attribute (as handling of this attribute
based on the semantics assumes that the speaker knows the semantics
of this attribute, and therefore assumes that the speaker recognizes it, 
which contradicts the premise that the speaker doesn't recognize it).

Yakov.

> --
> dima.
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On Behalf Of Danny
> > McPherson
> > Sent: Thursday, February 15, 2001 11:15 AM
> > To: [email-masked]
> > Subject: Re: handling unrecognized optional transitive attributes 
> > 
> > 
> > 
> > > So, let's say that out of three routes to be aggregate two
> > > routes contain an unrecognized optional transitive attribute.
> > > What would you expect happen in this case ?
> > 
> > Based on the wording I provided a moment ago .. drop it.  If all 
> > three contain the unrecognized optional transitive attribute 
> > then the attribute MUST (or SHOULD?) be passed along to other 
> > BGP peers and the Partial bit set to 1.
> > 
> > While I agree with you in general, dropping the attribute just 
> > doesn't make sense to me if ALL the subsets of a given aggregate
> > contain an identical optional transitive attribute. 
> > 
> > Of course, this model is a bit more complex, especially when one 
> > considers what now needs to be done if the value of that one more-
> > specific's optional transitive attribute changes (be it in either 
> > case) .. as such, I don't have _strong feelings either way.
> > 
> > -danny
> > 
> 

To: [email-masked]
From: Danny McPherson <[email-masked]>
Reply-To: [email-masked]
Subject: Re: handling unrecognized optional transitive attributes 
Date: Thu, 15 Feb 2001 10:18:09 -0700
Sender: [email-masked]

> I think, is not realistic since it would
> lead to potentially different requirements for
> different attributes.

Yeah, this is my biggest problem with any alternative as 
well.

-danny

From: "Dmitri Krioukov" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: RE: handling unrecognized optional transitive attributes 
Date: Thu, 15 Feb 2001 12:15:47 -0500
Importance: Normal
Sender: [email-masked]

I'd say that the discussion of the AGGREGATOR
example suggests "MUST drop" unless you want
to depend on semantics of a given attribute,
which, I think, is not realistic since it would
lead to potentially different requirements for
different attributes.
--
dima.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Danny
> McPherson
> Sent: Thursday, February 15, 2001 11:15 AM
> To: [email-masked]
> Subject: Re: handling unrecognized optional transitive attributes 
> 
> 
> 
> > So, let's say that out of three routes to be aggregate two
> > routes contain an unrecognized optional transitive attribute.
> > What would you expect happen in this case ?
> 
> Based on the wording I provided a moment ago .. drop it.  If all 
> three contain the unrecognized optional transitive attribute 
> then the attribute MUST (or SHOULD?) be passed along to other 
> BGP peers and the Partial bit set to 1.
> 
> While I agree with you in general, dropping the attribute just 
> doesn't make sense to me if ALL the subsets of a given aggregate
> contain an identical optional transitive attribute. 
> 
> Of course, this model is a bit more complex, especially when one 
> considers what now needs to be done if the value of that one more-
> specific's optional transitive attribute changes (be it in either 
> case) .. as such, I don't have _strong feelings either way.
> 
> -danny
> 

To: [email-masked]
From: Danny McPherson <[email-masked]>
Reply-To: [email-masked]
Subject: Re: handling unrecognized optional transitive attributes 
Date: Thu, 15 Feb 2001 10:03:29 -0700
Sender: [email-masked]

> > While I agree with you in general, dropping the attribute just
> > doesn't make sense to me if ALL the subsets of a given aggregate
> > contain an identical optional transitive attribute.
> 
> What exactly is the probability to receive an IDENTICAL optional
> transitive attribute from ALL subsets? I guess nobody can really answer
> this. But it COULD very well be a rare event (again depending on the
> actual UNRECOGNIZED semantic of the attribute).

OTOH, it could be much greater than one would suspect, as an 
optional transitive attribute doesn't 'just appear', there's going
to be some reasoning as to why, and with that being the case, it's 
likely to appear in other places as well.

> So why adding this complexity to help solving the issue in maybe less
> than 10% of all possible cases?

Because in the 10%, or even 1% of the areas that it arises, mods 
beforehand make things a lot simpler down the road. 

> If there really is an elaborated solution to help deployement of future
> such attributes, why not make it elaborate enough to help in ALL
> possible cases (like "to be defined" generic aggregation rules
> configurable per type code)?

I see, you want an "Optional [transitive] attribute" .. sounds 
familiar.   Then you're back to the same problem of what to do when
it's unrecognized or and/or only present in a subset of the routes
that comprise the aggregate.

The general goal, and presumably, the reason it was asked, was to keep 
things as simple as possible while providing as much flexibility as 
possible.

-danny

Date: Thu, 15 Feb 2001 11:41:10 -0500
From: Xavier Briard <[email-masked]>
Organization: Tenor Networks
To: [email-masked]
Cc: [email-masked]
Subject: Re: handling unrecognized optional transitive attributes
Sender: [email-masked]

> While I agree with you in general, dropping the attribute just
> doesn't make sense to me if ALL the subsets of a given aggregate
> contain an identical optional transitive attribute.

What exactly is the probability to receive an IDENTICAL optional
transitive attribute from ALL subsets? I guess nobody can really answer
this. But it COULD very well be a rare event (again depending on the
actual UNRECOGNIZED semantic of the attribute).

> Of course, this model is a bit more complex, especially when one
> considers what now needs to be done if the value of that one more-
> specific's optional transitive attribute changes (be it in either
> case) .. as such, I don't have _strong feelings either way.

So why adding this complexity to help solving the issue in maybe less
than 10% of all possible cases?

If there really is an elaborated solution to help deployement of future
such attributes, why not make it elaborate enough to help in ALL
possible cases (like "to be defined" generic aggregation rules
configurable per type code)?

my $.02
Xavier

To: [email-masked]
From: Danny McPherson <[email-masked]>
Reply-To: [email-masked]
Subject: Re: handling unrecognized optional transitive attributes 
Date: Thu, 15 Feb 2001 09:15:10 -0700
Sender: [email-masked]

> So, let's say that out of three routes to be aggregate two
> routes contain an unrecognized optional transitive attribute.
> What would you expect happen in this case ?

Based on the wording I provided a moment ago .. drop it.  If all 
three contain the unrecognized optional transitive attribute 
then the attribute MUST (or SHOULD?) be passed along to other 
BGP peers and the Partial bit set to 1.

While I agree with you in general, dropping the attribute just 
doesn't make sense to me if ALL the subsets of a given aggregate
contain an identical optional transitive attribute. 

Of course, this model is a bit more complex, especially when one 
considers what now needs to be done if the value of that one more-
specific's optional transitive attribute changes (be it in either 
case) .. as such, I don't have _strong feelings either way.

-danny

To: Ben Abarbanel <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Re: handling unrecognized optional transitive attributes 
Date: Thu, 15 Feb 2001 07:46:25 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Ben,

>   If we drop the unrecognized optional transitive attribute we dont leave
> the door open
> for adding new features into BGP and thus make phasing new features a pain.
> Can we not drop unknown attributes of all kinds?

Do you have a specific proposal on how to deal with unrecognized
optional transitive attributes when aggregating routes ?

Yakov.

> 
> Ben
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Yakov
> Rekhter
> Sent: Thursday, February 15, 2001 9:51 AM
> To: Ben Abarbanel
> Cc: [email-masked]'
> Subject: Re: handling unrecognized optional transitive attributes 
> 
> 
> Ben,
> 
> > Yakov:
> >   I thought optional transitive means the attribute is passed through
> > without being dropped?
> 
> Yes, that is what you do if you don't aggregate routes. The issue
> I brought up is what to do when you aggregate routes.
> 
> Yakov.
> > 
> > Ben
> > 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On Behalf Of Yakov
> > Rekhter
> > Sent: Wednesday, February 14, 2001 8:57 AM
> > To: [email-masked]
> > Subject: handling unrecognized optional transitive attributes 
> > 
> > 
> > Folks,
> > 
> > The current BGP spec doesn't say anything wrt how a BGP speaker
> > that aggregates several routes should handle optional transitive
> > attributes of these routes if the speaker doesn't recognize the
> > attributes. We should probably need to specify how to handle this.
> > One option would be to require the speaker to drop these attributes.
> > Any other (reasonable) options ?
> > 
> > Yakov.

From: Ben Abarbanel <[email-masked]>
To: "'Yakov Rekhter'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: handling unrecognized optional transitive attributes 
Date: Thu, 15 Feb 2001 10:38:49 -0500
Sender: [email-masked]

Yakov:
  If we drop the unrecognized optional transitive attribute we dont leave
the door open
for adding new features into BGP and thus make phasing new features a pain.
Can we not
drop unknown attributes of all kinds?

Ben

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Yakov
Rekhter
Sent: Thursday, February 15, 2001 9:51 AM
To: Ben Abarbanel
Cc: [email-masked]'
Subject: Re: handling unrecognized optional transitive attributes 

Ben,

> Yakov:
>   I thought optional transitive means the attribute is passed through
> without being dropped?

Yes, that is what you do if you don't aggregate routes. The issue
I brought up is what to do when you aggregate routes.

Yakov.
> 
> Ben
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Yakov
> Rekhter
> Sent: Wednesday, February 14, 2001 8:57 AM
> To: [email-masked]
> Subject: handling unrecognized optional transitive attributes 
> 
> 
> Folks,
> 
> The current BGP spec doesn't say anything wrt how a BGP speaker
> that aggregates several routes should handle optional transitive
> attributes of these routes if the speaker doesn't recognize the
> attributes. We should probably need to specify how to handle this.
> One option would be to require the speaker to drop these attributes.
> Any other (reasonable) options ?
> 
> Yakov.

To: [email-masked]
Cc: [email-masked]
Subject: Re: handling unrecognized optional transitive attributes 
Date: Thu, 15 Feb 2001 07:41:01 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Danny,

> I'm OK with the general idea here, but I don't think 
> dropping the attribute(s) is necessary if ALL the routes
> contain them.
> 
> I'd be more appeased by wording that suggests "unless ALL
> routes within an aggregate contain an unrecognized optional 
> transitive attribute, it MUST be dropped". 
> 
> IMO, this addresses the case sufficiently, but provides
> some amount of flexibility as well.

So, let's say that out of three routes to be aggregate two
routes contain an unrecognized optional transitive attribute.
What would you expect happen in this case ?

Yakov.

> 
> -danny
> 
> > So, how about if we'll insert the following text at the end of
> > 9.2.4.2:
> > 
> >   When a BGP speaker aggregates several routes, and some/all of
> >   these routes contain optional transitive attributes that are not
> >   recognized by the speaker, the speaker MUST drop these attributes
> >   from the aggregate route.
> > 
> > If there are no objections to this before end of next week, I'll
> > add this text to the Internet Draft and re-issue it.
> 
> 

To: [email-masked]
From: Danny McPherson <[email-masked]>
Reply-To: [email-masked]
Subject: Re: handling unrecognized optional transitive attributes 
Date: Thu, 15 Feb 2001 08:33:07 -0700
Sender: [email-masked]

I'm OK with the general idea here, but I don't think 
dropping the attribute(s) is necessary if ALL the routes
contain them.

I'd be more appeased by wording that suggests "unless ALL
routes within an aggregate contain an unrecognized optional 
transitive attribute, it MUST be dropped". 

IMO, this addresses the case sufficiently, but provides
some amount of flexibility as well.

-danny

> So, how about if we'll insert the following text at the end of
> 9.2.4.2:
> 
>   When a BGP speaker aggregates several routes, and some/all of
>   these routes contain optional transitive attributes that are not
>   recognized by the speaker, the speaker MUST drop these attributes
>   from the aggregate route.
> 
> If there are no objections to this before end of next week, I'll
> add this text to the Internet Draft and re-issue it.

To: Enke Chen <[email-masked]>
Cc: [email-masked]
Subject: Re: handling unrecognized optional transitive attributes 
Date: Thu, 15 Feb 2001 06:57:08 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

> > Folks,
> > 
> > The current BGP spec doesn't say anything wrt how a BGP speaker
> > that aggregates several routes should handle optional transitive
> > attributes of these routes if the speaker doesn't recognize the
> > attributes. We should probably need to specify how to handle this.
> 
> > One option would be to require the speaker to drop these attributes.
> 
> This seems to be reasonable. I do not see much benefit (but more
> complexity) in trying to keep the attribute during aggregation.

So, how about if we'll insert the following text at the end of
9.2.4.2:

  When a BGP speaker aggregates several routes, and some/all of
  these routes contain optional transitive attributes that are not
  recognized by the speaker, the speaker MUST drop these attributes
  from the aggregate route.

If there are no objections to this before end of next week, I'll
add this text to the Internet Draft and re-issue it.

Yakov.

Date: Thu, 15 Feb 2001 09:52:54 -0500 (EST)
From: Mark Mentovai <[email-masked]>
To: Xavier Briard <[email-masked]>
Cc: Dmitri Krioukov <[email-masked]>, IDR <[email-masked]>
Subject: Re: handling unrecognized optional transitive attributes
Sender: [email-masked]

Xavier Briard wrote:
>> > How about this: if all of the routes being aggregated contain identical
>> > instances of the unknown optional transitive attribute in
>> > question, the BGP
>> > speaker should include the attribute in the aggregated route, with the
>> > partial bit set, but may instead drop the attribute.
>>
>> Why not a hard choice here?
>
>Like "dropping" as suggested first.
>
>Let's take for example the AGGREGATOR attribute (optional transitive).
>BGP spec says:
>"All AGGREGATOR attributes of all routes to be aggragted should be
>ignored"
>
>Let's now ASSUME a router not recognizing this attribute (allowed by
>nature...). Applying a rule like keeping it if all sources present the
>same value goes against the previous statement.

"Should be ignored."  But the attribute still makes sense, and still applies
somewhat to the new aggregated prefixes, provided the AGGREGATOR attributes
carried with the longer prefixes now being aggregated were identical.  In
this case, the speaker won't be adding a new AGGREGATOR, and others will see
based on the partial bit that the data contained within the attribute isn't
guaranteed to be 100% accurate.  The aggregator listed in the AGGREGATOR
attribute will still be -an- aggregator of the entire prefix, just not -the-
aggregator of the new unified advertisement.

I think it's better to retain the AGGREGATOR attribute in any case,
regardless of the authenticity of the included aggregating AS and speaker,
to inform others that the advertisement is the result of one (or more)
aggregations.

>One could argue in general that depending on the semantic of the
>attribute it may not make sense at all to give a value to the aggregate
>equal to the unique value of all sources (because a router supporting
>this attribute would have computed the sum for example).

This is what the partial bit is about.  If any BGP speaker needs to be
guaranteed that an optional transitive attribute requiring processing by
other BGP speakers is correct, it has to check the partial bit.  In this
case, the partial bit would be set.

The rationale I'm following is that it's better to provide more data than
less data, by setting the partial bit, you can notify other BGP speakers
that the attribute data may not be valid.  Speakers which understand the
attribute will know whether or not to trust data with the partial bit set.
They may choose, for example, to honor a COMMUNITIES attribute even with the
partial bit set, but ignore an attribute that requires a sum to be
recomputed at each step unless the bit is clear.

Why not a hard choice?  Because I don't think one is warranted here - I
recommend providing going the extra mile to provide the data if you desire,
but if that's too much, the attribute can be dropped.  Existing BGP speakers
probably just drop unknown optional transitive attributes on aggregation
anyway, and I don't think it's worth making them noncompliant over a point
as minor as this.  Still, I do see some value in trying to preserve as much
of the initial advertisement as possible.

Doesn't seem to be a very popular opinion, though.  :)

Mark

To: Ben Abarbanel <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Re: handling unrecognized optional transitive attributes 
Date: Thu, 15 Feb 2001 06:50:52 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Ben,

> Yakov:
>   I thought optional transitive means the attribute is passed through
> without being dropped?

Yes, that is what you do if you don't aggregate routes. The issue
I brought up is what to do when you aggregate routes.

Yakov.
> 
> Ben
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Yakov
> Rekhter
> Sent: Wednesday, February 14, 2001 8:57 AM
> To: [email-masked]
> Subject: handling unrecognized optional transitive attributes 
> 
> 
> Folks,
> 
> The current BGP spec doesn't say anything wrt how a BGP speaker
> that aggregates several routes should handle optional transitive
> attributes of these routes if the speaker doesn't recognize the
> attributes. We should probably need to specify how to handle this.
> One option would be to require the speaker to drop these attributes.
> Any other (reasonable) options ?
> 
> Yakov.

To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: Re: handling unrecognized optional transitive attributes 
Date: Wed, 14 Feb 2001 12:21:00 -0800
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Yakov,

> Message-Id: <[email-masked]>
> To: [email-masked]
> Subject: handling unrecognized optional transitive attributes 
> MIME-Version: 1.0
> Content-Type: text/plain; charset="us-ascii"
> Content-ID: <[email-masked]>
> Date: Wed, 14 Feb 2001 05:56:40 -0800
> From: Yakov Rekhter <[email-masked]>
> Sender: [email-masked]
> Precedence: bulk
> 
> Folks,
> 
> The current BGP spec doesn't say anything wrt how a BGP speaker
> that aggregates several routes should handle optional transitive
> attributes of these routes if the speaker doesn't recognize the
> attributes. We should probably need to specify how to handle this.

> One option would be to require the speaker to drop these attributes.

This seems to be reasonable. I do not see much benefit (but more
complexity) in trying to keep the attribute during aggregation.

-- Enke

> Any other (reasonable) options ?
> 
> Yakov.
> 

Date: Wed, 14 Feb 2001 14:54:28 -0500
From: Xavier Briard <[email-masked]>
Organization: Tenor Networks
To: Dmitri Krioukov <[email-masked]>
Cc: Mark Mentovai <[email-masked]>, IDR <[email-masked]>
Subject: Re: handling unrecognized optional transitive attributes
Sender: [email-masked]

> > How about this: if all of the routes being aggregated contain identical
> > instances of the unknown optional transitive attribute in
> > question, the BGP
> > speaker should include the attribute in the aggregated route, with the
> > partial bit set, but may instead drop the attribute.
> 
> Why not a hard choice here?

Like "dropping" as suggested first.

Let's take for example the AGGREGATOR attribute (optional transitive).
BGP spec says:
"All AGGREGATOR attributes of all routes to be aggragted should be
ignored"

Let's now ASSUME a router not recognizing this attribute (allowed by
nature...). Applying a rule like keeping it if all sources present the
same value goes against the previous statement.

One could argue in general that depending on the semantic of the
attribute it may not make sense at all to give a value to the aggregate
equal to the unique value of all sources (because a router supporting
this attribute would have computed the sum for example).

Xavier

From: "Dmitri Krioukov" <[email-masked]>
To: "Mark Mentovai" <[email-masked]>
Cc: "IDR" <[email-masked]>
Subject: RE: handling unrecognized optional transitive attributes 
Date: Wed, 14 Feb 2001 14:01:30 -0500
Importance: Normal
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Mark
> Mentovai
> Sent: Wednesday, February 14, 2001 10:49 AM
> To: Yakov Rekhter
> Cc: IDR
> Subject: Re: handling unrecognized optional transitive attributes
>
>
> Yakov Rekhter wrote:
> >The current BGP spec doesn't say anything wrt how a BGP speaker
> >that aggregates several routes should handle optional transitive
> >attributes of these routes if the speaker doesn't recognize the
> >attributes. We should probably need to specify how to handle this.
> >One option would be to require the speaker to drop these attributes.
> >Any other (reasonable) options ?
>
> How about this: if all of the routes being aggregated contain identical
> instances of the unknown optional transitive attribute in
> question, the BGP
> speaker should include the attribute in the aggregated route, with the
> partial bit set, but may instead drop the attribute.

Why not a hard choice here?

> If the routes being
> aggregated don't all contain identical instances of the unknown attribute,
> the attribute must not be included in the aggregated route.
>
> Does that sound sane?  Sound like it'll break anything?
>
> Mark
--
dima.

To: [email-masked]
Cc: "IDR" <[email-masked]>, [email-masked]
Subject: Re: graceful restart question 
Date: Wed, 14 Feb 2001 10:54:04 -0800
From: Enke Chen <[email-masked]>
Sender: [email-masked]

> Reply-To: <[email-masked]>
> From: "James Tsillas" <[email-masked]>
> To: "IDR" <[email-masked]>
> Subject: graceful restart question
> Date: Wed, 14 Feb 2001 13:37:16 -0500
> Message-ID: <[email-masked]>
> 
> If the receiving speaker detected a TCP reset but the
> received capability turns out not to have the restart flag
> set (but did have the forwarding state bit set for some
> AFs) is it correct for the receiving speaker to flush
> stale routing information before the end-of-RIB is received?

No.

> Is the restart flag only considered by restarting speakers
> to avoid deadlock or can it be used as an indication of
> whether a given peer has really restarted?

See the text in Sect 5. Graceful Restart Capability:

     When set (value 1), this bit indicates
     that the BGP speaker has restarted, and its peer should not wait
     for the End-of-RIB marker from the speaker before advertising
     routing information to the speaker.

> 
> The draft does state that a lack of the forwarding state
> bit for an AF or the lack of the capability for an AF will cause
> stale routes to be flushed. No mention of the lack of the
> restart state bit or the lack of the graceful restart
> capability.

Isn't obvious that "lack of the graceful restart capbility"
implies "lack of the capability for an AF" (actually for all
AFs)?

-- Enke

Reply-To: <[email-masked]>
From: "James Tsillas" <[email-masked]>
To: "IDR" <[email-masked]>
Subject: graceful restart question
Date: Wed, 14 Feb 2001 13:37:16 -0500
Importance: Normal
Sender: [email-masked]

If the receiving speaker detected a TCP reset but the
received capability turns out not to have the restart flag
set (but did have the forwarding state bit set for some
AFs) is it correct for the receiving speaker to flush
stale routing information before the end-of-RIB is received?
Is the restart flag only considered by restarting speakers
to avoid deadlock or can it be used as an indication of
whether a given peer has really restarted?

The draft does state that a lack of the forwarding state
bit for an AF or the lack of the capability for an AF will cause
stale routes to be flushed. No mention of the lack of the
restart state bit or the lack of the graceful restart
capability.

Date: Wed, 14 Feb 2001 11:52:44 -0500 (EST)
From: Mark Mentovai <[email-masked]>
To: Bruno Rijsman <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, IDR <[email-masked]>
Subject: RE: handling unrecognized optional transitive attributes 
Sender: [email-masked]

Bruno Rijsman wrote:
>I don't think that is safe in all cases. Consider for example aggregation
>of the MP-REACH-NLRI attribute on a router which supports aggregation but
>does not (yet) support the multi-protocol extensions: we don't want the
>aggregate to copy the (unrecognized) MP-REACH-NLRI attribute of any
>covered routes because that would implicitly withdraw the NLRI included in
>the MP-REACH-NLRI of the covered route themselves (assuming the covered
>routes are not suppressed due to the aggregate being summary-only).

MP_REACH_NLRI is non-transitive.  If you don't understand the attribute but
copy it anyway, you're in violation of the spec, and have bigger problems
than your behavior during aggregation.

Mark

Date: Wed, 14 Feb 2001 10:49:09 -0500 (EST)
From: Mark Mentovai <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: IDR <[email-masked]>
Subject: Re: handling unrecognized optional transitive attributes 
Sender: [email-masked]

Yakov Rekhter wrote:
>The current BGP spec doesn't say anything wrt how a BGP speaker
>that aggregates several routes should handle optional transitive
>attributes of these routes if the speaker doesn't recognize the
>attributes. We should probably need to specify how to handle this.
>One option would be to require the speaker to drop these attributes.
>Any other (reasonable) options ?

How about this: if all of the routes being aggregated contain identical
instances of the unknown optional transitive attribute in question, the BGP
speaker should include the attribute in the aggregated route, with the
partial bit set, but may instead drop the attribute.  If the routes being
aggregated don't all contain identical instances of the unknown attribute,
the attribute must not be included in the aggregated route.

Does that sound sane?  Sound like it'll break anything?

Mark

From: Ben Abarbanel <[email-masked]>
To: "'Yakov Rekhter'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: handling unrecognized optional transitive attributes 
Date: Wed, 14 Feb 2001 09:48:13 -0500
Sender: [email-masked]

Yakov:
  I thought optional transitive means the attribute is passed through
without being 
dropped?

Ben

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Yakov
Rekhter
Sent: Wednesday, February 14, 2001 8:57 AM
To: [email-masked]
Subject: handling unrecognized optional transitive attributes 

Folks,

The current BGP spec doesn't say anything wrt how a BGP speaker
that aggregates several routes should handle optional transitive
attributes of these routes if the speaker doesn't recognize the
attributes. We should probably need to specify how to handle this.
One option would be to require the speaker to drop these attributes.
Any other (reasonable) options ?

Yakov.

To: [email-masked]
Subject: handling unrecognized optional transitive attributes 
Date: Wed, 14 Feb 2001 05:56:40 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

The current BGP spec doesn't say anything wrt how a BGP speaker
that aggregates several routes should handle optional transitive
attributes of these routes if the speaker doesn't recognize the
attributes. We should probably need to specify how to handle this.
One option would be to require the speaker to drop these attributes.
Any other (reasonable) options ?

Yakov.

Reply-To: "Srinivasa Chaganti" <[email-masked]>
From: "Srinivasa Chaganti" <[email-masked]>
To: <[email-masked]>, "Yakov Rekhter" <[email-masked]>
Subject: Re: 4 bytes ASs
Date: Thu, 8 Feb 2001 08:30:10 -0800
Organization: Pluris
Sender: [email-masked]

Hi,
I have some suggestions on avoiding conversions between 2 bytes AS numbers
and 4 bytes AS numbers until 4 bytes AS numbers are really in use. We can
avoid this conversion process by defining another optional attribute
(ASP_TYPE) which tells whether the numbers in as-path are in 2 bytes format
or in 4 bytes format. When NEW_BGP_SPEAKER is sending a path  to another
NEW_BGP_SPEAKER if the path is already in 2 bytes format sending side just
needs to add ASP_TYPE attribute to tell the peer that the AS numbers in the
path are in 2 bytes format. On the receiving side NEW_BGP_SPEAKER interprets
the AS numbers based on whether ASP_TYPE attribute is present or not. This
also helps in avoiding conversion process on NEW_BGP_SPEAKERs when sending 2
bytes value AS numbers from 4 bytes before sending to OLD_BGP_SPEAKERs. This
procedure saves memory, CPU, and bandwidth until that time when 4 bytes AS
numbers are really in use. Once every path in the network contain at least
one 4 bytes AS number in them, that time we can get rid of using ASP_TYPE
attribute.

any comments??

S. Chaganti

----- Original Message -----
From: "Yakov Rekhter" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, January 31, 2001 6:47 AM
Subject: 4 bytes ASs

> Folks,
>
> As we agreed at the last WG meeting, here is the document.
>
> Yakov.
> ------- Forwarded Message
>
> Date:    Wed, 31 Jan 2001 07:15:13 -0500
> From:    [email-masked]
> To:      IETF-Announce: ;
> cc:      [email-masked]
> Subject: I-D ACTION:draft-ietf-idr-as4bytes-00.txt
>
> - --NextPart
>
> 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 : BGP support for four-octet AS number space
> Author(s) : Q. Vohra, E. Chen
> Filename : draft-ietf-idr-as4bytes-00.txt
> Pages : 7
> Date : 30-Jan-01
>
> Currently the Autonomous System number is encoded in BGP as a two-
> octets field. This document describes extensions to BGP to carry the
> Autonomous System number as a four-octets field.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-idr-as4bytes-00.txt
>
> Internet-Drafts are also available by anonymous FTP. Login with the
username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-ietf-idr-as4bytes-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> [email-masked].
> In the body type:
> "FILE /internet-drafts/draft-ietf-idr-as4bytes-00.txt".
>
> NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility.  To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command.  To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader.  Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
> - --NextPart
> Content-Type: Multipart/Alternative; Boundary="OtherAccess"
>
> - --OtherAccess
> Content-Type: Message/External-body;
> access-type="mail-server";
> server="[email-masked]"
>
> Content-Type: text/plain
> Content-ID: <[email-masked]>
>
> ENCODING mime
> FILE /internet-drafts/draft-ietf-idr-as4bytes-00.txt
>
> - --OtherAccess
> Content-Type: Message/External-body;
> name="draft-ietf-idr-as4bytes-00.txt";
> site="ftp.ietf.org";
> access-type="anon-ftp";
> directory="internet-drafts"
>
> Content-Type: text/plain
> Content-ID: <[email-masked]>
>
> - --OtherAccess--
>
> - --NextPart--
>
>
>
> ------- End of Forwarded Message
>

Reply-To: "Srinivasa Chaganti" <[email-masked]>
From: "Srinivasa Chaganti" <[email-masked]>
To: <[email-masked]>
Subject: Re: Query in Route Refresh Capability
Date: Thu, 8 Feb 2001 08:00:48 -0800
Organization: Pluris
Sender: [email-masked]

With route refresh capability, you still need to keep all the feasible
routes locally after applying inbound policies (routes which are not
filtered out by inbound policies) for each neighbor, though some of them are
non best routes. When BGP speaker receives withdrawn message for a route it
finds next best route among feasible routes received from other peers. With
route refresh capability, you need not maintain received routes (i.e.,
before applying inbound policies) in the local system as you can get them
from neighbor by route-refresh request as and when needed.

S. Chaganti
----- Original Message -----
From: "Venu V." <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, February 07, 2001 11:42 PM
Subject: Query in Route Refresh Capability

>
> The Route Refresh Capability RFC 2918, suggests a way for sending
> ROUTE-REFRESH messages so that the peer can send its Adj_RIB_Out table.
This
> helps the BGP speaker to avoid keeping Adj_RIB_In tables.
>
> But how are Withdrawn messages handled in this context, in the absence of
> Adj_RIB_In?
>
> When a BGP speaker receives Withdrawn message, it needs to find the next
> feasible/replacement route to that prefix. If it does not maintain the
> Adj_RIBs_In, from where does it gets the information.
>
>
> Thanks in Advance,
> Venu
>

From: "Venu V." <[email-masked]>
To: [email-masked]
Subject: Query in Route Refresh Capability
Date: Thu, 8 Feb 2001 02:42:52 -0500 
Sender: [email-masked]

The Route Refresh Capability RFC 2918, suggests a way for sending
ROUTE-REFRESH messages so that the peer can send its Adj_RIB_Out table. This
helps the BGP speaker to avoid keeping Adj_RIB_In tables.

But how are Withdrawn messages handled in this context, in the absence of
Adj_RIB_In? 

When a BGP speaker receives Withdrawn message, it needs to find the next
feasible/replacement route to that prefix. If it does not maintain the
Adj_RIBs_In, from where does it gets the information.

Thanks in Advance,
Venu

To: [email-masked]
Cc: "IDR" <[email-masked]>, [email-masked]
Subject: Re: Graceful Restart: end-of-RIB marker per address-family? 
Date: Wed, 07 Feb 2001 11:20:55 -0800
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Hi, Jim:
See the following text from Section 6 (Operation):

-----
   The End-of-RIB marker should be sent by a BGP speaker to its peer
   once it completes the initial routing update (including the case when
   there is no update to send) for an address family after the BGP
   session is established.
-----

The End-of-RIB marker is defined and used on a per address family basis.

-- Enke

> From: "James Tsillas" <[email-masked]>
> To: "IDR" <[email-masked]>
> Subject: Graceful Restart: end-of-RIB marker per address-family?
> Date: Wed, 7 Feb 2001 13:48:37 -0500
> Message-ID: <[email-masked]>
> MIME-Version: 1.0
> 
> The draft (Graceful Restart Mechanism for BGP) doesn't
> explicitly state if it is required that and end-of-RIB
> (EOR) marker be sent (and received) per address-family
> (AF), although it does indicate how the EOR is defined
> for IPv4 and for MP-BGP.
> 
> Is one to assume that EOR is sent per AF?
> 
> Can a restarting speaker restart the AFs indepently, if
> each AF would have its own EOR?
> 
> thanks,
> -Jim.
> 

Reply-To: <[email-masked]>
From: "James Tsillas" <[email-masked]>
To: "IDR" <[email-masked]>
Subject: Graceful Restart: end-of-RIB marker per address-family?
Date: Wed, 7 Feb 2001 13:48:37 -0500
Importance: Normal
Sender: [email-masked]

The draft (Graceful Restart Mechanism for BGP) doesn't
explicitly state if it is required that and end-of-RIB
(EOR) marker be sent (and received) per address-family
(AF), although it does indicate how the EOR is defined
for IPv4 and for MP-BGP.

Is one to assume that EOR is sent per AF?

Can a restarting speaker restart the AFs indepently, if
each AF would have its own EOR?

thanks,
-Jim.