Subject: [Idr] Fw: Old transport-layer protocols to Historic?

From: "t.petch" <[email-masked]>
Date: Fri, 7 Jan 2011 18:33:18 +0100

Warren

A propos draft-ietf-idr-deprecate-as-sets-00

Deprecate seems to be getting quite an airing at present - there
is a netconf implementor who is questioning it as well - but I am with
Adrian, that what we have works, and is well enough defined and 
understood.

Tom Petch

----- Original Message ----- 
From: "Andrew Sullivan" <[email-masked]>
To: <[email-masked]>
Sent: Friday, January 07, 2011 3:15 PM
Subject: Re: Old transport-layer protocols to Historic?

> I'm not keen to start a language war, but. . .
> 
> On Fri, Jan 07, 2011 at 08:39:37AM +0200, Mykyta Yevstifeyev wrote:
> 
> > Moreover, 'obsoleted' means the same as 'deprecated' or 'non-current'  
> > (see http://www.synonym.com/synonyms/obsolete/ or  
> > http://dictionary.sensagent.com/obsolete/en-en/#synonyms). So it is a  
> > problem in RFC2026.
> 
> . . .I fully disagree with that, regardless of what those claims of
> synonymy say.  To deprecate something is to express disapproval.  To
> mark something as obsolete doesn't do that; it merely says that the
> marked thing is outdated.  There is a useful distinction here worth
> maintaining.
> 
> A
> 
> -- 
> Andrew Sullivan
> [email-masked]
> Shinkuro, Inc.
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Jakob Heitz <[email-masked]>
Date: Fri, 7 Jan 2011 13:58:27 -0500

"deprecate" is too wussy. It does nothing.
We need a recommendation of what to do when we receive one.
Suggestions:
1. Replace the AS-SET with the AS number of the sending speaker
2. Replace the AS-SET with a special ASN that means "there was an AS-SET here"
3. drop the AS-SET
4. drop the route

I don't like 3 and 4.
The recommended action could be knobbed (optional).

--
Jakob Heitz.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of t.petch
> Sent: Friday, January 07, 2011 9:33 AM
> To: [email-masked]
> Cc: idr
> Subject: [Idr] Fw: Old transport-layer protocols to Historic?
> 
> Warren
> 
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: Ilya Varlashkin <[email-masked]>
Date: Fri, 7 Jan 2011 20:44:49 +0100

Jakob,

very valid points. Please see comments below.

> 1. Replace the AS-SET with the AS number of the sending speaker

what if AS-SET is not the last element of the AS-PATH? e.g. an announcement went through some routers which don't yet know that AS-SET has been depricated? doesn't sound like a good idea

> 2. Replace the AS-SET with a special ASN that means "there was an AS-SET here"

this appeals to me as the best possible solution. While removing AS-SET we should probably also remove AGGREGATOR and ATOMIC_AGGREGATE. IANA section should be updated then and we need early allocation ASAP.

> I don't like 3 and 4.

me neither

> The recommended action could be knobbed (optional).
and what to do by default?

Kind regards,
iLya

---

From: Jakob Heitz <[email-masked]>
Date: Mon, 10 Jan 2011 07:34:44 -0500

For option 1, if AS-SET is not the last element, replace it
with the adjacent AS number, the AS number of the AS that
created the AS-SET.

Anyway, I also like option 2 the best. (I proposed it on 9/21).
Reserve a number. It conveys the most information.

Default action is normally to retain old behaviour.
Adoption of new behaviour should be a concious decision,
in case side effects need to be fixed.
If there will be no side effects to fix, then the default could
be the new behaviour.

--
Jakob Heitz.

> From: Ilya Varlashkin [mailto:[email-masked]] 
> Sent: Friday, January 07, 2011 11:45 AM
> To: Jakob Heitz
> Cc: t.petch; [email-masked]; idr
> Subject: Re: [Idr] Fw: Old transport-layer protocols to Historic?
> 
> Jakob,
> 
> what if AS-SET is not the last element of the AS-PATH? e.g. 
> an announcement went through some routers which don't yet 
> know that AS-SET has been depricated? doesn't sound like a good idea
> 
> this appeals to me as the best possible solution. While 
> removing AS-SET we should probably also remove AGGREGATOR and 
> ATOMIC_AGGREGATE. IANA section should be updated then and we 
> need early allocation ASAP.
> 
> > 3. drop the AS-SET
> > 4. drop the route
> > 
> > I don't like 3 and 4.
> 
> me neither
>

---

From: "t.petch" <[email-masked]>
Date: Mon, 10 Jan 2011 15:43:02 +0100

----- Original Message -----
From: "Jakob Heitz" <[email-masked]>
To: "t.petch" <[email-masked]>; <[email-masked]>
Cc: "idr" <[email-masked]>
Sent: Friday, January 07, 2011 7:58 PM

<tp>

Agree which is why I am pressing for the total removal of section three and will
go on pressing for as long as it takes.

It is totally, utterly and  completely wrong to attempt to redefine deprecate.

We need precise specific actions, such as

Do not generate any new AS_SET
Get rid of those that exist as soon as practicable.

I do not think that we should come up with processing different to RFC4271 at
this stage, I think that that comes later when the above has been approved.

Tom Petch
</tp>

I don't like 3 and 4.

--
Jakob Heitz.

> =

---

From: Paul Jakma <[email-masked]>
Date: Sun, 16 Jan 2011 12:24:51 +0000 (GMT)

> 2. Replace the AS-SET with a special ASN that means "there was an AS-SET here"

Why do any of these? What is the practical good in this, other than 
satisfying some internal dislike of AS_SETs?

If AS_SETs interfere with some other new extension to BGP, let that 
extension mandate what to do. BGP speakers will vote with their 
firmware updates, according to the utility of AS_SETs (or lack of) 
versus that new extension.

Let economics and natural progress decide, not artificial prescript 
to break people's routing.

regards,
-- 
Paul Jakma	[email-masked]	@pjakma	Key ID: 64A2FF6A
Fortune:
If it's worth hacking on well, it's worth hacking on for money.

---

From: Tony Li <[email-masked]>
Date: Sun, 16 Jan 2011 10:33:48 -0800

On Jan 16, 2011, at 4:24 AM, Paul Jakma wrote:

> Let economics and natural progress decide, not artificial prescript to break people's routing.

+1

It seems to me that 'deprecate' suffices.  This convince others to stop adding more AS_SETs.  Since we can't reasonably remove the uses that are in the field, this is the best thing that we can do.

Tony

---

From: Paul Jakma <[email-masked]>
Date: Tue, 18 Jan 2011 09:39:03 +0000 (GMT)

On Sun, 16 Jan 2011, Tony Li wrote:

> stop adding more AS_SETs.  Since we can't reasonably remove the 
> uses that are in the field, this is the best thing that we can do.

Also, AS_SET may still be useful in the future to allow future 
routing schemes to provide a transitional compatibility-interface to 
(then) legacy BGP-4 speakers. E.g. hierarchical routing schemes.

regards,
-- 
Paul Jakma	[email-masked]	@pjakma	Key ID: 64A2FF6A
Fortune:
Misfortune, n.:
 	The kind of fortune that never misses.
 		-- Ambrose Bierce, "The Devil's Dictionary"

---

From: Ilya Varlashkin <[email-masked]>
Date: Tue, 18 Jan 2011 20:45:02 +0100

On Jan 18, 2011, at 10:39 , Paul Jakma wrote:

>> stop adding more AS_SETs.  Since we can't reasonably remove the uses that are in the field, this is the best thing that we can do.
> 
> Also, AS_SET may still be useful in the future to allow future routing schemes to provide a transitional compatibility-interface to (then) legacy BGP-4 speakers. E.g. hierarchical routing schemes.
> 

isn't current discussion exactly about how to interact with legacy BGP speakers? if our idea is to move towards verified (signed) routes, which do not support AS_SET then I believe it's appropriate to discuss what to do with existing AS_SETs that eventually will reach a router that wants to use route verification. And since it's important to fit new functionality into BGP best path selection process, then options suggested by Jakob are possible ways to go.

As regards to whether AS_SETs will find use in the future. If they haven't found much use in the past, then either problem was not very severe one or AS_SETs were wrong solution. And keeping them as a solution for a problem we haven't yet found doesn't seem to be proper. Somewhere in the beginning of this thread there was a post regarding presence of AS_SETs in the current global table and it looked like AS_SET's can go. So we're back to the question what new BGP speakers should do when they encounter AS_SET.

Kind regards,
iLya

---

From: John Leslie <[email-masked]>
Date: Tue, 18 Jan 2011 16:27:22 -0500

Ilya Varlashkin <[email-masked]> wrote:
>>> stop adding more AS_SETs. Since we can't reasonably remove the uses
>>> that are in the field, this is the best thing that we can do.
>> 
>> Also, AS_SET may still be useful in the future to allow future routing
>> schemes to provide a transitional compatibility-interface to (then)
>> legacy BGP-4 speakers. E.g. hierarchical routing schemes.

   Hierarchical Routing is considered essential to IPv6 -- we just keep
claiming it will "happen automatically". I wouldn't mind keeping some
options alive...

> isn't current discussion exactly about how to interact with legacy
> BGP speakers?

   I'm not sure I understand where everyone is coming from...

   Clearly we're having a discussion about what to do when we receive
NLRI containing AS_SET and want to be sure we don't propagate anything
with AS_SET. This is a good discussion; but not everybody worries about
whether they propagate an AS_SET.

> if our idea is to move towards verified (signed) routes, which do not
> support AS_SET then I believe it's appropriate to discuss what to do
> with existing AS_SETs that eventually will reach a router that wants
> to use route verification.

   With that "eventually" in there, I don't think I want to do anything.
Perhaps if I were signing something, I would, but most of us operators
aren't worrying about "signing", just worrying about "verifying".

> And since it's important to fit new functionality into BGP best path
> selection process, then options suggested by Jakob are possible ways
> to go.

   Hmm... I really should bite my tongue instead of saying this...

   BGP, IMHO, has suffered long from defining algorithms instead of
defining meaning of bits on the wire.

   That horse has long left the barn: not all BGP speakers use exactly
the same algorithms. :^(

   IMHO, verification is doomed unless we define _meaning_ rather than
pretend everyone's running identical best-path-selection algorithms.

> As regards to whether AS_SETs will find use in the future. If they
> haven't found much use in the past, then either problem was not very
> severe one or AS_SETs were wrong solution.

   This is a relatively convincing argument; but I'm not certain that
the problems we encounter next year will be the same problems we faced
ten years ago. (In particular, hierarchical routing is a new animal.)

> And keeping them as a solution for a problem we haven't yet found
> doesn't seem to be proper.

   "Deprecate", to me, pretty much excludes "keeping them as a solution."

> Somewhere in the beginning of this thread there was a post regarding
> presence of AS_SETs in the current global table and it looked like
> AS_SET's can go.

   Indeed, it looks as if signing/verifying can safely exclude them.

> So we're back to the question what new BGP speakers should do when
> they encounter AS_SET.

   What means "new BGP speakers"? Terms like that make me nervous...
(I gag whenever the phrase "Flag Day" threatens to surface...)

--
John Leslie <[email-masked]>

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 19 Jan 2011 16:11:23 +0000

> pretend everyone's running identical best-path-selection algorithms.

If people weren't running compatible enough best path selection, their
networks would be doomed to inconsistent forwarding.  It's the very fact
that consistent route selection is needed throughout an AS that's kept
intra-AS features in a certain level of stalemate over the years.

The same is true to a lesser extent in inter-domain BGP.  Incremental
deployment of a feature requires consistent enough routing between ASes that
use a feature in order to not introduce routing inconsistencies on an
inter-AS basis.

Lest we spend too much time arguing about this, you might want to go back
and review any given new feature du jour and note where it was killed by the
incremental deployment issue. :-)

FWIW, I have pretty much always been of the opinion that BGP is all about
*policy*.  At best, you get default useful route selection from the base
path selection mechanism.  To get something operationally useful, you spend
most of your time tweaking policies.  If you're lucky, those policies do
something useful.

Also FWIW, with regard to SIDR style route validation, it should just leave
AS_SET alone if it wants to.  I made the observation on the SIDR list and at
the Maastricht IETF that if we want *origin* validation to work, we can
still accommodate that with the documented hack presented at that IETF *or*
through the use of complex aggregation should sets prove to be necessary.

Thus if you care about origin validation, you can just ignore that
reachability.  Providers sending you those routes would not care if you send
them that traffic anyway.  If they did, they wouldn't use sets.  Problem
solved - people voted with their route selection as they always do.

For *path* validation, sets are doomed from the start.  

> ten years ago. (In particular, hierarchical routing is a new animal.)

Also a non-issue if you consider the AS4 space.  In cases where you need a
set of providers to be represented as an aggregate forwarding entity, just
assign a given equivalence class set of such providers a new ASN from the
AS4 space.  The feature roughly looks like confederations.  Protocol problem
solved - implementation spec, not so much. :-)

(And the implementation would probably look like an AS_SET or the
confederation version of the same.  Much like when confederations go to
advertise their confed ASes, the set is stripped and replaced by the
equivalence class ASN.  Within this super-confederation, validation isn't
done on the local components.)

-- Jeff

---

From: Paul Jakma <[email-masked]>
Date: Fri, 21 Jan 2011 09:50:07 +0000 (GMT)

On Tue, 18 Jan 2011, Ilya Varlashkin wrote:

> haven't found much use in the past, then either problem was not 
> very severe one or AS_SETs were wrong solution.

There are two aspects here:

1. Generation of AS_SETs.

Deprecating AS_SETS to as to discourage generation is grand, as 
aggregation has proven impractical in the current scheme of things 
and is generally little used. Plus it simplifies SIDR, which is 
trying to find a way to secure the current scheme of things.

2. Comprehension of AS_SETs

This, I argue, should be retained.

Retaining comprehension need not undermine extensions to BGP that do 
not wish to support AS_SETs - those extensions will need to specify 
what to do for AS_SETs anyway, for the foreseeable future (e.g. drop 
the UPDATE, whatever). If speakers want to run those extensions and 
ignore AS_SETs as part of that, that's perfectly fine.

Retaining comprehension may be useful in the future. AS_SETs remain 
the only way to communicate "the path goes through these ASes" in BGP 
without affecting the routing metric. This is, completely independent 
of BGP aggregation, a potentially useful comprehension ability to 
retain in BGP speakers. For one day we may wish to interface some new 
routing scheme (potentially quite different from BGP, or an extension 
of it) with older routers in some transition period.

I.e. the ability for BGP speakers to disable extensions and return to 
understanding some universal base language for exchanging routing 
information is important. It's an important feature for 
compatibility, which is important to allow incremental progress.

Lobotomising speakers and reducing or, worse, risking the fragmention 
of that base, universal language they collectively understand could 
bite us in the future, is my worry.

regards,
-- 
Paul Jakma	[email-masked]	@pjakma	Key ID: 64A2FF6A
Fortune:
 	"Have you lived here all your life?"
 	"Oh, twice that long."