Subject: [Idr] WG Last Call on draft-ietf-idr-as4bytes-11.txt

From: Yakov Rekhter <[email-masked]>
Date: Fri, 07 Oct 2005 09:41:41 -0700

Folks,

This is to start the WG Last Call on advancing draft-ietf-idr-as4bytes-11.txt
to a Proposed Standard. The implementation report is
draft-huston-idr-as4bytes-survey-00.txt.

The Last Call ends Oct 21, 2005.

Yakov.

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

---

From: Geoff Huston <[email-masked]>
Date: Sat, 08 Oct 2005 15:16:42 +1000

I am happy to see this draft advance.

   Geoff

---

From: Tony Tauber <[email-masked]>
Date: Sun, 9 Oct 2005 13:25:42 -0700 (PDT)

> I am happy to see this draft advance.

Me as well.

Would be nice if the implementation list were a tad longer...

Router vendors?  Code maintainers?

Tony

---

From: Tony Li <[email-masked]>
Date: Sun, 9 Oct 2005 13:48:21 -0700

> Router vendors?  Code maintainers?

Customers?

Tony

---

From: Paul Jakma <[email-masked]>
Date: Mon, 10 Oct 2005 02:15:06 +0100 (IST)

On Fri, 7 Oct 2005, Yakov Rekhter wrote:

> Folks,
>
> This is to start the WG Last Call on advancing 
> draft-ietf-idr-as4bytes-11.txt to a Proposed Standard. The 
> implementation report is draft-huston-idr-as4bytes-survey-00.txt.

1. Surely the questions raised in the implementation report should
    first be at least examined, if not addressed? (concerns 5.2.3 at
    least, see 3.).

2. Section 5.3 should be deleted, I'm not sure how this draft could
    ever mandate behaviour for OLD speakers, when OLD specifically is
    defined to be those peers which do not implemented the extensions
    defined in the draft. ;)

3. NEW_AS_PATH parsing/actions are barely specified.

Eg:

    NEW       NEW       NEW      OLD       OLD     NEW
    AS256---AS200000---AS512---AS1024---AS2048---AS4096

According to 5.2.2, AS512 should create an AS_PATH attribute for 
AS1024 that preserves the path-length by representing each 4-byte ASN 
with AS_TRANS, and should construct NEW_AS_PATH as per AS_PATH (the 
AS_PATH as received previously presumably). So AS1024 would receive:

AS_PATH:	seq(512,AS_TRANS,256)
NEW_AS_PATH:	seq(200000,256)

AS4096 would receive:

AS_PATH:	seq(2048,1024,512,AS_TRANS,256)
NEW_AS_PATH:	seq(200000,256)

5.2.3 states that:

"<leading part of AS_PATH information> should be prepended to the 
NEW_AS_PATH attribute to construct the exact AS path information."

Where "leading part" are those ASN that are only 2-byte and OLD. But 
we're not told how one should deduce where this leading part 
finishes. The simplistic approach of "closest AS_TRANS marks end of 
leading part", which is suggested by definition of "leading part" 
would give us:

 	seq(2048,1024,512,200000,256)

Which is the correct result, however the method is wrong. Imagine if 
the 200000 and 256 are the other way around:

AS_PATH:	seq(2048,1024,512,256,AS_TRANS)
NEW_AS_PATH:	seq(256,200000)

Using previous method would give:

 	seq(2048,1024,512,256,256,200000)

Which result is wrong :). Obviously, one should use the n #-of-ASNs 
in the *NEW_AS_PATH* as the *trailing* part of the real AS_PATH 
information and override the last n ASNs in the AS_PATH. So why 
doesn't the draft state this? ;)

I.e. The full process should preferably be *documented* in the draft, 
but at a minimum this vague (if not slightly misleading) 'prepend 
leading part of AS_PATH' language should be removed.

Also, if a process to reconcile AS_PATH and NEW_AS_PATH is to be 
described (I think it should ;) ), obvious questions arise, as 
one responder to the implementation report hints at:

   a) Should/Must the "overriden" ASNs in the AS_PATH be reconciled
      against the NEW_AS_PATH ASNs which are replacing them?

   b) If so, what if they can /not/ be reconciled?

4. Some mention, surely, could be made of the issues protocol
    decoders will face, and of the ASN allocation strategy which could
    help remove this issue? (It has a cost of one additional reserved
    2-byte ASN).

5. 5.2.3 contains the following statement:

"<the NEW_AS_PATH> attribute may not have been updated since the 
route left the last NEW BGP speaker."

Which raises the question of how exactly any speaker besides a NEW 
(or NEW-compatible) speaker would modify NEW_AS_PATH? Indeed, 
NEW_AS_PATH can /not/ propogate across NEW speakers. The last speaker 
to have "modified" NEW_AS_PATH is, by the language of the draft, the 
NEW speaker which formed it which must therefore be the last NEW 
speaker. So the "may not" should read "will not" instead.

> Yakov.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Thank goodness modern convenience is a thing of the remote future.
 		-- Pogo, by Walt Kelly

---

From: vijay gill <[email-masked]>
Date: Sun, 09 Oct 2005 23:08:47 -0400

>> Router vendors?  Code maintainers?

Make it so!

Though I'm sure I missed where we couldn't make it 128 bytes and call it 
done.

/vijay

---

From: Tony Li <[email-masked]>
Date: Mon, 10 Oct 2005 00:43:45 -0700

>>> Router vendors?  Code maintainers?

I should have been somewhat less obtuse.

In the interests of being crystal clear and perhaps educating a few  
newcomers and some folks who are otherwise not directly involved in  
the sales process....

In the last 15 years, the dynamic between network equipment customers  
and vendors has changed.  In Ye Olden Days, we all sat together and  
then those of us who coded went off and did things and then those of  
us who ran things tested it and we iterated.  And all saw that it was  
good.

Today, since networking has become Big Business, the dynamic has  
changed drastically.  For the most part the customers who attend IETF  
no longer have  the influence over the purchasing decision that they  
once did.  Instead, there are casts of hundreds involved, lengthy  
RFPs and evaluation processes, and decisions about multiple millions  
of dollars that are handled at the 'C' level in the organization.   
Frequently, the technical considerations are the minority factor in  
the decision making, if they are included at all.

Similarly on the vendor side, the engineers who attend IETF no long  
have a significant say in product content.  Feature development is  
carefully controlled by the vendor's managers, and engineers who  
contribute features that are not a requested part of the PRD for the  
next release are gently excused.

The upshot of this change in the dynamic is that we all need to  
understand that the process for getting ideas translated into product  
has changed.  While talking to one another as part of the IETF  
process is still beneficial, it is no longer sufficient.  In fact, it  
is no longer even an effective mechanism for communicating to the  
vendor.  Instead, the *only* effective channel is via the formal  
sales process.  Even then, the normal account manager or product  
manager may not be sufficient.  You may well need to talk to the  
specific person who is managing the specific release of the specific  
operating system for the specific point product on a specific  
development train.  Sadly, they are far less likely to be up to speed  
on the issue technically or likely to be influenced by "big picture"  
thinking or doing the "right thing".  For them, it is very likely  
that the sales opportunity connected to the feature is the one and  
only factor that is a meaningful input.

I don't mean to defend this process, just to ensure that everyone  
understands that this is the reality that we live in today.  It is  
(sadly) unlikely to change: there is too much money involved.  The  
only thing that we can do at this point is to cooperate to influence  
those above us in our respective organizations, realizing that none  
of us are empowered to be the decision makers for our respective  
companies.  Forward progress on this issue will take influencing both  
customer and vendor executives and we should ensure that we do that,  
but first and foremost we should be responsible for influencing our  
own organizations.  It would be best if we coordinated our efforts,  
but we should at the very least understand that all involved are  
somewhat limited in their authority.

Newly yours on the customer side of street,
Tony

---

From: Ran Liebermann <[email-masked]>
Date: Mon, 10 Oct 2005 14:27:54 +0200

> draft-huston-idr-as4bytes-survey-00.txt.

A couple of things:

1.
Just one cosmetic thing.  In my not-fully-English OS I see some funky
characters at the end of section 5.2.2 (last paragraph of page 3, 2nd
line from the top of the paragraph), between "Autonomous System" and
"AS number".

2.
There wasn't any mentioning as to the reserved AS numbers (RFC 1930
section 10).  I think it should be explicitly mentioned that a NEW BGP
speaker peering with an OLD speaker must not insert a reserved AS
number to the NEW_AS_PATH attribute.

Cheers,
--
Ran.

---

From: John Leslie <[email-masked]>
Date: Mon, 10 Oct 2005 11:16:50 -0400

Paul Jakma <[email-masked]> wrote:
>    first be at least examined, if not addressed?

   To be specific, Juniper reports:
] 
] Are there parts of the specification that are unclear where the
] implementor had to exercise some judgement that may impact
] interoperability?
]    *  It isn't clear what to do if the information in the old as-path
]       is inconsistent with the information in the new as-path.

   It seems to me that NEW_AS_PATH information inconsistent with
AS_PATH information MUST be discarded. Can't we say so?

]    *  There some places where AS numbers are used where it wasn't
]       clear how to deal with 4-octet as-numbers (e.g. extended
]       communities).

   This isn't clear to me, either.

]    *  It isn't spelled out that this capability cannot be dynamically
]       negotiated.

   Actually, I _can_ think how to dynamically negotiate it, but it
seems like a bad idea.

> (concerns 5.2.3 at least, see 3.).
] 
] Note that a route may have traversed a series of autonomous systems
] with 2-octet AS numbers and OLD BGP speakers only. In that case, if
] the route carries a NEW_AS_PATH attribute, this attribute may not
] have been updated since the route left the last NEW BGP speaker. The
] trailing AS path information (representing autonomous systems with
] 2-octet AS numbers and OLD BGP speakers only) is contained only in
] the current AS_PATH attribute (encoded in the leading part of the
] AS_PATH attribute). This AS path information should be prepended to
] the NEW_AS_PATH attribute to construct the exact AS path information.

   This last sentence is inconsistent with discarding NEW_AS_PATH
information which is inconsistent with AS_PATH information.

] Similarly, a NEW BGP speaker should be prepared to receive the
] NEW_AGGREGATOR attribute from an OLD BGP speaker. In that case, the
] AGGREGATOR attribute is ignored and the NEW_AGGREGATOR contains the
] exact information about the aggregating node.

   I find this worrisome. Any OLD BGP speakers will have been quite
unaware of the meaning of NEW-AGGREGATOR attributes they pass on. I
don't think we can ensure they _never_ introduce or modify an
AGGREGATOR attribute. I would be more comfortable if we examined any
NEW-AGGREGATOR attribute to clarify ambiguity in 2-octet numbers in
the AGGREGATOR attribute.

   There is a philosophical question here: whether we're retrofitting
4-octet AS numbers into an existing system, or whether we're piecing
together a new system of 4-octet AS numbers with some fudging of how
we tunnel through existing systems. Personally, I prefer the first.

>    defined to be those peers which do not implemented the extensions
] 
] In all other cases the speaker MUST encode Autonomous System numbers
] as 2-octet entities in both the AS_PATH and the AGGREGATOR attribute
] in the updates it sends to the peer, and MUST assume that these
] attributes in the updates received from the peer encoded Autonomous
] System numbers as 2-octet entities.

   Our problem is discerning a meaning for "all other cases". I don't
think there _is_ a clear meaning here. The section title suggests
we're specifying what an OLD BGP speaker MUST do; and that's simply
wrong.

   Deleting the secton seems easiest...

> NEW_AS_PATH:	seq(200000,256)

   Actually, I don't think it's clear whether this NEW_AS_PATH should
or should not contain 512.

> leading part",

   This is a very bad algorithm.

   We cannot, IMHO, ensure that AS_TRANS will not somehow get inserted
into a path without there being a corresponding entry in NEW_AS_PATH.
Thus, assuming that the closest AS_TRANS is the demarcation cannot
give dependable results.

   (However, Paul is exploring a different problem:)

> which is suggested by definition of "leading part" would give us:
> 

   Paul's algorithm looks safer...

   But IMHO we'd be poorly advised to blindly adopt it either.
Instead, we'd do well to match the trailing n ASNs, substituting
4-octet ASNs for AS_TRANS while the match remains good -- and dropping
back to the original AS_PATH if the match fails.

   (There is a weird case where the matching 4-octet AS _is_ AS_TRANS,
which IMHO is _not_ an error.)

> leading part of AS_PATH' language should be removed.

   I'd frankly prefer a full algorithm: otherwise we can't put very
much confidence in the result.

   But I'll admit that differing algorithms _might_ not be especially
harmful, so long as they preserve the AS_PATH _length_...

>      against the NEW_AS_PATH ASNs which are replacing them?

   (I, of course, don't believe the should be "overridden" -- merely
disambiguated.)

>   b) If so, what if they can /not/ be reconciled?

   We're poorly advised to leave _that_ question "as an exercise to
the student".

   I'm convinced that regardless of what we spec, NEW BGP speakers
_will_ receive AS_TRANS entries with no disambiguating NEW_AS_PATH
entry. This doesn't seem fatal: the worst effect which jumps out is
failure to detect loops (which seems fairly innocuous: detecting
loops where none exist would be a much more serious failing).

--
John Leslie <[email-masked]>

---

From: Paul Jakma <[email-masked]>
Date: Mon, 10 Oct 2005 16:40:20 +0100 (IST)

>   AS_PATH information MUST be discarded. Can't we say so?

I'd say the whole UPDATE would have to be discarded, you have no way 
of knowing exactly which of the two paths is "wrong", nor any way to 
properly reconstruct the path.

> information which is inconsistent with AS_PATH information.

Indeed, but the draft does not specify anywhere what action (if any) 
should be taken if the paths are found to be inconsistent. But that 
might be cause it doesn't describe in any meaningful way how to 
reconcile the different paths.

> AGGREGATOR attribute. I would be more comfortable if we examined 
> any NEW-AGGREGATOR attribute to clarify ambiguity in 2-octet 
> numbers in the AGGREGATOR attribute.

Ah, indeed yes, that needs clarification too. If AGGREGATOR is /not/ 
AS_TRANS then indeed AGGREGATOR is the last aggregator, and 
NEW_AGGREGATOR is just simply stale.

>   There is a philosophical question here: whether we're 
> retrofitting 4-octet AS numbers into an existing system, or whether 
> we're piecing together a new system of 4-octet AS numbers with some 
> fudging of how we tunnel through existing systems. Personally, I 
> prefer the first.

I think it's a bit of both.

> or should not contain 512.

Yes, that's what I was hinting at with "AS_PATH as received 
previously presumably" ;)

>   But IMHO we'd be poorly advised to blindly adopt it either.

Oh, ACK.

> 4-octet ASNs for AS_TRANS while the match remains good -- and 
> dropping back to the original AS_PATH if the match fails.

If the match fails, you have no clue who ferked up. NEW_AS_PATH 
/should/ be the canonical path information though for the further 
portion of the composite path. But if the further portion of the 
2-byte path does not coincide with the same further portion of the 
NEW_AS_PATH then either:

- an OLD speaker decided to modify bits of the path proir to it
 	- eg to aggregate it, in which case reconstructing the full
 	  composite PATH involves more than just appending/prepending
- the NEW speaker who formed the NEW_AS_PATH screwed up

- ???

Actually, is the "OLD speaker aggregated" case even discussed in the 
draft?

>   (There is a weird case where the matching 4-octet AS _is_ 
> AS_TRANS, which IMHO is _not_ an error.)

It is an error, AS_TRANS is reserved and its only described use is to 
denote 4-byte ASNs in 2-bytes. Hence there is no reason (within this 
draft at least) to see it in 4-byte space.

> harmful, so long as they preserve the AS_PATH _length_...

The draft at least should state what it *intends the result* from 
merging the OLD and NEW paths to be, and perhaps offer one example 
algorithm.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Ignorance must certainly be bliss or there wouldn't be so many people
so resolutely pursuing it.

---

From: Pekka Savola <[email-masked]>
Date: Mon, 10 Oct 2005 21:00:40 +0300 (EEST)

> draft-huston-idr-as4bytes-survey-00.txt.

high-level bits:

I don't think I've seen justification for this particular approach; if 
this is superior to the others for some reason, maybe background could 
be discussed a bit in the doc (e.g., in a missing "Introduction" 
section).

Specifically, I don't see why we couldn't just simply start using 
NEW_AS_PATH and NEW_AGGREGATOR and keep the old elements as-is -- 
changing the encoding of BGP messages based on the negotiated 
capabilities seems a bit troubling.

An additional concern is synthetization of BGP attributes when 
propagating messages.  One could ask whether this is really necessary 
or not.  I think it would be reasonbly to require that each transit AS 
which would be passing NEW_* attributes should be aware of them. 
Further, this approach could have security considerations if so/sBGP 
were to be deployed.

editorial nits
--------------

numerous nits, such as:
  - numbered status of this memo/abstract
  - references in the abstract
  - a non-ascii character

    For the purpose of this document lets define a BGP speaker which does

==> s/lets/we/

   NEW_AS_PATH.  This attribute is optional transitive and contains the

==> s/attribute is optional transitive/is an optional transitive 
attribute/
(similar elsewhere)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Enke Chen <[email-masked]>
Date: Mon, 10 Oct 2005 11:59:56 -0700

Hi, Paul:

> first be at least examined, if not addressed? (concerns 5.2.3 at

We did examine the questions raised:

* It isn't clear what to do if the information in the old as-path
is inconsistent with the information in the new as-path.

There is no good answer here - but will clarify on re-constructing the 
as-path.

* There some places where AS numbers are used where it wasn't
clear how to deal with 4-octet as-numbers (e.g. extended
communities).

Not a problem as the extended community spec has allocated type code for 
4-byte ASs.

* It isn't spelled out that this capability cannot be dynamically
negotiated.

Not a problem for the revised version of the dynamic capability - 
although there is no reason to make the capability dynamic in this case.

> defined to be those peers which do not implemented the extensions

Will delete the section.

> we're not told how one should deduce where this leading part finishes. 
> The simplistic approach of "closest AS_TRANS marks end of leading 
> part", which is suggested by definition of "leading part" would give us:
>
> Which result is wrong :). Obviously, one should use the n #-of-ASNs in 
> the *NEW_AS_PATH* as the *trailing* part of the real AS_PATH 

Will clarify on how to re-construct the as-path. Will send out the text 
when it is ready.

> described (I think it should ;) ), obvious questions arise, as one 
> responder to the implementation report hints at:
>

Not sure if this is necessary (based on the previous discussions).

> "<the NEW_AS_PATH> attribute may not have been updated since the route 
> left the last NEW BGP speaker."
>
> Which raises the question of how exactly any speaker besides a NEW (or 
> NEW-compatible) speaker would modify NEW_AS_PATH? Indeed, NEW_AS_PATH 
> can /not/ propogate across NEW speakers. The last speaker to have 
> "modified" NEW_AS_PATH is, by the language of the draft, the NEW 
> speaker which formed it which must therefore be the last NEW speaker. 
> So the "may not" should read "will not" instead.

Will revised.

Thanks a lot!

-- Enke

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 11 Oct 2005 09:57:08 -0400

> Not a problem as the extended community spec has allocated type code for 

In extended communities, the type may have as much to do with the community
being unique as does the contents.

RT-100:1 != RT4-100:1

Or at least this is one way to interpret the current spec.

-- 
Jeff Haas 
NextHop Technologies

---

From: John Leslie <[email-masked]>
Date: Tue, 11 Oct 2005 11:53:25 -0400

> properly reconstruct the path.

   Recall that the _result_ of all our routing-protocol machinations is
that a packet will be passed to the "most appropriate" next-hop.

   Thus, IMHO, what the peer-you-will-choose doesn't know, can't help
you.

   Following this principle, I prefer to use the 2-octet-AS path info
I get from my OLD BGP peer unless I'm confident I can do better.
(Arguably, we'd be better off to ignore NEW_AS_PATH entirely, but that
would sentence folks with AS > 65535 to never detect their loops.)

   So while I agree we don't know which path is "wrong", we do know
which one the peer we got it from will use. Thus, we know which one
is "better".

   I fail to see how discarding the UPDATE could be appropriate.

> reconcile the different paths.

   I really don't see any way to "reconcile" the paths. I've stated
my preference; the draft seems to choose the opposite direction.
Possibly we can nag Bill or Alex into suggesting a resolution.

> NEW_AGGREGATOR is just simply stale.

   True.

> I think it's a bit of both.

   We'd be better advised to choose, IMHO.

   And I'd advise choosing to "retrofit". We're going to be stuck with
a mixture of systems for many years into the future. (Hopefully,
systems nearest the backbone will become NEW BGP quickly when ASNs
greater than 65535 are allocated; but purchase cycles will drag on in
both directions. Near the edge, nothing _has_to_ happen until you
want to peer with an AS > 65535.)

> - an OLD speaker decided to modify bits of the path prior to it

   Mostly (IMHO), it's the second case.

   Let us not forget that the "B" of "BGP" is for "border". IOW,
the border of what we have good reason to trust. We're getting stuff
from peers we have limited reason to trust. They're passing on stuff
from peers _they_ have limited reason to trust. So most of the stuff
we deal with we have _no_ good reason to trust: it's merely "good
enough for best-effort".

   The days are _long_ gone when we could trust BB&N to keep all the
routing information consistent. If there ever was a time we could
trust Cisco to keep stuff consistent throughout the network of their
routers, that too is long gone.

> draft at least) to see it in 4-byte space.

   Well, that's an open question: if indeed the draft says it MUST
be discarded and the NEW_AS_PATH patched in for the remainder, there
MIGHT be no reason to see it coming from a NEW BGP speaker to another
NEW BGP speaker.

   But IMHO the draft does _not_ say that. Nor IMHO should it.

> merging the OLD and NEW paths to be, and perhaps offer one example 

   IMHO, the draft needs editing to clarify whether we're retrofitting
or tunneling. (I trust my recommendation between these is clear.)

---

From: Paul Jakma <[email-masked]>
Date: Tue, 11 Oct 2005 19:50:53 +0100 (IST)

On Tue, 11 Oct 2005, John Leslie wrote:

> (Arguably, we'd be better off to ignore NEW_AS_PATH entirely, but 
> that would sentence folks with AS > 65535 to never detect their 
> loops.)
>
> which one the peer we got it from will use.

The peer you got it from is OLD and is in the dark anyway wrt 4-byte 
ASNs. The 2-byte AS_PATH is therefore already incomplete and "wrong".

> Thus, we know which one is "better".

> I fail to see how discarding the UPDATE could be appropriate.

I disagree. Propogating known-inconsistent routes onward is asking 
for trouble during any transition period.

If there's an inconsistency between the two something has either gone 
badly wrong somewhere, or an OLD speaker in the path somewhere has 
decided to make major modifications to the 2-byte AS_PATH for reasons 
known only to itself (an attacker?), specifically modifying the 
portions that contained mapped-to-2byte ASNs, not realising it's 
destroying information it doesn't fully comprehend.

> I really don't see any way to "reconcile" the paths.

Sure there is, there has to be or this draft just can not work at 
all. And if the 2 paths are consistent (and there isn't a good reason 
for them not to be) then it's easy. ;)

>> NEW_AGGREGATOR is just simply stale.

The draft though says NEW_AGGREGATOR should always be used by a NEW 
speaker over AGGREGATOR. So that needs to be fixed in the draft too.

>   And I'd advise choosing to "retrofit". We're going to be stuck 
> with a mixture of systems for many years into the future. 
> (Hopefully, systems nearest the backbone will become NEW BGP 
> quickly when ASNs greater than 65535 are allocated; but purchase 
> cycles will drag on in both directions. Near the edge, nothing 
> _has_to_ happen until you want to peer with an AS > 65535.)

It's the other way around more likely. The edges of the internet are 
more likely to go NEW first (new ASes, the ones which will get 4-byte 
ASNs first, tend to be leaf sites). Indeed the 'backbone' of the 
internet could stay OLD forever, with edge ASes NEW and it'd still 
work fine. If we presume new ASes with 4-byte ASNs get NEW equipment, 
then we can imagine various 'edges' of the internet will look like:

A-B---<rest of internet>
  /
C

If A, B and C are 4-byte, then it just works. To the 'core' of the 
internet, if still 2-byte, it just looks as if there's some new 
super-AS (AS_TRANS) slowly taking over all the new leaf ASes on the 
internet ;).

> Well, that's an open question: if indeed the draft says it MUST be 
> discarded and the NEW_AS_PATH patched in for the remainder, there 
> MIGHT be no reason to see it coming from a NEW BGP speaker to 
> another NEW BGP speaker.

>   But IMHO the draft does _not_ say that. Nor IMHO should it.

It doesn't say it, no. I suspect it should though, as seeing AS_TRANS 
in a 4-byte AS_PATH would be a strong indicator someone screwed up.

What good reason is there to /not/ mandate that AS_TRANS expressed 
4-byte ASN form is an error?

>   IMHO, the draft needs editing to clarify whether we're 
> retrofitting or tunneling. (I trust my recommendation between these 
> is clear.)

I'm not sure why it makes a difference :).

We're moving from 2 to 4 bytes for ASNs, retrofitting 4-bytes on the 
existing BGP protocol and providing for some form of tunneling of 
4-byte AS_PATH's through BGP speakers as a transitional mechanism.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
He who has but four and spends five has no need for a wallet.

---

From: Paul Jakma <[email-masked]>
Date: Tue, 11 Oct 2005 19:55:28 +0100 (IST)

On Tue, 11 Oct 2005, Paul Jakma wrote:

> tend to be leaf sites). Indeed the 'backbone' of the internet could stay OLD 
> forever, with edge ASes NEW and it'd still work fine.

NB: That's not to say this would be a good thing. It'd be /far/ 
better if everyone got themselves NEW capable long before the first 
4-byte AS appears.

Just the draft /would/ allow for NEW functionality to just sit at the 
edges. (But then switching the remaining transit ASes to NEW would be 
murder).

regards,
Measure twice, cut once.

---

From: Enke Chen <[email-masked]>
Date: Tue, 11 Oct 2005 18:28:12 -0700

Hi, folks:

Attached is the revised text on how to construct the AS path information.

Please comment if you see any issue.

> Will clarify on how to re-construct the as-path. Will send out the 
> text when it is ready.

-----------------------------------------------------------------------------------------------------

The exact AS path information can be constructed by taking as many AS
numbers and path segments as necessary from the leading part of the
AS_PATH attribute, and then prepending them to the NEW_AS_PATH
attribute so that the AS path information has an identical number of
AS numbers as the AS_PATH attribute. The number of AS numbers is
calculated using the method specified in Sect. 9.1.2.2 [BGP-4] and
[RFC3065] for route selection. Note that an AS_CONFED_SEQUENCE or
AS_CONFED_SET path segment is counted as zero, and SHALL be prepended
when it is adjacent to another path segment that is prepended.
-----------------------------------------------------------------------------------------------------------

-- Enke

---

From: Paul Jakma <[email-masked]>
Date: Wed, 12 Oct 2005 09:20:51 +0100 (IST)

Hi Enke,

> Please comment if you see any issue.

Seems acceptable to me[1].

The issue of what to do if we detect an OLD speaker has done 
aggregation is still open though:

- If AGGREGATOR does not contain AS_TRANS then:
 	- an OLD speaker, which tries to include unknown attributes
           of aggregated routes in aggregates, has aggregated the
           route
 	  (these kinds of speakers are rare apparently?)

 	- NEW_AGGREGATOR should then be ignored (I believe you will
           be specifying this in a new revision)

This implies though that NEW_AS_PATH is *also* 'stale' and therefore 
the merging method will not be appropriate. I'd suggest at least:

- Also ignore NEW_AS_PATH if NEW_AGGREGATOR is ignored
 	- has an issue in what do about AS_TRANS's in the 2-byte path
 	  - just remove it? (Section 7 mentions risks with
             aggregates, as you pointed out to me privately)

This seems far more appropriate than just merging AS_PATH and 
NEW_AS_PATH given that doing so would likely replace the aggregate's 
AS_SET information with completely different information from a stale 
NEW_AS_PATH, or possibly fail to include /any/ portion of the 2-byte 
path in the merged path.

(For in such a case the path length of the NEW_AS_PATH no longer 
would have any strong correlation to the path length of any trailing 
portion of the OLD AS_PATH, so the method to determine which part is 
'leading' would produce a meaningless result - eg, it might indicate 
the AS_PATH has /no/ leading portion at all, or even a 'negative' 
leading portion ;) ).

It's still sufficiently simple given that this condition will likely 
be rare and the draft is willing to live with uncommon risks, 
particulary wrt aggregation.

E.g: move the text about ignoring NEW_AGGREGATOR to /before/ the text 
about NEW_AS_PATH and make the text concerning AS_PATH/NEW_AS_PATH be 
something like:

- if NEW_AGGREGATOR was present but has been ignored:
 	- ignore NEW_AS_PATH
 	- just strip AS_TRANS from the 2-byte AS_PATH and form the
           4-byte PATH directly from the result
- else
 	- perform the merging process (i.e. the updated text you
           posted)

The risks could be mitigated better, but with a more involved process 
of course.

> -- Enke

1. Though, ideally, I'd prefer to see the NEW speaker actually check 
the 2 paths make sense against each other, given the speaker doing 
the merging is the only speaker who could detect any such 
inconsistencies. After merging, the information will be lost. Also, 
the implementation report strongly suggests that at least one of the 
implementations /does/ attempt to detect inconsistencies... ;)

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
"The four building blocks of the universe are fire, water, gravel and vinyl."
 		-- Dave Barry

---

From: Geoff Huston <[email-masked]>
Date: Thu, 13 Oct 2005 02:01:35 +1000

If we are considering another round of this draft, then we may want to add
one further paragraph into the IANA Considerations section

namely:

--------------------

IANA is to create a 4-Byte AS Number Registry, where the registry's entries
for 4-Byte AS numbers from 0 to 65535 refer to the IANA "AUTONOMOUS SYSTEM
NUMBERS" registry, including listed reservations, allocations and special
designations. All future changes in the existing "AUTONOMOUS SYSTEM
NUMBERS REGISTRY" are also to be treated in the same way in the 4-Byte
AS number registry. No further 4-Byte AS Number reservations or special
designations apart from those noted here are proposed by this document.

-------------------

Is this proposed text in the IANA Considerations of the draft acceptable
to the WG? (Its either that or we need to do a special  purpose document
later on in order to open up this IANA registry.)

The alternative is to propose an augmentation of the existing AS number
registry where the first 65536 numbers are noted as "2-Byte compliant"
numbers, and the remainder of the registry are "4-Byte-only" values. I do not
recall seeing any precedent here in the IANA registries as to which is a
better way to go, but at least the text proposed here is a placeholder
that can be reviewed by the IANA during the IESG evaluation. If there is
a better idea as to the best way to undertake the IANA registry, then it
can be considered at that point in time.

regards,

   Geoff

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 12 Oct 2005 12:53:43 -0400

Geoff,

On Thu, Oct 13, 2005 at 02:01:35AM +1000, Geoff Huston wrote:
> numbers, and the remainder of the registry are "4-Byte-only" values.

I prefer this option.  While mistakes are probably rare at best,
this narrows (eliminates) the chances of a mistake causing a conflict
between the registries.

-- 
Jeff Haas 
NextHop Technologies

---

From: John Leslie <[email-masked]>
Date: Wed, 12 Oct 2005 16:47:19 -0400

Paul and I have hashed out a few things privately. I'd like to
update folks on stuff I think we've agreed not to argue on the list:

>> which one the peer we got it from will use.

   I believe Paul is ready to humor me here.

>> Thus, we know which one is "better".

   But not here. I promise not to argue "better".

>> I fail to see how discarding the UPDATE could be appropriate.

   I can't say we're particularly close to agreement, but I have
agreed that discarding the NLRI in an UPDATE containing an AS_PATH
and a NEW_AS_PATH known to be inconsistent is a valid action.

   I believe that discarding such NLRIs _should_ be permitted in
the spec.

>> I really don't see any way to "reconcile" the paths.

   I think we've agreed to stop using that word.

>> _has_to_ happen until you want to peer with an AS > 65535.)

   I've agreed to stop trying to draw a distinction between "retrofit"
and "tunnel".

> more likely to go NEW first...

   We've agreed that we should spec a transition which can work
either way (backbone going 4-byte first or edges going 4-byte first).

> 4-byte ASN form is an error?

   We've made some progress here. We're still hung up over calling it
an "error", but we've agreed it could happen in the wild, and that
a BGP speaker with AS > 65535 _should_ discard 4-byte NLRIs containing
it, since they could represent routing loops.

---

From: John Leslie <[email-masked]>
Date: Wed, 12 Oct 2005 16:57:13 -0400

> Attached is the revised text on how to construct the AS path information.

   I welcome this clarification. It's much easier to determine whether
a particular algorithm matches this description.

> ----------------------------------------------------------------------
> 
> AS_PATH attribute,

   This much is clearly correct.

> and then prepending them to the NEW_AS_PATH attribute so that the
> AS path information has an identical number of AS numbers as the
> AS_PATH attribute.

   It's very important to be clear that the AS_PATH "length" MUST be
the same as the AS_PATH received from the OLD BGP speaker.

   This algorithm should be appropriate, provided a reasonable test
for consistency between AS_PATH and NEW_AS_PATH is performed. (I'd
be happy to discuss my ideas for such a test.)

   I think we need to add a provision that the NLRI MAY (or even
SHOULD) be discarded if the two are inconsistent.

> The number of AS numbers is calculated...

   I'd prefer not to comment on this part: I haven't examined it in
detail. At first blush, it looks right.

---

From: Geoff Huston <[email-masked]>
Date: Thu, 13 Oct 2005 13:38:14 +1000

>this narrows (eliminates) the chances of a mistake causing a conflict

I'm personally not willing to write text for this option, as I feel that it
makes the 2-byte registry ambiguous in terms of interpretation. What I
have drafted is text that refers to the inclusion of the 2-Byte registry's
contents in the low (0:0 - 0:65,535) number block of the the 4-Byte registry
by reference. If you have alternate text as clear IANA instructions that
preserves the appropriate distinction between the 2-Byte and 4-Byte AS
number registries while co-existing in a single protocol parameter
register then a request for your text that achieves this would be
appropriate.

Geoff Huston
APNIC

---

From: Geoff Huston <[email-masked]>
Date: Thu, 13 Oct 2005 14:39:16 +1000

>either way (backbone going 4-byte first or edges going 4-byte first).

I do not understand this. Surprisingly, he earth is not flat. What is an 
'edge' and
what is a 'backbone' are from an individual network operator's perspective 
often
arbitrary distinctions, and then talking about which is these "goes first" 
is perhaps
unhelpful What I like about the draft as it stands is that it views transition
as a set of OLD / NEW and NEW / OLD transitions. That's simple and effective.
I would not readily ascribe attributes to a transition spec that starts 
from a premise
of "backbones" and "edges" and then starts to talk about which "goes first".

regards,

     Geoff

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 13 Oct 2005 01:22:41 -0400

In message <6.2.0.14.2.20051013143340.02e25900@localhost>
Geoff Huston writes:
> I do not understand this. Surprisingly, he earth is not flat.

That is only a theory according to some proposed science curriculum
revisions in the US.  [Is that too US Centric a joke?]

> What is
> an 'edge' and what is a 'backbone' are from an individual network
> operator's perspective often arbitrary distinctions, and then talking
> about which is these "goes first" is perhaps unhelpful What I like
> about the draft as it stands is that it views transition as a set of
> OLD / NEW and NEW / OLD transitions. That's simple and effective.  I
> would not readily ascribe attributes to a transition spec that starts
> from a premise of "backbones" and "edges" and then starts to talk
> about which "goes first".
>  
> regards,
>  
>      Geoff

Edges are things that are single homed or at most dual homed but the
important thing is that they don't take full routes, don't provide any
transit, and don't readvertise any routes that they learn from one
Internet facing interface to another.

Would you prefer transit and stub to backbone and edge?

It doesn't matter if single homed stubs ever understand as4byte.  They
don't really need to run an external routing protocol.  The dual homed
non-transit might take a subset of routes, but if a few are missing
they'll never know since they have a default (other than load balance
might be affected).  As soon as an AS passes routes from one peer to
another it might start to matter, but many small providers don't
provide transit to any BGP peers and their customers are not (or
should not be) passing routes to their other providers if dual homed
to more than one provider.  These "edges" don't have to convert before
a transition occurs.

It doesn't matter which AS converts to as4byte capable first as long
as the deployment is very far along before 4 byte AS start showing up.

Curtis

---

From: Enke Chen <[email-masked]>
Date: Wed, 12 Oct 2005 23:06:30 -0700

Hi, Paul:

You seem to be talking about the same case described in the Transition 
Sect. of the document::

----------------------------------------------------------------------------------
   Under certain conditions it may not be possible to reconstruct the
   entire AS path information from the AS_PATH and the NEW_AS_PATH
   attributes of a route. This occurs when two or more routes that carry
   the NEW_AS_PATH attribute are aggregated by an OLD BGP speaker, and
   the NEW_AS_PATH attribute of at least one of these routes carries at
   least one 4-octet AS number (as oppose to a 2-octet AS number that is
   encoded in 4 octets).
-----------------------------------------------------------------------------------

As I am not aware of any implementation that compares and preserves 
unrecognized attributes in aggregation, I concur that it should be 
"rare" to see the NEW_AS_PATH after aggregation by an OLD  BGP speaker.

In the unlikely scenario that the NEW_AS_PATH got preserved during 
aggregation by an OLD BGP speaker,  as it is not possible to construct 
the exact AS path info, it does not seem to matter whether we take the 
AS_PATH or the NEW_AS_PATH as each of them contains partial, valid info. 
(We could add some clarification, though.)

Regardless this loss of AS path info is not new for aggregation. 
Currently a large portion of the aggregates are created without AS_SET.

-- Enke

Paul Jakma wrote:

> (For in such a case the path length of the NEW_AS_PATH no longer would 
> have any strong correlation to the path length of any trailing portion 
> of the OLD AS_PATH, so the method to determine which part is 'leading' 
> would produce a meaningless result - eg, it might indicate the AS_PATH 
> has /no/ leading portion at all, or even a 'negative' leading portion 
> ;) ).
>
> the 2 paths make sense against each other, given the speaker doing the 
> merging is the only speaker who could detect any such inconsistencies. 
> After merging, the information will be lost. Also, the implementation 
> report strongly suggests that at least one of the implementations 
> /does/ attempt to detect inconsistencies... ;)
>
> regards,

---

From: Enke Chen <[email-masked]>
Date: Wed, 12 Oct 2005 23:29:13 -0700

Hi, John:

What types of "inconsistencies" between AS_PATH and NEW_AS_PATH you are 
concerned about, beyond the one described in the Transition Section 
(Please see my reply to Paul on that one)?

If your concern is about bogus AS path info somehow got propagated 
around, that seems to be a general issue, independent of the 4byte AS.

-- Enke

John Leslie wrote:

[snip]

---

From: Geoff Huston <[email-masked]>
Date: Thu, 13 Oct 2005 17:11:51 +1000

> Would you prefer transit and stub to backbone and edge?

yes!

>as the deployment is very far along before 4 byte AS start showing up.

I have got to agree wholeheartedly here

   geoff

---

From: Paul Jakma <[email-masked]>
Date: Thu, 13 Oct 2005 13:11:33 +0100 (IST)

On Wed, 12 Oct 2005, Enke Chen wrote:

> Hi, Paul:
>
> You seem to be talking about the same case described in the 
> Transition Sect. of the document::

No, I mean any case where one or more 4-byte paths are aggregated 
with one or more non-4-byte paths. The part in the draft concerns 
itself with two 4-byte paths being aggregated.

> "rare" to see the NEW_AS_PATH after aggregation by an OLD BGP 

Sure. But the transitional mechanism specified in the draft might 
have to remain 'dormant' for 5 or more years. So in addition to 
considering what is typical for speakers today, we should consider 
situations which are valid according to the RFC, particularly if they 
are very easy to deal with.

> aggregation by an OLD BGP speaker,  as it is not possible to construct the 
> exact AS path info, it does not seem to matter whether we take the AS_PATH or 
> the NEW_AS_PATH as each of them contains partial, valid info.

Well, the point is more that the merging /method/ doesn't apply any 
longer - the path lengths won't correlate. The method might even fail 
to include /any/ of the OLD path - which clearly is wrong.

> (We could add some clarification, though.)

What exactly is wrong with just ignoring NEW_AS_PATH if 
NEW_AGGREGATOR is? It's consistent and should be simple enough to 
state. I've left the outline quoted below.

> Currently a large portion of the aggregates are created without 

Sure, but I do not per se refer to the aggregated information. Other 
portions of the leading path could be lost too, because the method 
itself is inappropriate in such a case.

>> (For in such a case the path length of the NEW_AS_PATH no longer would have 
>> any strong correlation to the path length of any trailing portion of the 
>> OLD AS_PATH, so the method to determine which part is 'leading' would 
>> produce a meaningless result - eg, it might indicate the AS_PATH has /no/ 
>> leading portion at all, or even a 'negative' leading portion ;) ).

>> E.g: move the text about ignoring NEW_AGGREGATOR to /before/ the text about 
>> NEW_AS_PATH and make the text concerning AS_PATH/NEW_AS_PATH be something 
>> like:
>> 

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
 	The judge fined the jaywalker fifty dollars and told him if he was
caught again, he would be thrown in jail.  Fine today, cooler tomorrow.

---

From: John Leslie <[email-masked]>
Date: Fri, 14 Oct 2005 08:58:15 -0400

> concerned about, beyond the one described in the Transition Section 

   To tell truth, I'm not concerned about any particular case: I'm
concerned about the general case. I expect whatever algorithms we
specify to be still in use five years from now, in weird situations
we _cannot_ imagine.

> around, that seems to be a general issue, independent of the 4byte AS.

   Indeed, I am largely concerned about things which are a general
problem now. My concern is that these problems will lead to different
behaviors and that the trail will be harder to follow.

   I believe there are simple consistency checks that could be run,
and that if the consistency checks (between 2-byte AS_PATH and 4-byte
NEW_AS_PATH) fail, we could either discard the NLRI or tag the 4-byte
AS_PATH we will pass on so that other BGP speakers can know the
inconsistency was found.

   (Paul and I, BTW, haven't reached agreement on which of these options
is better. My concern is to establish the general principle, not to
argue the details.)