Subject: [Idr] Re: 4-Byte As Number soon to come?

From: Enke Chen <[email-masked]>
Date: Wed, 24 Aug 2005 01:02:00 -0700

Hi, folks:

My comment is regarding this suggestion on the NANOG mailing list:

 > I think it makes more sense to ALWAYS send the old 16-bit AS path and 
the new 32-bit AS path attribute

For folks that was involved in the IDR in 2001, you might remember that 
was the original design. However, it has the flaw of carrying duplicate 
info even after the world has transitioned to 4-byte AS, and some folks 
even suggested having a "second transition" to eliminate the 2-byte 
as-path.  So the idea was dropped.

-- Enke
-------------------------------------------------------------------------------------------------------------------

    Re: 4-Byte AS Number soon to come?

    * /From:/ Iljitsch van Beijnum
    * /Date:/ Wed Aug 24 02:59:08 2005

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

On 24-aug-2005, at 5:50, Susan Hares wrote:

This is the first of many steps.  And to be fair to the authors, the
process got held up due to the base draft being re-written.

So, the key discussion points are (as Yakov has indicated as well):
    a) Are there any technical problems with the specification
    b) Does the specification cause operational problems?
    c) General concerns about the design of the additions to BGP
        (scaling, etc).

I find the design less robust than it could be.

What it does is define that toward a neighbor that also supports wide AS 
numbers it will send the AS path with 32-bit AS numbers, and toward a 
neighbor that doesn't support wide AS numbers it sends the AS path with 
16-bit AS numbers and a "new AS path" with 32-bit AS numbers.

I think it makes more sense to ALWAYS send the old 16-bit AS path and 
the new 32-bit AS path attribute. This makes the code path identical for 
the two types of peers, which is less likely to lead to new bugs and 
makes for easier (operational) debugging.

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

---

From: Paul Jakma <[email-masked]>
Date: Wed, 24 Aug 2005 13:24:50 +0100 (IST)

On Wed, 24 Aug 2005, Enke Chen wrote:

>> I think it makes more sense to ALWAYS send the old 16-bit AS path and the 
> new 32-bit AS path attribute
>
> For folks that was involved in the IDR in 2001, you might remember that was 
> the original design. However, it has the flaw of carrying duplicate info even 
> after the world has transitioned to 4-byte AS, and some folks even suggested 
> having a "second transition" to eliminate the 2-byte as-path.  So the idea 
> was dropped.

Above is not a good idea either way, agreed.

Further, given I'm the only person here who seems concerned enough 
about either the "observer" issue or the more philosophical 
"attributes should be self-standing" issue to think the draft should 
be changed even if it invalidates existing implementations, and 
several others have disagreed, I withdraw my objection to the draft.

I still don't think it's ideal, but then I'm the only one standing in 
way of consensus - no more. :)

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
A long-forgotten loved one will appear soon.

Buy the negatives at any price.

---

From: Paul Jakma <[email-masked]>
Date: Fri, 26 Aug 2005 09:16:23 +0100 (IST)

On Wed, 24 Aug 2005, Paul Jakma wrote:

> "attributes should be self-standing" issue to think the draft 
> should be changed even if it invalidates existing implementations, 
> and several others have disagreed, I withdraw my objection to the 
> draft.

BTW, this is not an objection, but the thought struck me that if 
we're revisiting syntax of AS_PATH that we should, before proceeding, 
consider whether there are any /other/ issues or improvements in 
current AS_PATH which we should fix besides the ASN size.

Eg, we could disassociate path-length from the actual path 
information, and instead put an explicit path-length field in the 
AS_PATH (or better, NEW_AS_PATH ;) ). This would remove the need for 
AS_PATH prepending, you could instead simply increment the 
path-length field by more than one.

The actual path information would then be dimensionless, though it's 
order would be of great administrative interest.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
What is the sound of one hand clapping?

---

From: Paul Jakma <[email-masked]>
Date: Fri, 26 Aug 2005 11:05:23 +0100 (IST)

On Fri, 26 Aug 2005, Paul Jakma wrote:

> AS_PATH (or better, NEW_AS_PATH ;) ). This would remove the need 
> for AS_PATH prepending, you could instead simply increment the 

Other possibilities:

- increase the segment length field width to two octets, for future
   proofing.
   (This suggestion, in private, is what got me thinking about other
    possibilities if AS_PATH encoding is on the table)

- add some reserved space, for future proofing
   (eg, if we ever need 64bit ASNs ;), or need to signal other
    types of encoding changes.)

- add Tony Li's (et al) hopcount-TTL to the AS_PATH, rather than as a
   seperate attribute

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Two peanuts were walking through the New York.  One was assaulted.

---

From: "Manav Bhatia" <[email-masked]>
Date: Fri, 26 Aug 2005 18:50:49 +0530

Yes, if there is a thought to revisit the *_AS_PATH path attribute then i
would personally want to see (i) an increase in the segment length field (to
support more than 255 ASes) from the current one octet to 2 octets and (ii)
perhaps a reserved field for future extensions.

Cheers,
Manav

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 26 Aug 2005 11:04:49 -0400

In message <007401c5aa40$fbf455d0$6401a8c0@manav>
"Manav Bhatia" writes:
>  
> Yes, if there is a thought to revisit the *_AS_PATH path attribute
> then i would personally want to see (i) an increase in the segment
> length field (to support more than 255 ASes) from the current one
> octet to 2 octets and (ii) perhaps a reserved field for future
> extensions.
>  
> Cheers,
> Manav

The longest legitimate AS paths (not padded) are well under 20 in
length, the vast majority under 10 and typically 5 or less.  The only
practical purpose that allowing more than 255 would serve is to allow
further abuse of AS PATH padding.

Curtis

---

From: Paul Jakma <[email-masked]>
Date: Fri, 26 Aug 2005 16:08:06 +0100 (IST)

> further abuse of AS PATH padding.

If encoding can be changed beyond the current draft, that can be 
fixed too.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
You definitely intend to start living sometime soon.

---

From: Enke Chen <[email-masked]>
Date: Fri, 26 Aug 2005 08:17:04 -0700

The idea indeed came up in 2001, and was dropped based on the following 
reasoning:

     This is not a practical issue considering that the max ttl for ip 
packet (ipv4/ipv6) is only 255.

-- Enke

Paul Jakma wrote:

> If encoding can be changed beyond the current draft, that can be fixed 
> too.
>
> regards,

---

From: Paul Jakma <[email-masked]>
Date: Fri, 26 Aug 2005 16:25:55 +0100 (IST)

On Fri, 26 Aug 2005, Enke Chen wrote:

>    This is not a practical issue considering that the max ttl for ip packet 
> (ipv4/ipv6) is only 255.

True yes.

But, unlike IP TTL, the AS-Path can represent not just the length, 
but also the /width/.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
The default Magic Word, "Abracadabra", actually is a corruption of the
Hebrew phrase "ha-Bracha dab'ra" which means "pronounce the blessing".

---

From: Enke Chen <[email-masked]>
Date: Fri, 26 Aug 2005 10:14:02 -0700

The BGP base spec actually allows one to carry more than 255 AS numbers 
in the AS-PATH attribute using multiple segments. There is really no 
need to optimize for this unlikely scenario.

Regards,

-- Enke

Paul Jakma wrote:

> But, unlike IP TTL, the AS-Path can represent not just the length, but 
> also the /width/.
>
> regards,

---

From: "Manav Bhatia" <[email-masked]>
Date: Fri, 26 Aug 2005 22:53:51 +0530

Ok, so the argument is that since an IP packet will never traverse more than
255 hops, it makes no sense to have more than 255 ASes in the path.

This is not even an issue because even if we overflow the ASes in a sequence
we can introduce another AS_SEQUENCE.segment and that would work as well.

The problem is with AS_SETs. If the nos. of elements (i.e. ASes) goes beyond
255 then we cant insert another AS_SET segment as that would increase the
path length by 1.

Consider the following two paths:

as_path {a b} nlri 10.1.1/24
as_path {a1 b1} nlri 10.1.2/24
as_path {a2 b2} nlri 10.1.3/24

Agrregating this creates as_path [ a a1 a2 b b1 b2] nlri 10.1/16

Clearly the number of ASes in as_path is NOT proportional to number of hops.

Thanks,
Manav

----- Original Message ----- 
From: "Enke Chen" <[email-masked]>
To: "Paul Jakma" <[email-masked]>
Cc: "Curtis Villamizar" <[email-masked]>; "Manav Bhatia"
<[email-masked]>; "Inter-Domain Routing List" <[email-masked]>; "Enke
Chen" <[email-masked]>
Sent: Friday, August 26, 2005 8:47 PM
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?

---

From: Enke Chen <[email-masked]>
Date: Fri, 26 Aug 2005 10:24:42 -0700

> On Fri, 26 Aug 2005, Paul Jakma wrote:
[snip]

> types of encoding changes.)

As you indicated in a previous email, the 1:<xx> might last for 20 years :-)
So the 4-byte AS numbers may last for at least tens of thousands of 
years :-)

> - add Tony Li's (et al) hopcount-TTL to the AS_PATH, rather than as a

They are of different semantics. The hopcount can only be inserted by 
one AS, and is optional. It is also expected that only a (small) subset 
of the routes would need/do the hopcount attribute. IMHO the hopcount 
attribute should stay as is.

Regards,

-- Enke

---

From: Enke Chen <[email-masked]>
Date: Fri, 26 Aug 2005 10:39:51 -0700

>we can introduce another AS_SEQUENCE.segment and that would work as well.
Agreed.

>255 then we cant insert another AS_SET segment as that would increase the

As long as consistency is maitained with an AS, how is this different 
from AS prepend (with respect to the path length)?

-- Enke

---

From: "Manav Bhatia" <[email-masked]>
Date: Fri, 26 Aug 2005 23:35:00 +0530

I used this example to state that number of ASes in as_path may NOT be
proportional to number of hops.

We could potentially have applications in future (ecmp perhaps?) , which may
insert more than 255 ASes in an AS_SET. There we could have scenarios where
one may want to preserve the as_path length and may not want it to increase.

Keeping this upper bound of 255 ASes in an AS_SET looks unreasonable to me.
The only reason I bring this up is because there is a discussion going on
related to *_AS_PATH attribute, and this is one thing that can be addressed.

I would not be very comfortable with this, but if its too much of a hassle
then we could increase the length to 2 octets for only the *_AS_SET segment
and not touch the *_AS_SEQUENCE.

Manav

----- Original Message ----- 
From: "Enke Chen" <[email-masked]>
To: "Manav Bhatia" <[email-masked]>
Cc: "Paul Jakma" <[email-masked]>; "Curtis Villamizar"
<[email-masked]>; "Inter-Domain Routing List" <[email-masked]>; "Enke
Chen (enkechen)" <[email-masked]>
Sent: Friday, August 26, 2005 11:09 PM
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?

---

From: Glen Kent <[email-masked]>
Date: Sat, 27 Aug 2005 00:06:07 +0530

I think i understand his concern. However, I would be most
uncomfortable with having a different syntaxes for the sets and the
sequences. If the idea is to use two octets then we might as well do
it for both of them.

Enke, what is your concern with increasing the count of ASes (it
should btw never have been called the "length" which is extremely
confusing) to two octets?

This is assuming that the 4byte AS number draft would be reconsidered.
If thats not the case, then we are unnecessarily wasting time and
bandwidth.

Glen

---

From: Paul Jakma <[email-masked]>
Date: Fri, 26 Aug 2005 20:14:28 +0100 (IST)

On Fri, 26 Aug 2005, Enke Chen wrote:

> The BGP base spec actually allows one to carry more than 255 AS numbers in 
> the AS-PATH attribute using multiple segments. There is really no need to 
> optimize for this unlikely scenario.

You're still thinking in terms of length though. Yes, you can use an 
additional segment to go past a /length/ of 255. But not a width.

And no, you don't see anyone caring much about being able to express 
width /today/, primarily cause the only thing in BGP today which 
cares is aggregation.

There is a really good reason to care about width though, we don't 
have it in BGP yet, and at least one implementation which tried a 
'local' hack of this got burned by it because it ignored width..

Given that we likely have /potential/ path-widths of at least a 
hundred already *today* on paths that, eg, go through the 
several-hundred+ member-AS IXes we have today, given it's unlikely 
the internet is going to get narrower, then I think it's not 
unreasonable to consider whether to extend segment length so that it 
/definitely/ can never overflow.

I don't have hard numbers, but 255 doesn't feel like something I'd 
bet a lot of money on as 'future-proof'. So, given the very rare 
opportunity we have today to examine what changes, if any other than 
4-octets, should be made to AS_PATH to take it through another 15+ 
years of internet growth, I think it's very foolish to not at least 
*think* about it simply because the draft as stands has one early 
implementation. ;)

And yes, I am quite biased, because if some overwhelmingly good 
reason came along to change the draft, I'd get to have my nit fixed. 
:). But that's insignificant compared to carefully considering:

"We have to change AS_PATH anyway, so what will it need to 
future-proof it?"

"Nothing but ASN size" is of course a valid answer, but not without 
consideration.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
After the last of 16 mounting screws has been removed from an access
cover, it will be discovered that the wrong access cover has been removed.

---

From: Paul Jakma <[email-masked]>
Date: Fri, 26 Aug 2005 20:18:50 +0100 (IST)

On Fri, 26 Aug 2005, Enke Chen wrote:

> As long as consistency is maitained with an AS, how is this 
> different from AS prepend (with respect to the path length)?

AS_SET adds one to the path-length.

When you want to have a path-width of 256 at a certain point in your 
AS-Path then:

 	AS_SET(<255 ASN's>) AS_SET(<1 ASN>)

Simply isn't the same thing, that's a length of 2, width 255 followed 
by length 1, width 1 - not quite same thing.

regards,
"What's a battle?"

 	--Ralph Wiggum
 	  Whacking Day (Episode 9F18)

---

From: Paul Jakma <[email-masked]>
Date: Fri, 26 Aug 2005 20:30:15 +0100 (IST)

On Fri, 26 Aug 2005, Enke Chen wrote:

> As you indicated in a previous email, the 1:<xx> might last for 20 
> years :-) So the 4-byte AS numbers may last for at least tens of 
> thousands of years :-)

;)

Glad there's a solution for that actually.

> They are of different semantics.

Nah, it's a pretty good path attribute.

> The hopcount can only be inserted by one AS, and is optional.

And it still could be, even in a NEW_AS_PATH

> It is also expected that only a (small) subset of the routes would 
> need/do the hopcount attribute. IMHO the hopcount attribute should 
> stay as is.

I don't know, I have a feeling AS_HOPCOUNT could be really popular. 
Good idea. But you won't see /that/ much of it, no ;).

If you're redesigning AS_PATH, then a static field for as-hopcount 
seems a grand idea. Particularly as then *everyone* will have to 
support it within 5 to 10 years (when NEW_AS_PATH support would 
become essential). And hopefully there'd be lots of advance 
deployment before the actual ASN crunch..

Come on, surely there must be some interesting AS_PATH ideas you 
have?

Another idea: Get rid of as-path prepending by introducing an AS_WIDE 
segment, it would have the property of:

- only ever contains one ASN
- length field indicates not the number of ASNs in the segment data,
   but the amount to increase the hopcount by.

So, eg, a 6 ASN prepend like:

 	23456 23456 2345 23456 23456 23456

just becomes:

 	type: AS_WIDE, length: 6, 23456

on the wire, ie 6 bytes (4-octet ASN), instead of 12.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
The most dangerous organization in America today is:
 	(a) The KKK
 	(b) The American Nazi Party
 	(c) The Delta Frequent Flyer Club

---

From: Enke Chen <[email-masked]>
Date: Fri, 26 Aug 2005 14:23:57 -0700

Hi, Paul:

[snip]

> Come on, surely there must be some interesting AS_PATH ideas you have?

Indeed - based on what we know today and if this were 1992!

> So, eg, a 6 ASN prepend like:

This idea seems to be similar to what was proposed 10 years ago. Take a 
look at Vadim Antonov's draft (1995):

http://gato.kotovnik.com/~avg/old_page/draft-bgpmetric.txt

The issue then was the difficulty in transition to a new path selection 
algorithm.

Today the networks are much larger, and it is much more difficult.

Regards,

-- Enke

---

From: Paul Jakma <[email-masked]>
Date: Sat, 27 Aug 2005 07:02:18 +0100 (IST)

> Indeed - based on what we know today and if this were 1992!

Hehe :)

> This idea seems to be similar to what was proposed 10 years ago. Take a look 
> at Vadim Antonov's draft (1995):
>

Wow, that's really interesting. I was considering also proposing that 
one could encode the ASNs as (metric,ASN) tuples, but was dissuaded.

The above is far more sophisticated, though the full implications of 
what it suggests possibly are hard to discern.

> The issue then was the difficulty in transition to a new path 
> selection algorithm.

> Today the networks are much larger, and it is much more difficult.

In what sense? Given there is a "must be revised" event horizon lying 
somewhere between 2009 and 2020 for today's AS_PATH. Hence why we're 
discussing your draft. :)

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Bond reflected that good Americans were fine people and that most of them
seemed to come from Texas.
 		-- Ian Fleming, "Casino Royale"

---

From: Enke Chen <[email-masked]>
Date: Fri, 26 Aug 2005 23:42:33 -0700

Paul Jakma wrote:

>> This idea seems to be similar to what was proposed 10 years ago. Take 
>> a look at Vadim Antonov's draft (1995):
>>

A network must have consistent route selection in order to avoid 
forwarding loops. When some routers in a network recognize a new BGP 
attribute that changes route selection, and some do not, forwarding 
loops can occur.

Sorry - this is probably too basic, and boring for many folks on this 
list :-)

Regards,

-- Enke

---

From: Paul Jakma <[email-masked]>
Date: Sat, 27 Aug 2005 08:06:04 +0100 (IST)

On Fri, 26 Aug 2005, Enke Chen wrote:

> forwarding loops. When some routers in a network recognize a new 
> BGP attribute that changes route selection, and some do not, 
> forwarding loops can occur.

Gosh really?

Where exactly did I propose to either:

- change anything but as-path length metric
   - i don't remember mentioning changing the selection process

- change anything incompatibly over a transition period

?

> Sorry - this is probably too basic, and boring for many folks on 
> this list :-)

Nice.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Space is to place as eternity is to time.
 		-- Joseph Joubert

---

From: Enke Chen <[email-masked]>
Date: Sat, 27 Aug 2005 00:16:31 -0700

> - change anything incompatibly over a transition period

I thought we were talking about your idea of AS_WIDE segment.  It is 
possible that I misunderstood something there (and sorry in that case).

Regards,

-- Enke

---

From: Paul Jakma <[email-masked]>
Date: Sat, 27 Aug 2005 09:01:22 +0100 (IST)

On Sat, 27 Aug 2005, Enke Chen wrote:

> I thought we were talking about your idea of AS_WIDE segment.

Yes, an obvious optimisation - it doesn't change anything, only 
provides a compact way to encode as-prepending, an existing practice. 
There might be other reasonably obvious and risk-free modifications 
that could be made.

But: If and only if it's considered worthwhile to change the draft.

That's a question you and I have entrenched positions on and aren't 
going to resolve. (Though, if you update the IANA considerations of 
the draft to mention the "Assign 4-octets ASNs from AS_TRANS:x first" 
trick, I won't be terribly unhappy with the draft).

> It is possible that I misunderstood something there (and sorry in 
> that case).

No worries.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Linux is alread carrier (pigeon) grade
                 -> www.blug.linux.no/rfc1149/

 	- Alan Cox on linux-kernel

---

From: "Manav Bhatia" <[email-masked]>
Date: Sun, 28 Aug 2005 09:07:00 +0530

Okay there is another way of doing this.

Represent each AS path segment in the NEW_AS_PATH by a quadruple <flags,
path segment type, path segment length, path segment value>. If the LSB of
the flags is set then the path segment MUST be considered contiguous to the
previous segment and should not affect the path length. This bit would be
relevant only when the path segment is of type SET.

This way we dont need to increase the length field to two octets. The
remaining bits in the 'flags' field can be put to other uses in the future.

Manav

----- Original Message ----- 
From: "Manav Bhatia" <[email-masked]>
To: "Enke Chen" <[email-masked]>
Cc: "Inter-Domain Routing List" <[email-masked]>; "Paul Jakma" <[email-masked]>
Sent: Friday, August 26, 2005 11:35 PM
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?

> > >>>If encoding can be changed beyond the current draft, that can be
fixed

---

From: Glen Kent <[email-masked]>
Date: Sun, 28 Aug 2005 21:37:17 +0530

> > as-path. So the idea was dropped.

 I went through the IDR mail archives (circa 2001 and early 2002) and i 
didnt come across any active discussion regarding the 4-byte AS draft. Did i 
miss something?
 BTW, which vendors have actually implemented this feature?
 Glen
_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: Enke Chen <[email-masked]>
Date: Sun, 28 Aug 2005 11:11:10 -0700

Hi, Glen:

>didnt come across any active discussion regarding the 4-byte AS draft. Did i 

My recollection is that there were active discussions at the IDR WG 
meeting, and a lot of discussions in the hallway (in addition to 
numerous discussions among the authors and other active participants).  
I do not remember much about the activities on the IDR mailing list at 
that time.

> BTW, which vendors have actually implemented this feature?
My understanding is that the editor (Geoff) has received two 
implementation reports. So we can expect to see the report really soon.

-- Enke

---

From: Glen Kent <[email-masked]>
Date: Sun, 28 Aug 2005 23:49:46 +0530

> implementation reports. So we can expect to see the report really soon.
 Is it Redback and now, Cisco? ;-)
 Glen.
_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 30 Aug 2005 13:10:58 -0400

Two comments:

> AS_SET adds one to the path-length.

Perhaps it would make sense to treat adjacent set segments as not
adding to the path length.  E.g.

> 	AS_SET(<255 ASN's>) AS_SET(<1 ASN>)

would be treated as length 1 rather than 2.

(Of course the entire AS would have to use this logic.)

The second comment was regarding padding vs. a "wide" AS attribute.
While a wide AS attribute would have nice encoding properties, they
are semantically identical.  Changing the encoding doesn't seem to
be a big win at this point, as-4bytes not withstanding.

-- 
Jeff Haas 
NextHop Technologies

---

From: Paul Jakma <[email-masked]>
Date: Tue, 30 Aug 2005 18:39:54 +0100 (IST)

> would be treated as length 1 rather than 2.

I think a modification of Manav's idea given earlier in this 
discussion would be nice: he proposed adding a flag to signal whether 
a segment should be treated as a continuation of the previous 
segment. I'd suggest this could be done with a new segment type, eg 
AS_CONTINUATION, so you encode a set of 256 ASNs as:

 	AS_SET(<255 ASNs>) AS_CONTINUATION(<1 ASN>)

AS_CONTINUATION would have no meaning other than extending the length 
of the last seen non-continuation segment.

> (Of course the entire AS would have to use this logic.)

The entire internet even :)

> be a big win at this point, as-4bytes not withstanding.

Of that change itself, yes, I agree. But it's one of several little 
nits, other than sizeof(ASN), which I think ideally ought to be taken 
care of if AS_PATH is revised, some of those nits being:

- inefficient encoding of prepends
- 255 length limit
- using the new NEW_AS_PATH type for NEW speakers, rather than
   overloading the existing AS_PATH type
- clarifying effect on path-length of AS_SET and AS_SEQUENCE in the
   definition of AS_PATH itself (currently, it's not specified in the
   definition itself, but elsewhere in the BGP-4 draft.)
- clarifying text on segment packing in AS_PATH

The latter two points can, and should, still be taken care of in the 
draft before us today regardless, as it shouldn't affect encoding.

The first three "nits" affect syntax obviously.

regards,
You are here:
 		***
 		***
 	     *********
 	      *******
 	       *****
 		***
 		 *

 		 But you're not all there.

---

From: Paul Jakma <[email-masked]>
Date: Tue, 30 Aug 2005 18:43:17 +0100 (IST)

On Sat, 27 Aug 2005, Paul Jakma wrote:

> resolve. (Though, if you update the IANA considerations of the draft to 
> mention the "Assign 4-octets ASNs from AS_TRANS:x first" trick, I won't be 
> terribly unhappy with the draft).

Urg, oops, AS_TRANS obviously wont do as it will be used as a 
two-octet ASN.

So an additional two-octet ASN (AS_4OCTET?) ought to be reserved by 
IANA and used as the prefix for the block to assign the first 65k 
4-octet ASNs from. AS_4OCTET should /never/ encoded in two-octets on 
the wire.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
printk("you lose buddy boy...\n");
         linux-2.6.6/arch/sparc/kernel/traps.c

---

From: Paul Jakma <[email-masked]>
Date: Tue, 30 Aug 2005 18:57:58 +0100 (IST)

> would be treated as length 1 rather than 2.

One comment I forgot to make, I strongly would recommend against 
considering allowing adjacent AS_SET's to be packed together. An 
AS_SET segment has a fixed length, independent of the ASNs contained 
within, merging hence alters the path-length. There are potential 
applications of this property of AS_SETs.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
[Washington, D.C.] is the home of... taste for the people -- the big,
the bland and the banal.
 		-- Ada Louise Huxtable

---

From: Glen Kent <[email-masked]>
Date: Tue, 30 Aug 2005 23:38:36 +0530

I would tend to agree with Paul here.
 Merging the SETs together appears to me as a hacky way of fixing the the 
issue of inserting more than 255 ASes in a SET. I am sure there must be 
better and cleaner ways of doing the same.
 Glen.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 30 Aug 2005 15:11:10 -0400

At least in the approach that we suggested in our ID for preserving path 
length and what path information can be preserved in multi-pathing, 
collapsing adjacent sets would break what we were doing.  There are other 
solutions, which reduce the available information, but can cope if the WG 
decides that adjacent sets should be collapsesd.

Yours,
Joel

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 31 Aug 2005 11:47:35 -0400

On Tue, Aug 30, 2005 at 06:57:58PM +0100, Paul Jakma wrote:
> considering allowing adjacent AS_SET's to be packed together.

The current bgp draft has already gone past last call.  Lots of
people implement this already:

            - for each pair of adjacent tuples in the aggregated
            AS_PATH, if both tuples have the same type, merge them
            together, as long as doing so will not cause a segment with
            length greater than 255 to be generated.

Proposals that want to leave sets in disjoint segments don't have a lot
of hope of having their segments unmerged in many implementations
under conditions of another aggregation.  I'd strongly suggest that
another path be considered for implementing the desired feature.

General comment on path length:

While path length was commonly implemented in many versions of BGP
post RFC 1771, it wasn't in the spec for a very long time.  The behavior
of having an AS_SET count as 1 towards the length per segment is
relatively new.

In general, as long as an AS consistently applies BGP tie breaking,
you can calculate the length however you like.  You simply must follow
the path loop detection mechanisms (check for your AS on ingress,
prepend your AS on egress) and the rest of the Internet can construct
a loop free topology.

While path length has certainly served as a very big knob to allow
for one form of traffic engineering, I think it's generally understood
that this relies on the kindness of operators to let path length
influence things as much as they do.

-- 
Jeff Haas 
NextHop Technologies

---

From: Glen Kent <[email-masked]>
Date: Wed, 31 Aug 2005 23:11:34 +0530

> > length greater than 255 to be generated.

 This is going to break a lot of implementations out there in the field. I 
am aware of atleast 3, all widely deployed, that will get affected with 
this. There are then many others who have taken the stack from one of these 
that will get affected.
 What do we gain out of this anyways?
 Glen.
Glen.
_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 31 Aug 2005 13:59:47 -0400

> - inefficient encoding of prepends

Your data may vary.  I encourage those with an interest in the matter
(I suspect them to be few :-) to run their own numbers.
This is from my local set:

Total distinct AS Paths in local database: 105887
Total paths containing an AS_SET: 110
Distribution of path length in local database:

   2:     11
   3:    699
   4:  25740
   5:  37612
   6:  25205
   7:   8766
   8:   3218
   9:   1628
  10:    921
  11:    664
  12:    527
  13:    301
  14:    213
  15:    172
  16:     89
  17:     52
  18:     27
  19:     16
  20:      6
  21:      9
  22:      3
  26:      3
  27:      1

I haven't done the distribution correlation against that observed by
well known researchers, but the majority is between 4-6, which is
what I'd expect considering that my feeds are not from the core.
Data from sources such as route-views may be interesting.

84% of the data set is <= 6.

Number of bytes to represent a sequence of 6 2-byte ASes: 14

Number of bytes to represent the same sequence presuming 0 prepends
and 2 byte ASes using a tuple of <1byte count, 2byte AS>: 20.

This is 30% overhead.

Of related interest, the number of distinct paths that have prepending
(represented by the occurence of a given AS more than once):
14254, representing 13.5% of the data set.

Distribution of prepended ASes:
   4:     68
   5:   1512
   6:   3125
   7:   2882
   8:   2213
   9:   1473
  10:    898
  11:    664
  12:    527
  13:    301
  14:    213
  15:    172
  16:     89
  17:     52
  18:     27
  19:     16
  20:      6
  21:      9
  22:      3
  26:      3
  27:      1

1/3 of the prepended ASes are within <= length 6.

My Conclusions:
A length of 255 isn't a problem right now, except with respect
to implementation bugs for segment overflow. :-)

Prepending encoding would introduce additional overhead, not
reduce it from an encoding standpoint.

>   overloading the existing AS_PATH type

I'm of mixed opinion on overloading the existing mechanism depending
on the behavior of the speaker as a 2-byte or 4-byte speaker.  It
certainly had to be accounted for in the bgp v2 mib.  I do like the
fact that after the majority of the Net transitions to as4bytes that
we're not carrying duplicate information.  As a transitional mechanism,
IMO, it's good.

>   definition itself, but elsewhere in the BGP-4 draft.)

I think it's pretty clear:

      a) Remove from consideration all routes which are not tied for
      having the smallest number of AS numbers present in their AS_PATH
      attributes. Note, that when counting this number, an AS_SET counts
      as 1, no matter how many ASs are in the set.

> - clarifying text on segment packing in AS_PATH

I've previously posted on this.  I believe the arguments being made
aren't a call for clarification, it's a call to change the behavior
so that tuples aren't merged as a side effect of aggregation.

-- 
Jeff Haas 
NextHop Technologies

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 31 Aug 2005 14:03:15 -0400

On Wed, Aug 31, 2005 at 11:11:34PM +0530, Glen Kent wrote:
>  This is going to break a lot of implementations out there in the field.

A lot of implementations of what?

-- 
Jeff Haas 
NextHop Technologies

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 31 Aug 2005 14:03:05 -0400

In message <[email-masked]>
Glen Kent writes:
>  This is going to break a lot of implementations out there in the field. I>  
> this. There are then many others who have taken the stack from one of these>  
> that will get affected.

Mr Glen Glen,

What exactly do you think will break?  As Jeff pointed out and you
chopped off, the AS_SET counting as 1 is new and as long as the same
thing is done in any one AS things work.  The implication for cutover
is that new software needs an option to coexist with old software.
When all new software is installed a few flag seconds (not a flag day)
is needed to disable that old behaviour.  At worst a few routes will
have inconsistent decisions for a few seconds and its a one time
transition.  Other vendors with new BGP implementations would have to
have the same option but being "bug for bug compatible" with the
incumbent has always been an aspect of this business.

Curtis

---

From: Paul Jakma <[email-masked]>
Date: Wed, 31 Aug 2005 19:44:33 +0100 (IST)

> A length of 255 isn't a problem right now, except with respect to 
> implementation bugs for segment overflow. :-)

Yes, I agree actually. It's not important now.

> reduce it from an encoding standpoint.

I don't quite see how, as it can be encoded in two words of data, 
always. A prepend using a sequence takes the same for first prepend. 
A word per ASN after that.

Here's what I see from my limited corner of the world:

prepended: 2, 497
prepended: 3, 360
prepended: 4, 581
prepended: 5, 103
prepended: 6, 168
prepended: 7, 44
prepended: 8, 18
prepended: 9, 19
prepended: 10, 28
prepended: 11, 19
prepended: 12, 0
prepended: 13, 1
prepended: 14, 1
prepended: 15, 1
prepended: 16, 1

Out of ~26k prefixes I receive. 28 distinct paths which have 10-ASN 
prepends. Even *16* ASN prepends :).

It's not terribly important no though, but if we had the chance be 
nice to reduce the sillyness of encoding 2 words of information in 
20.

> I'm of mixed opinion on overloading the existing mechanism 
> depending on the behavior of the speaker as a 2-byte or 4-byte 
> speaker.  It certainly had to be accounted for in the bgp v2 mib.

> I do like the fact that after the majority of the Net transitions 
> to as4bytes that we're not carrying duplicate information.  As a 
> transitional mechanism, IMO, it's good.

Or you could have the net simply transition to the new type. The old 
type just dies out with the OLD speakers. No difference.

In either case, be it transitioning to new type code or transitioning 
to a new as-path but reusing the type code, you're transitioning and 
dropping support for the old. No difference really.

>      as 1, no matter how many ASs are in the set.

That's part of the text on route-selection though. It affects how 
route-selection works.

It'd be nice to make this part of the definition of the actual 
AS_PATH attribute, rather than having various properties of AS_PATHs 
be inferred from reading various other bits of a text.

> so that tuples aren't merged as a side effect of aggregation.

As a side-effect of aggregation - fine. Aggregation /specifies/ that, 
and the AS_SET introduced is created by the speaker concerned.

The question is whether speakers are allowed to merge adjacent 
AS_SET's in paths which they are /not/ aggregating but simply passing 
along.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
"Eww, Daddy, this tastes like Gramma!"

 	--Ralph Wiggum
 	  E-I-E-I-(ANNOYED GRUNT) (Episode AABF19)

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 31 Aug 2005 14:56:04 -0400

> nice to reduce the sillyness of encoding 2 words of information in 

Nice, yes.  In this case, This is the Wrong Tool.

Now, if you want to argue that this is more likely to happen in the future,
the nice researchers on GROW will be interested. :-)

> dropping support for the old. No difference really.

I agree.  That said, I think the mechanism as proposed is fine.
At this point, it has implementations.  Consensus is rough, code is
running and the Internet runs. 

> be inferred from reading various other bits of a text.

Indeed.

Having a complete rewrite of the BGP spec for the next time we go
through a major document update that is clearer is certainly an
option.  However, I'd suggest reviewing the time frame of the
current update for an idea how long that sort of effort will take.

> AS_SET's in paths which they are /not/ aggregating but simply passing 

For loop prevention purposes, it's not important.
For path length calculation, it's locally important.
For inter-domain behavior, it may affect route selection.  There
are situations (aggregation) where this may Just Happen.  Counting
on it to not happen is probably a bad idea.

-- 
Jeff Haas 
NextHop Technologies

---

From: Tulip Rasputin <[email-masked]>
Date: Wed, 31 Aug 2005 15:25:50 -0400 (EDT)

> on it to not happen is probably a bad idea.

As long as the collapsing of SETs is done only by the speaker performing aggregation, proposals
that want to utilize disjoint SET segments have no reason to fret about. This is because the act
of aggregation is akin to generating a new route.

The authors of such proposals would be in a better position to comment though.

Tulip

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

---

From: Paul Jakma <[email-masked]>
Date: Wed, 31 Aug 2005 21:28:31 +0100 (IST)

On Wed, 31 Aug 2005, Jeffrey Haas wrote:

> I agree.  That said, I think the mechanism as proposed is fine. At 
> this point, it has implementations.  Consensus is rough, code is 

Yes, that is indeed a good reason to leave the mechanism and encoding 
in as4bytes unchanged.

> current update for an idea how long that sort of effort will take.

I think we're talking at cross-purposes possibly.

For case where a speaker does route-aggregation, it should merge. 
That's what the RFC says it should do, so that's what it should. I'm 
not referring to that, though I think possibly you think i am ;).

I meant the case where a speaker advertises on a route - not doing 
aggregation at all. The current draft does not specify that speakers 
in such a case may or should merge adjacent sets.

It seems there is at least differing opinion on whether this is 
allowed or not, possibly differing implementation too. It'd be nice 
to iron this out. It'll affect one of the two possible classes of 
implementations, but then it affects route-selection between them 
anyway.

> For loop prevention purposes, it's not important.

ACK.

> on it to not happen is probably a bad idea.

ACK.

We could at least decide which way to go though and remove the scope 
for differing interpretations. You posed this very question a few 
years ago here on IDR I think.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
One Bell System - it used to work before they installed the Dimension!

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 31 Aug 2005 23:05:51 -0400

Given that path prepending is the primary (arguably the only) way for an 
advertiser to express provider preference in a way visible to information 
receivers, it seems that AS Path length is still our primary knob.

This would suggest that having routers along a path change the AS Path 
length of advertisements they have (potentially shortening the length) 
would be a very bad thing.

It was precisely to avoid such misleading effects that we introduced the 
series of AS Sets.

Yours,
Joel M. Halpern

Date: Wed, 31 Aug 2005 23:05:51 -0400
To: Jeffrey Haas <[email-masked]>, Paul Jakma <[email-masked]>
From: "Joel M. Halpern" <[email-masked]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
Cc: [email-masked]
Sender: [email-masked]

Given that path prepending is the primary (arguably the only) way for an 
advertiser to express provider preference in a way visible to information 
receivers, it seems that AS Path length is still our primary knob.

This would suggest that having routers along a path change the AS Path 
length of advertisements they have (potentially shortening the length) 
would be a very bad thing.

It was precisely to avoid such misleading effects that we introduced the 
series of AS Sets.

Yours,
Joel M. Halpern

Date: Wed, 31 Aug 2005 21:28:31 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Jeffrey Haas <[email-masked]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
Mail-Copies-To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

ACK.

ACK.

regards,

Date: Wed, 31 Aug 2005 15:25:50 -0400 (EDT)
From: Tulip Rasputin <[email-masked]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
To: Jeffrey Haas <[email-masked]>, Paul Jakma <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

Tulip

Date: Wed, 31 Aug 2005 14:56:04 -0400
From: Jeffrey Haas <[email-masked]>
To: Paul Jakma <[email-masked]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
Cc: [email-masked]
Sender: [email-masked]

Indeed.

-- 
Jeff Haas 
NextHop Technologies

Date: Wed, 31 Aug 2005 19:44:33 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Jeffrey Haas <[email-masked]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
Mail-Copies-To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

prepended: 2, 497
prepended: 3, 360
prepended: 4, 581
prepended: 5, 103
prepended: 6, 168
prepended: 7, 44
prepended: 8, 18
prepended: 9, 19
prepended: 10, 28
prepended: 11, 19
prepended: 12, 0
prepended: 13, 1
prepended: 14, 1
prepended: 15, 1
prepended: 16, 1

regards,

 	--Ralph Wiggum

To: Glen Kent <[email-masked]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come? 
Date: Wed, 31 Aug 2005 14:03:05 -0400
From: Curtis Villamizar <[email-masked]>
Cc: [email-masked], Jeffrey Haas <[email-masked]>, Paul Jakma <[email-masked]>
Reply-To: [email-masked]
Sender: [email-masked]

In message <[email-masked]>
Glen Kent writes:
> >=20
> >=20
>  This is going to break a lot of implementations out there in the field. I=
> =20
> am aware of atleast 3, all widely deployed, that will get affected with=20
> this. There are then many others who have taken the stack from one of these=
> =20
> that will get affected.

Mr Glen Glen,

Curtis

Date: Wed, 31 Aug 2005 14:03:15 -0400
From: Jeffrey Haas <[email-masked]>
To: Glen Kent <[email-masked]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
Cc: [email-masked]
Sender: [email-masked]

-- 
Jeff Haas 
NextHop Technologies

Date: Wed, 31 Aug 2005 13:59:47 -0400
From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
Sender: [email-masked]

   2:     11
   3:    699
   4:  25740
   5:  37612
   6:  25205
   7:   8766
   8:   3218
   9:   1628
  10:    921
  11:    664
  12:    527
  13:    301
  14:    213
  15:    172
  16:     89
  17:     52
  18:     27
  19:     16
  20:      6
  21:      9
  22:      3
  26:      3
  27:      1

This is 30% overhead.

My Conclusions:

-- 
Jeff Haas 
NextHop Technologies

Date: Wed, 31 Aug 2005 23:11:34 +0530
From: Glen Kent <[email-masked]>
To: Jeffrey Haas <[email-masked]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
Cc: [email-masked], Paul Jakma <[email-masked]>
Sender: [email-masked]

--===============1851877030==
Content-Type: multipart/alternative; 
	boundary="----=_Part_4398_9084944.1125510094238"

------=_Part_4398_9084944.1125510094238
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

>=20
>=20

 This is going to break a lot of implementations out there in the field. I=
=20
am aware of atleast 3, all widely deployed, that will get affected with=20
this. There are then many others who have taken the stack from one of these=
=20
that will get affected.
 What do we gain out of this anyways?
 Glen.
Glen.

------=_Part_4398_9084944.1125510094238
Content-Type: text/html; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

<div>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">&gt; The current bgp draft has a=
lready gone past last call.&nbsp;&nbsp;Lots of<br>&gt; people implement thi=
s already:
<br><br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - =
for each pair of adjacent tuples in the aggregated<br>&gt;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AS_PATH, if both tuples have th=
e same type, merge them<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp; together, as long as doing so will not cause a segment wit=
h
<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; length=
 greater than 255 to be generated.</blockquote>
<div>&nbsp;</div>
<div>This is going to break a lot of implementations out there in the field=
. I am aware of atleast 3, all widely deployed, that will get affected with=
 this. There are then many others who have taken the stack from one of thes=
e that will&nbsp;get affected.
</div>
<div>&nbsp;</div>
<div>What do we gain out of this anyways?</div>
<div>&nbsp;</div>
<div>Glen.</div>
<div>Glen.</div>
<div>&nbsp;</div></div>

------=_Part_4398_9084944.1125510094238--

--===============1851877030==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--===============1851877030==--

Date: Wed, 31 Aug 2005 11:47:35 -0400
From: Jeffrey Haas <[email-masked]>
To: Paul Jakma <[email-masked]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
Cc: [email-masked]
Sender: [email-masked]

-- 
Jeff Haas 
NextHop Technologies

Date: Tue, 30 Aug 2005 15:11:10 -0400
To: Jeffrey Haas <[email-masked]>, [email-masked]
From: "Joel M. Halpern" <[email-masked]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
Cc: 
Sender: [email-masked]

Yours,
Joel

Date: Tue, 30 Aug 2005 23:38:36 +0530
From: Glen Kent <[email-masked]>
To: Paul Jakma <[email-masked]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
Cc: [email-masked], Jeffrey Haas <[email-masked]>
Sender: [email-masked]

--===============1715895151==
Content-Type: multipart/alternative; 
	boundary="----=_Part_5467_19477096.1125425316784"

------=_Part_5467_19477096.1125425316784
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

I would tend to agree with Paul here.
 Merging the SETs together appears to me as a hacky way of fixing the the=
=20
issue of inserting more than 255 ASes in a SET. I am sure there must be=20
better and cleaner ways of doing the same.
 Glen.=20
 On 8/30/05, Paul Jakma <[email-masked]> wrote:=20
>=20
>=20
>=20
>=20
>=20

------=_Part_5467_19477096.1125425316784
Content-Type: text/html; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

<div>I would tend to agree with Paul here.</div>
<div>&nbsp;</div>
<div>Merging the SETs together appears to me as&nbsp;a hacky way of fixing =
the the issue of inserting more than 255 ASes in&nbsp;a SET. I am sure ther=
e must be better and cleaner ways of doing the same.</div>
<div>&nbsp;</div>
<div>Glen.&nbsp;<br>&nbsp;</div>
<div><span class=3D"gmail_quote">On 8/30/05, <b class=3D"gmail_sendername">=
Paul Jakma</b> &lt;<a href=3D"mailto:[email-masked]">[email-masked]</a>&gt; w=
rote:</span>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">On Tue, 30 Aug 2005, Jeffrey Haa=
s wrote:<br><br>&gt; Perhaps it would make sense to treat adjacent set segm=
ents as not
<br>&gt; adding to the path length.&nbsp;&nbsp;E.g.<br>&gt;<br>&gt;&gt;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;AS_SET(&lt;255 ASN's&gt;) AS_SET(&lt;1 ASN&=
gt;)<br>&gt;<br>&gt; would be treated as length 1 rather than 2.<br><br>One=
 comment I forgot to make, I strongly would recommend against
<br>considering allowing adjacent AS_SET's to be packed together. An<br>AS_=
SET segment has a fixed length, independent of the ASNs contained<br>within=
, merging hence alters the path-length. There are potential<br>applications=
 of this property of AS_SETs.
<br><br>regards,<br>--<br>Paul Jakma&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>&nbsp;&nbsp; <a href=3D"mail=
to:[email-masked]">[email-masked]</a>&nbsp;&nbsp;Key ID: 64A2FF6A<br>Fortun=
e:<br>[Washington, D.C.] is the home of... taste for the people -- the big,
<br>the bland and the banal.<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- Ada Louise Huxtable<br><br>___=
____________________________________________<br>Idr mailing list<br><a href=
=3D"mailto:[email-masked]">[email-masked]</a><br><a href=3D"https://www1.ietf.o=
rg/mailman/listinfo/idr">
https://www1.ietf.org/mailman/listinfo/idr</a><br></blockquote></div><br>

------=_Part_5467_19477096.1125425316784--

--===============1715895151==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--===============1715895151==--

Date: Tue, 30 Aug 2005 18:57:58 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Jeffrey Haas <[email-masked]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
Mail-Copies-To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

regards,

Date: Tue, 30 Aug 2005 18:43:17 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Enke Chen <[email-masked]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
Mail-Copies-To: [email-masked]
Cc: Inter-Domain Routing List <[email-masked]>
Sender: [email-masked]

regards,

Date: Tue, 30 Aug 2005 18:39:54 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Jeffrey Haas <[email-masked]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
Mail-Copies-To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

regards,

Date: Tue, 30 Aug 2005 13:10:58 -0400
From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
Sender: [email-masked]

Two comments:

-- 
Jeff Haas 
NextHop Technologies

Date: Tue, 30 Aug 2005 19:36:49 +0530
From: Maneesh Chawla <[email-masked]>
To: [email-masked]
Subject: [Idr] BGP Communities
Sender: [email-masked]

--===============0954988643==
Content-Type: multipart/alternative; 
	boundary="----=_Part_1007_5968081.1125410809575"

------=_Part_1007_5968081.1125410809575
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi All,
 I am pretty new to this.I have 2 questions on this :
 1. Is it possible to receive a route from the internet with "reserved=20
communities" set on the route ?
 If yes,
 2. Should an implementation have provision to configure community list wit=
h=20
"reserved communities" , though not to set the communities but atleast to=
=20
match routes that have those communities in them ?
 Thanks
Maneesh

------=_Part_1007_5968081.1125410809575
Content-Type: text/html; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

<div>Hi All,</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I am pret=
ty new to this.I have 2 questions on this :</div>
<div>&nbsp;</div>
<div>1. Is it possible to receive a route from the internet with &quot;rese=
rved communities&quot; set on the route ?</div>
<div>&nbsp;</div>
<div>If yes,</div>
<div>&nbsp;</div>
<div>2. Should an implementation have provision to configure community list=
 with &quot;reserved communities&quot; , though not to set the communities =
but atleast to match routes that have those communities in them ?</div>

<div>&nbsp;</div>
<div>Thanks</div><span class=3D"sg">
<div>Maneesh</div></span>

------=_Part_1007_5968081.1125410809575--

--===============0954988643==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--===============0954988643==--

Date: Sun, 28 Aug 2005 23:49:46 +0530
From: Glen Kent <[email-masked]>
To: Enke Chen <[email-masked]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
Cc: Inter-Domain Routing List <[email-masked]>
Sender: [email-masked]

--===============0040739514==
Content-Type: multipart/alternative; 
	boundary="----=_Part_4464_33088343.1125253186597"

------=_Part_4464_33088343.1125253186597
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

> My understanding is that the editor (Geoff) has received two=20

------=_Part_4464_33088343.1125253186597
Content-Type: text/html; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

<div><span class=3D"gmail_quote">&gt; My understanding is that the editor (=
Geoff) has received two <br>&gt; implementation reports. So we can expect t=
o see the report really soon.</span></div>
<div><span class=3D"gmail_quote"></span>&nbsp;</div>
<div><span class=3D"gmail_quote">Is it Redback and now, Cisco? ;-)</span></=
div>
<div><span class=3D"gmail_quote"></span>&nbsp;</div>
<div><span class=3D"gmail_quote">Glen.</span></div>
<p><span class=3D"gmail_quote">&nbsp;</span></p>
<div><br>&nbsp;</div>

------=_Part_4464_33088343.1125253186597--

--===============0040739514==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--===============0040739514==--

Date: Sun, 28 Aug 2005 11:11:10 -0700
From: Enke Chen <[email-masked]>
To: Glen Kent <[email-masked]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
Cc: Inter-Domain Routing List <[email-masked]>
Sender: [email-masked]

Hi, Glen:

-- Enke

Date: Sun, 28 Aug 2005 21:37:17 +0530
From: Glen Kent <[email-masked]>
To: Enke Chen <[email-masked]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
Cc: Inter-Domain Routing List <[email-masked]>
Sender: [email-masked]

--===============0015029558==
Content-Type: multipart/alternative; 
	boundary="----=_Part_4192_22723008.1125245237437"

------=_Part_4192_22723008.1125245237437
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Enke Chen <[email-masked]> wrote:=20
>=20
>=20

 I went through the IDR mail archives (circa 2001 and early 2002) and i=20
didnt come across any active discussion regarding the 4-byte AS draft. Did =
i=20
miss something?
 BTW, which vendors have actually implemented this feature?
 Glen

------=_Part_4192_22723008.1125245237437
Content-Type: text/html; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

<div><span class=3D"gmail_quote"><b class=3D"gmail_sendername">Enke Chen</b=
> &lt;<a href=3D"mailto:[email-masked]">[email-masked]</a>&gt; wrot=
e:</span>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><br>&gt; For folks that was invo=
lved in the IDR in 2001, you might remember that<br>&gt; was the original d=
esign. However, it has the flaw of carrying duplicate
<br>&gt; info even after the world has transitioned to 4-byte AS, and some =
folks<br>&gt; even suggested having a &quot;second transition&quot; to elim=
inate the 2-byte<br>&gt; as-path.&nbsp;&nbsp;So the idea was dropped.</bloc=
kquote>

<div>&nbsp;</div>
<div>I went through the IDR mail archives (circa 2001 and early 2002) and i=
 didnt come across any active discussion regarding the 4-byte AS draft. Did=
 i miss something?</div>
<div>&nbsp;</div>
<div>BTW, which vendors have actually implemented this feature?</div>
<div>&nbsp;</div>
<div>Glen</div></div>

------=_Part_4192_22723008.1125245237437--

--===============0015029558==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--===============0015029558==--

Content-class: urn:content-classes:message
Subject: RE: [Idr] draft-ietf-idr-rfc2858bis-07.txt, SAFI=3 removed?
Date: Sun, 28 Aug 2005 07:23:20 -0600
From: "Susan Hares" <[email-masked]>
To: "Pekka Savola" <[email-masked]>, <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

Pekka:

	My recollection is that Mboned discussed it.  In my early
discussion with ISPs operators during early deployments tended to put
multicast on different routers.

You are welcome to ask the chairs of mboned as well. 

Cheers, 

Sue

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Pekka Savola
Sent: Wednesday, August 24, 2005 1:48 AM
To: [email-masked]
Cc: [email-masked]
Subject: [Idr] draft-ietf-idr-rfc2858bis-07.txt, SAFI=3 removed?

Hi,

On Tue, 23 Aug 2005 [email-masked] wrote:
> http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2858bis-07.txt

Has the removal of "both unicast and multicast" in MP-BGP update been 
reviewed by multicast communities?

(Personally, I haven't verified what happens when I advertise all our 
BGP prefixes as identically for both unicast and multicast; does that 
result in two sets of prefixes for SAFI=1, then SAFI=2 or just 
SAFI=3..)

-- 
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: "Manav Bhatia" <[email-masked]>
To: <[email-masked]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
Date: Sun, 28 Aug 2005 09:07:00 +0530
Sender: [email-masked]

Manav

----- Original Message ----- 
From: "Manav Bhatia" <[email-masked]>
To: "Enke Chen" <[email-masked]>
Cc: "Inter-Domain Routing List" <[email-masked]>; "Paul Jakma" <[email-masked]>
Sent: Friday, August 26, 2005 11:35 PM
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?

fixed

Date: Sun, 28 Aug 2005 00:31:17 +0300 (EEST)
From: Pekka Savola <[email-masked]>
To: Bill Fenner <[email-masked]>
Cc: [email-masked]
Subject: [Idr] Re: draft-ietf-idr-rfc2858bis-07.txt, SAFI=3 removed?
Sender: [email-masked]

On Fri, 26 Aug 2005, Bill Fenner wrote:
> The implementation report showed 2 implementations that implement SAFI
> 3 for receive-only (presumably they would apply the update to individual
> SAFI 2 and SAFI 1 RIBs and advertise it seperately when propogating) and
> 3 implementations that do not implement SAFI 3.  Features that have not
> been implemented need to be removed when going to Draft Standard (but the
> SAFI is reserved, so it would be possible to document SAFI 3 in a Proposed
> Standard if people thought it was important to have a document for).

Well, if what you say is correct, it'd be perfectly fine to document 
receive-only SAFI=3 processing in the draft standard -- two 
independent implementations are enough.

Whether that makes sense or not (I guess this mainly depends on 
whether there are believed to be implmentations which actually send 
out SAFI=3 and inteoperability should not be broken) is debatable.

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

Date: Sat, 27 Aug 2005 09:01:22 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Enke Chen <[email-masked]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
Mail-Copies-To: [email-masked]
Cc: Inter-Domain Routing List <[email-masked]>
Sender: [email-masked]

No worries.

regards,

Date: Sat, 27 Aug 2005 00:16:31 -0700
From: Enke Chen <[email-masked]>
To: Paul Jakma <[email-masked]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
Cc: Inter-Domain Routing List <[email-masked]>
Sender: [email-masked]

Regards,

-- Enke

Date: Sat, 27 Aug 2005 08:06:04 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Enke Chen <[email-masked]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
Mail-Copies-To: [email-masked]
Cc: Inter-Domain Routing List <[email-masked]>
Sender: [email-masked]

Gosh really?

?

Nice.

regards,

Date: Fri, 26 Aug 2005 23:42:33 -0700
From: Enke Chen <[email-masked]>
To: [email-masked]
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
Cc: Inter-Domain Routing List <[email-masked]>
Sender: [email-masked]

Regards,

-- Enke

Date: Sat, 27 Aug 2005 07:02:18 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Enke Chen <[email-masked]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
Mail-Copies-To: [email-masked]
Cc: Inter-Domain Routing List <[email-masked]>
Reply-To: [email-masked], Inter-Domain Routing List <[email-masked]>
Sender: [email-masked]

Hehe :)

regards,

Date: Fri, 26 Aug 2005 14:23:57 -0700
From: Enke Chen <[email-masked]>
To: Paul Jakma <[email-masked]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
Cc: Inter-Domain Routing List <[email-masked]>
Sender: [email-masked]

Hi, Paul:

[snip]

Regards,

-- Enke

Date: Fri, 26 Aug 2005 20:30:15 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Enke Chen <[email-masked]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
Mail-Copies-To: [email-masked]
Cc: Inter-Domain Routing List <[email-masked]>
Sender: [email-masked]

;)

just becomes:

regards,

Date: Fri, 26 Aug 2005 20:18:50 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Enke Chen <[email-masked]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
Mail-Copies-To: [email-masked]
Cc: Manav Bhatia <[email-masked]>, Inter-Domain Routing List <[email-masked]>
Sender: [email-masked]

regards,

 	--Ralph Wiggum

Date: Fri, 26 Aug 2005 20:14:28 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Enke Chen <[email-masked]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
Mail-Copies-To: [email-masked]
Cc: Manav Bhatia <[email-masked]>, Inter-Domain Routing List <[email-masked]>
Sender: [email-masked]

regards,

Date: Sat, 27 Aug 2005 00:06:07 +0530
From: Glen Kent <[email-masked]>
To: Manav Bhatia <[email-masked]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
Cc: Inter-Domain Routing List <[email-masked]>, Paul Jakma <[email-masked]>
Sender: [email-masked]

Glen

From: "Manav Bhatia" <[email-masked]>
To: "Enke Chen" <[email-masked]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
Date: Fri, 26 Aug 2005 23:35:00 +0530
Cc: Inter-Domain Routing List <[email-masked]>, Paul Jakma <[email-masked]>
Sender: [email-masked]

Manav

----- Original Message ----- 
From: "Enke Chen" <[email-masked]>
To: "Manav Bhatia" <[email-masked]>
Cc: "Paul Jakma" <[email-masked]>; "Curtis Villamizar"

Date: Fri, 26 Aug 2005 10:39:51 -0700
From: Enke Chen <[email-masked]>
To: Manav Bhatia <[email-masked]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
Cc: Inter-Domain Routing List <[email-masked]>, Paul Jakma <[email-masked]>
Sender: [email-masked]

Agreed.

-- Enke

From: Bill Fenner <[email-masked]>
To: Pekka Savola <[email-masked]>
Date: Fri, 26 Aug 2005 13:36:35 -0400
Versions: dmail (linux) 2.7/makemail 2.14
Cc: [email-masked], [email-masked]
Subject: [Idr] Re: draft-ietf-idr-rfc2858bis-07.txt, SAFI=3 removed?
Sender: [email-masked]

The implementation report showed 2 implementations that implement SAFI
3 for receive-only (presumably they would apply the update to individual
SAFI 2 and SAFI 1 RIBs and advertise it seperately when propogating) and
3 implementations that do not implement SAFI 3.  Features that have not
been implemented need to be removed when going to Draft Standard (but the
SAFI is reserved, so it would be possible to document SAFI 3 in a Proposed
Standard if people thought it was important to have a document for).

  Bill

Date: Fri, 26 Aug 2005 10:24:42 -0700
From: Enke Chen <[email-masked]>
To: [email-masked]
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
Cc: Inter-Domain Routing List <[email-masked]>
Sender: [email-masked]

[snip]

Regards,

-- Enke

From: "Manav Bhatia" <[email-masked]>
To: "Enke Chen" <[email-masked]>, "Paul Jakma" <[email-masked]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
Date: Fri, 26 Aug 2005 22:53:51 +0530
Cc: Inter-Domain Routing List <[email-masked]>
Sender: [email-masked]

Thanks,
Manav

----- Original Message ----- 
From: "Enke Chen" <[email-masked]>
To: "Paul Jakma" <[email-masked]>
Cc: "Curtis Villamizar" <[email-masked]>; "Manav Bhatia"

Date: Fri, 26 Aug 2005 10:14:02 -0700
From: Enke Chen <[email-masked]>
To: Paul Jakma <[email-masked]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
Cc: Manav Bhatia <[email-masked]>, Inter-Domain Routing List <[email-masked]>
Sender: [email-masked]

Regards,

-- Enke

Date: Fri, 26 Aug 2005 17:32:38 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Subject: Re: [Idr] comment on draft-ietf-idr-as4bytes-10.txt 
Mail-Copies-To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

On Tue, 23 Aug 2005, Paul Jakma wrote:

> If we could reclaim ASN 1 (Level-3 stopped using it I think) and 
> reserve it, and hence guarantee the byte sequences "0x00 0x01" and 
> "0x00 0x00"

Actually given AS1 isn't possible: any existing unused AS number will 
do, eg, AS_TRANS ;). Just have IANA assign 4-octets ASNs from the 
23456:x block at first.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Q:	What's a light-year?
A:	One-third less calories than a regular year.

Date: Fri, 26 Aug 2005 16:25:55 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Enke Chen <[email-masked]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
Mail-Copies-To: [email-masked]
Cc: Manav Bhatia <[email-masked]>, Inter-Domain Routing List <[email-masked]>
Sender: [email-masked]

True yes.

regards,

Date: Fri, 26 Aug 2005 08:17:04 -0700
From: Enke Chen <[email-masked]>
To: Paul Jakma <[email-masked]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
Cc: Manav Bhatia <[email-masked]>, Inter-Domain Routing List <[email-masked]>
Sender: [email-masked]

-- Enke

Date: Fri, 26 Aug 2005 16:08:06 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Curtis Villamizar <[email-masked]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come? 
Mail-Copies-To: [email-masked]
Cc: Manav Bhatia <[email-masked]>, Inter-Domain Routing List <[email-masked]>
Sender: [email-masked]

regards,

To: "Manav Bhatia" <[email-masked]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come? 
Date: Fri, 26 Aug 2005 11:04:49 -0400
From: Curtis Villamizar <[email-masked]>
Cc: Inter-Domain Routing List <[email-masked]>, [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

Curtis

From: "Manav Bhatia" <[email-masked]>
To: <[email-masked]>, "Inter-Domain Routing List" <[email-masked]>, "Enke Chen" <[email-masked]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
Date: Fri, 26 Aug 2005 18:50:49 +0530
Cc: 
Sender: [email-masked]

Cheers,
Manav

----- Original Message ----- 
From: "Paul Jakma" <[email-masked]>
To: "Enke Chen" <[email-masked]>
Cc: "Inter-Domain Routing List" <[email-masked]>
Sent: Friday, August 26, 2005 3:35 PM
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?

Date: Fri, 26 Aug 2005 11:05:23 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Enke Chen <[email-masked]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
Mail-Copies-To: [email-masked]
Cc: Inter-Domain Routing List <[email-masked]>
Reply-To: [email-masked], Inter-Domain Routing List <[email-masked]>
Sender: [email-masked]

Other possibilities:

regards,

Date: Fri, 26 Aug 2005 09:16:23 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Enke Chen <[email-masked]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
Mail-Copies-To: [email-masked]
Cc: Inter-Domain Routing List <[email-masked]>
Reply-To: [email-masked], Inter-Domain Routing List <[email-masked]>
Sender: [email-masked]

regards,

From: "john smith" <[email-masked]>
To: [email-masked]
Date: Thu, 25 Aug 2005 09:25:24 +0000
Subject: [Idr] any AFI/SAFI for DNS
Sender: [email-masked]

Hi,

Is there any SAFI/AFI for carrying DNS in BGP?

-JS

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar - get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/

Date: Wed, 24 Aug 2005 13:24:50 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Enke Chen <[email-masked]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
Mail-Copies-To: [email-masked]
Cc: Inter-Domain Routing List <[email-masked]>
Reply-To: [email-masked], Inter-Domain Routing List <[email-masked]>
Sender: [email-masked]

regards,

Date: Wed, 24 Aug 2005 07:38:31 -0400
From: Jeffrey Haas <[email-masked]>
To: "Jan Novak (janovak)" <[email-masked]>
Subject: Re: [Idr] draft-ietf-idr-rfc2858bis-07.txt, SAFI=3 removed?
Cc: [email-masked], Pekka Savola <[email-masked]>, [email-masked]
Sender: [email-masked]

My observation during our development of 2858-related support was
that safi 3 wasn't widely supported.

Additionally, the code may become more complicated for many reasons if you
try to use safi 3.  One simple example is if your packing is such
that you first receive a safi 1, readvertise it and then shortly afterwards
receive a safi 2.  You could then advertise a safi 2 or a safi 3.
However, the implication of advertising a safi 3 was that the safi 1
component was getting a spurious update.

IMO, safi 3 gained us far more complexity than the supposed simplification
for congruent topologies.  Good riddance. :-)

On Wed, Aug 24, 2005 at 10:31:34AM +0200, Jan Novak (janovak) wrote:
> > (Personally, I haven't verified what happens when I advertise all our 
> > BGP prefixes as identically for both unicast and multicast; does that 
> > result in two sets of prefixes for SAFI=1, then SAFI=2 or just 
> > SAFI=3..)
> 
> I think is has been abandoned because nobody ever implemented SAFI=3
> most probably because of possible problems with BGP updates
> packaging/processing when depending on both sources of 
> the prefixes - like this peer can do it, this can't, uni
> prefix has gone, mcast prefix hasn't etc.
> 
> Jan

-- 
Jeff Haas 
NextHop Technologies

Content-class: urn:content-classes:message
Subject: RE: [Idr] draft-ietf-idr-rfc2858bis-07.txt, SAFI=3 removed?
Date: Wed, 24 Aug 2005 10:31:34 +0200
From: "Jan Novak \(janovak\)" <[email-masked]>
To: "Pekka Savola" <[email-masked]>, <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

Hi, 

> (Personally, I haven't verified what happens when I advertise all our 
> BGP prefixes as identically for both unicast and multicast; does that 
> result in two sets of prefixes for SAFI=1, then SAFI=2 or just 
> SAFI=3..)

I think is has been abandoned because nobody ever implemented SAFI=3
most probably because of possible problems with BGP updates
packaging/processing when depending on both sources of 
the prefixes - like this peer can do it, this can't, uni
prefix has gone, mcast prefix hasn't etc.

Jan

Date: Wed, 24 Aug 2005 01:02:00 -0700
From: Enke Chen <[email-masked]>
To: Inter-Domain Routing List <[email-masked]>
Cc: "Enke Chen"@cisco.com
Subject: [Idr] Re: 4-Byte As Number soon to come?
Sender: [email-masked]

Hi, folks:

-- Enke

Date: Wed, 24 Aug 2005 08:47:46 +0300 (EEST)
From: Pekka Savola <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: [Idr] draft-ietf-idr-rfc2858bis-07.txt, SAFI=3 removed?
Sender: [email-masked]

Hi,

On Tue, 23 Aug 2005 [email-masked] wrote:
> http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2858bis-07.txt

Has the removal of "both unicast and multicast" in MP-BGP update been 
reviewed by multicast communities?

(Personally, I haven't verified what happens when I advertise all our 
BGP prefixes as identically for both unicast and multicast; does that 
result in two sets of prefixes for SAFI=1, then SAFI=2 or just 
SAFI=3..)

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

To: [email-masked], Inter-Domain Routing List <[email-masked]>
Subject: Re: [Idr] comment on draft-ietf-idr-as4bytes-10.txt 
Date: Wed, 24 Aug 2005 01:23:09 -0400
From: Curtis Villamizar <[email-masked]>
Cc: 
Reply-To: [email-masked]
Sender: [email-masked]

In message <[email-masked]>
Paul Jakma writes:
>  
> On Tue, 23 Aug 2005, Geoff Huston wrote:
>  
> > merits some form of correction I would interpret as a positive 
> > attribute of the specification and I would advocate leaving it as 
> > is.
>  
> Straw poll:
>  
> On the question of the current as4bytes IDR working document 
> specifying that the syntax an existing well-known attribute be 
> overriden by an OPEN capability:
>  
> - anyone in favour of leaving the draft as is in this respect?
>  
> (Enke, Geoff, ....?)

Yes.  Leave as is.  Geoff is right.  As a provider I only had a need
to snoop on a BGP session when the BGP implementation was broken and I
was also the one maintaining the code back when we were still running
BGP2 and BGP3 code.  And we did about as much statistics collection of
BGP and other stats collection based on traffic sampling as anyone.

> - anyone in favour of changing the draft to use the new attribute
>    (NEW_AS_PATH) which is specified by the draft?
>  
> (paul, ....?)
>  
> I've floated my balloon, if it goes nowhere, or in wrong direction 
> I'll leave it go :)
>  
> regards,
> -- 
> PnPBIOS is a PC specific affliction. Other platforms have more elegantly
> designed but even buggier solutions
>  

Curtis

Date: Wed, 24 Aug 2005 01:01:49 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Enke Chen <[email-masked]>
Subject: Re: [Idr] comment on draft-ietf-idr-as4bytes-10.txt
Mail-Copies-To: [email-masked]
Cc: Yakov Rekhter <[email-masked]>, [email-masked]
Sender: [email-masked]

On Tue, 23 Aug 2005, Enke Chen wrote:

> The numbers 0x00 0x00 will be common even after the transition as 
> the existing 2-byte AS number will be encoded as 0:xx where the 
> first two bytes are zero.

Yep - 0x00 0x00 will be very common and an immediate indicator of '4 
byte' encoding, if found on a 2 octet boundary (it's not a valid AS 
segment header, nor is 0x00 0x01). 0 is not a valid ASN I'm 
reasonably sure (though, havn't checked), so can't be 2-octet.

Course, latching on 0x00 0x00 will not work for AS-Path's which 
contain only 'new' ASNs, Hence we'd need 0x00 0x01 to be reserved in 
2-octet space.

> I just checked Dave Meyer's route-view. AS 1 is still in the routing table.

Ah, oh dear. Who originates it and what? Level3 had deprecated it a 
good while ago I thought, and were slowly decommisioning it.

> However, one interesting stats from that route-view: it seems that 
> 99.9% of the as-path entries consists of just AS_SEQUENCE. For 
> these as-path entries, we can easily tell 2-byte vs 4-byte from the 
> attribute length and seglen (which is the number of AS numbers):

Sadly, not quite.

> attribute_len = segtype (1 byte) + seglen (1 byte) + as_count * AS_SIZE
>
> where as_count is the value in seglen field.

This assumes there is only one segment though, Eg, try:

0x02 0x03 0x00 0x19 0x01 0x56 0x00 0x0c 0x02 0x02 0x00 0x41 0xc9 0x89

Is that a single AS_SEQUENCE segment with 3 4-octet ASN's, or is it 
two 2-octet segments after each other, first with 3 ASN's, the second 
with two?

> This equation can only be true with AS_SIZE = 2, or 4, but not both.

How did you get the data from route-view? You need to look at the raw 
data to be sure that 99.9% of paths consist of /one/ AS_SEQUENCE ;). 
(I'll admit such constructions would be highly odd and unusual though 
- but I have no figures).

Also, route-views can be an odd view of the internet. The oddness may 
be hidden from it, or simply swamped by many many multiple copies of 
more 'normal' AS_PATHs.

> So there are several options for these "standalone" tools:
>
> 1) A user configurable knob: 100% accuracy.
>
> 2) Use the attribute length and seglen: >99.9% accuracy.

If you assume single segments are 99.9%, sure - and then that is (i 
/think/) 99.9*99.9 = 98.9% probability.

Each seperate corner case lowers the probability.

> 3) Use the existence of "0x00 0x00": 100% accuracy when mappable AS exists.

When, yes.

> 4) Combine #2 and #3.
>
> 5) Combine #2 and #3, and then #1 as last resort.
>
> Do we still need more options :-)

It's a lot of heuristics to put together when the draft really just 
could say:

 	If (attribute code == NEW_AS_PATH)
             || (attribute code == NEW_AGGREGATOR)
 	  sizeof (ASN): 4 octets
         else
 	  sizeof (ASN): 2 octets

And we'd be covered 100% without resorting to 99% heuristics.

But hey. ;)

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Moderation is a fatal thing.  Nothing succeeds like excess.
 		-- Oscar Wilde

Date: Tue, 23 Aug 2005 16:21:58 -0700
From: Enke Chen <[email-masked]>
To: Paul Jakma <[email-masked]>
Subject: Re: [Idr] comment on draft-ietf-idr-as4bytes-10.txt
Cc: Yakov Rekhter <[email-masked]>, [email-masked]
Sender: [email-masked]

Hi, Paul:

[snip]

>
>
> A hopefully fair analysis:
>
> In practice, in bulk of cases it likely would be posssible to figure 
> out which encoding is used; parsing with either 2 or 4 octet encoding 
> would quickly show one encoding to be implausible (eg a byte which 
> should be length but which claims a segment extends past end of the 
> data, or because you encounter 0x00 0x00 - which could only be valid 
> for a 4-octet encoded AS_PATH, and will be common during the 
> transition period.

The numbers 0x00 0x00 will be common even after the transition as the 
existing 2-byte AS number will be encoded as 0:xx where the first two 
bytes are zero.

> One hopes OLD speakers quickly would be deprecated once the first 
> 4-octet ASN is used. Though, you have a very long comfort 'zone', at 
> least for as long as ASN-1 is not reused by Level3 or whoever owns it 
> now.).
> However, there will be AS_PATHs which will, syntactically, seem 
> plausible for either encoding. Those will require further inspection 
> (eg by checking which ASNs actually are assigned by IANA or even RIRs).
>
> Further, you won't be able to discriminate easily between whether an 
> AS_PATH is incorrectly generated or corrupted and case of having used 
> wrong ASN octet size to parse it.
>
> (Geoff, I guess, would be quick to point out that this would not be a 
> problem for the BGP speakers concerned - they know their state.)
>
> If we could reclaim ASN 1 (Level-3 stopped using it I think) and 
> reserve it, and hence guarantee the byte sequences "0x00 0x01" and 
> "0x00 0x00" would /reliably/ indicate 4-byte encoding, then we could 
> (i think) reliably distinguish between encodings, until the first 
> "0x00 0x02 .. .." ASN is handed out - which wouldn't be for 20+ years, 
> one would imagine.

I just checked Dave Meyer's route-view. AS 1 is still in the routing table.

However, one interesting stats from that route-view: it seems that 99.9% 
of the as-path entries consists of just AS_SEQUENCE. For these as-path 
entries, we can easily tell 2-byte vs 4-byte from the attribute length 
and seglen (which is the number of AS numbers):

attribute_len = segtype (1 byte) + seglen (1 byte) + as_count * AS_SIZE

where as_count is the value in seglen field.

This equation can only be true with AS_SIZE = 2, or 4, but not both.

So there are several options for these "standalone" tools:

1) A user configurable knob: 100% accuracy.

2) Use the attribute length and seglen: >99.9% accuracy.

3) Use the existence of "0x00 0x00": 100% accuracy when mappable AS exists.

4) Combine #2 and #3.

5) Combine #2 and #3, and then #1 as last resort.

Do we still need more options :-)

Regards,

-- Enke

To: [email-masked]
Subject: [Idr] I-D ACTION:draft-ietf-idr-rfc2858bis-07.txt
Date: Tue, 23 Aug 2005 13:18:27 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

The revised draft (see attached) reflects the consensus among
those who participated in the discussion on the IANA section
of the draft.

Yakov.
------- Forwarded Message

Date:    Tue, 23 Aug 2005 15:50:01 -0400
From:    [email-masked]
To:      [email-masked]
cc:      [email-masked]
Subject: [Idr] I-D ACTION:draft-ietf-idr-rfc2858bis-07.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		: Multiprotocol Extensions for BGP-4
	Author(s)	: T. Bates, et al.
	Filename	: draft-ietf-idr-rfc2858bis-07.txt
	Pages		: 12
	Date		: 2005-8-23
	
Currently BGP-4 is capable of carrying routing information only for
   IPv4. This document defines extensions to BGP-4 to enable it to carry
   routing information for multiple Network Layer protocols (e.g., IPv6,
   IPX, etc...). The extensions are backward compatible - a router that
   supports the extensions can interoperate with a router that doesn't
   support the extensions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2858bis-07.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the mess
age.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-rfc2858bis-07.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-rfc2858bis-07.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-rfc2858bis-07.txt

- --OtherAccess
Content-Type: Message/External-body; name="draft-ietf-idr-rfc2858bis-07.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

- --OtherAccess--

- --NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

- --NextPart--

------- End of Forwarded Message

To: [email-masked]
From: [email-masked]
Date: Tue, 23 Aug 2005 15:50:01 -0400
Cc: [email-masked]
Subject: [Idr] I-D ACTION:draft-ietf-idr-rfc2858bis-07.txt 
Sender: [email-masked]

--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		: Multiprotocol Extensions for BGP-4
	Author(s)	: T. Bates, et al.
	Filename	: draft-ietf-idr-rfc2858bis-07.txt
	Pages		: 12
	Date		: 2005-8-23
	
Currently BGP-4 is capable of carrying routing information only for
   IPv4. This document defines extensions to BGP-4 to enable it to carry
   routing information for multiple Network Layer protocols (e.g., IPv6,
   IPX, etc...). The extensions are backward compatible - a router that
   supports the extensions can interoperate with a router that doesn't
   support the extensions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2858bis-07.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-rfc2858bis-07.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-rfc2858bis-07.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-rfc2858bis-07.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-idr-rfc2858bis-07.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--NextPart--

Date: Tue, 23 Aug 2005 17:18:43 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Subject: Re: [Idr] comment on draft-ietf-idr-as4bytes-10.txt 
Mail-Copies-To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

On Tue, 23 Aug 2005, Yakov Rekhter wrote:

> Is it "no" just for the AS_PATH attribute, or for other attributes 
> as well ? In other words, does the issue you brining up specific to 
> the AS_PATH attribute, or not ?

It is "no" only for AS_PATH. The issue is specific to the proposed 
changes to AS_PATH.

AGGREGATOR is overloaded too in the draft, but can easily be 
differentiated based on the attribute length.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Meekness is uncommon patience in planning a worthwhile revenge.

To: Paul Jakma <[email-masked]>
Subject: Re: [Idr] comment on draft-ietf-idr-as4bytes-10.txt 
Date: Tue, 23 Aug 2005 09:13:21 -0700
From: Yakov Rekhter <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Paul,

> On Tue, 23 Aug 2005, Yakov Rekhter wrote:
> 
> > On the subject of the BGP analyser/observer issue we need to
> > look at two aspects of this issue:
> >
> > 1. Is it possible to parse the BGP stream into messages/attributes
> > without capturing the OPEN message by the analyser/observer ?
> 
> Into messages and attributes, yes.
> 
> > 2. If the answer to 1 is "yes", then is it possible to understanding
> > the information of these messages/attributes without capturing the
> > OPEN message (and specifically the Capability Advertisement part
> > of it) by the analyser/observer ?
> 
> For the AS_PATH: deterministically/reliably, no.

Is it "no" just for the AS_PATH attribute, or for other attributes
as well ? In other words, does the issue you brining up specific
to the AS_PATH attribute, or not ?

Yakov.

Date: Tue, 23 Aug 2005 16:35:38 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Subject: Re: [Idr] comment on draft-ietf-idr-as4bytes-10.txt 
Mail-Copies-To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

On Tue, 23 Aug 2005, Paul Jakma wrote:

> Reclaim and reserve ASN 1.

This would allow only updated analysers to work reliably, but I'd 
settle for that.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
One way to stop a runaway horse is to bet on him.

Date: Tue, 23 Aug 2005 16:24:06 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Subject: Re: [Idr] comment on draft-ietf-idr-as4bytes-10.txt 
Mail-Copies-To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

On Tue, 23 Aug 2005, Yakov Rekhter wrote:

> On the subject of the BGP analyser/observer issue we need to
> look at two aspects of this issue:
>
> 1. Is it possible to parse the BGP stream into messages/attributes
> without capturing the OPEN message by the analyser/observer ?

Into messages and attributes, yes.

> 2. If the answer to 1 is "yes", then is it possible to understanding
> the information of these messages/attributes without capturing the
> OPEN message (and specifically the Capability Advertisement part
> of it) by the analyser/observer ?

For the AS_PATH: deterministically/reliably, no.

A hopefully fair analysis:

In practice, in bulk of cases it likely would be posssible to figure 
out which encoding is used; parsing with either 2 or 4 octet encoding 
would quickly show one encoding to be implausible (eg a byte which 
should be length but which claims a segment extends past end of the 
data, or because you encounter 0x00 0x00 - which could only be valid 
for a 4-octet encoded AS_PATH, and will be common during the 
transition period. One hopes OLD speakers quickly would be deprecated 
once the first 4-octet ASN is used. Though, you have a very long 
comfort 'zone', at least for as long as ASN-1 is not reused by Level3 
or whoever owns it now.).

However, there will be AS_PATHs which will, syntactically, seem 
plausible for either encoding. Those will require further inspection 
(eg by checking which ASNs actually are assigned by IANA or even 
RIRs).

Further, you won't be able to discriminate easily between whether an 
AS_PATH is incorrectly generated or corrupted and case of having used 
wrong ASN octet size to parse it.

(Geoff, I guess, would be quick to point out that this would not be a 
problem for the BGP speakers concerned - they know their state.)

If we could reclaim ASN 1 (Level-3 stopped using it I think) and 
reserve it, and hence guarantee the byte sequences "0x00 0x01" and 
"0x00 0x00" would /reliably/ indicate 4-byte encoding, then we could 
(i think) reliably distinguish between encodings, until the first 
"0x00 0x02 .. .." ASN is handed out - which wouldn't be for 20+ 
years, one would imagine.

So there's another possible solution if you really don't want to 
change the draft, but do want to preserve ability to parse AS_PATH 
without additional context:

Reclaim and reserve ASN 1.

> Yakov.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Somewhere, just out of sight, the unicorns are gathering.

To: Paul Jakma <[email-masked]>
Subject: Re: [Idr] comment on draft-ietf-idr-as4bytes-10.txt 
Date: Tue, 23 Aug 2005 07:47:50 -0700
From: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

Paul,

[clipped...]

> Which leaves the BGP analyser/observer issue as only significant 
> practical issue against the draft (I think even the drafts authors 
> have conceded btw that it's a minus point. Not a plus point: 
> ambiguity != security ;). However the authors obviously do not agree 
> with me that the extent of this issue is worth worrying about.).

On the subject of the BGP analyser/observer issue we need to
look at two aspects of this issue:

1. Is it possible to parse the BGP stream into messages/attributes
without capturing the OPEN message by the analyser/observer ?

2. If the answer to 1 is "yes", then is it possible to understanding
the information of these messages/attributes without capturing the
OPEN message (and specifically the Capability Advertisement part
of it) by the analyser/observer ?

Yakov.

Date: Tue, 23 Aug 2005 01:43:42 -0400 (EDT)
From: Tulip Rasputin <[email-masked]>
Subject: RE: [Idr] comment on draft-ietf-idr-as4bytes-10.txt  - errata
To: Inter-Domain Routing List <[email-masked]>
Sender: [email-masked]

> 
> With this proposal, such proposals 
                           ^^^^^^^^^
I meant "applications"

> would atleast parse the AS_PATH attribute. This would not
> yield
> correct results but would atleast give some meaningful result.
> 
> - Tulip
> 
> 
> 
> 	
> 
> 	
> 		
> __________________________________________________________ 
> Find your next car at http://autos.yahoo.ca
> 

		
__________________________________________________________ 
Find your next car at http://autos.yahoo.ca

Date: Tue, 23 Aug 2005 01:05:15 -0400 (EDT)
From: Tulip Rasputin <[email-masked]>
Subject: RE: [Idr] comment on draft-ietf-idr-as4bytes-10.txt 
To: Inter-Domain Routing List <[email-masked]>
Sender: [email-masked]

I am concerned for the applications that are asked to observe a BGP stream mid flow.

It would suffice if there are ways with which such applications could, by looking at the update
messages determine, the kind of ASN(s) used in the sessions or carried in the path attributes
without having parsed the OPEN message.

> 
> - anyone in favour of leaving the draft as is in this respect?
> 
> (Enke, Geoff, ....?)

The above point leaves me a little uncomfortable.

> 
> - anyone in favour of changing the draft to use the new attribute
>    (NEW_AS_PATH) which is specified by the draft?
> 
> (paul, ....?)

With this proposal, such proposals would atleast parse the AS_PATH attribute. This would not yield
correct results but would atleast give some meaningful result.

- Tulip

		
__________________________________________________________ 
Find your next car at http://autos.yahoo.ca

Date: Tue, 23 Aug 2005 03:35:56 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Geoff Huston <[email-masked]>
Subject: re: [Idr] comment on draft-ietf-idr-as4bytes-10.txt 
Mail-Copies-To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

On Tue, 23 Aug 2005, Geoff Huston wrote:

>> - A NEW speaker passes a route with an OLD path to a NEW speaker

> But section 5.1 of the draft says that the NEW speaker MUST pass 
> AS_PATH to the NEW peer as 4-bytes - I'm not sure I understand the 
> reference to "OLD path" in this context, so I may need some help 
> here in picking up your point.

The draft provides for AS_PATH being rewritten. In the above, the 
'OLD' path would come from an OLD speaker with a 2-octet AS_PATH. 
That would, when sent to a NEW peer, be rewritten into a 4-octet 
AS_PATH.

That potentially could invalidate any signatures made directly of 
information in the AS_PATH.

> As I've noted above, I'm not precisely sure what point you are 
> driving at here (that may be my fault - sorry)

Probably mine. ;) Hopefully above makes it clearer.

> - if your point is that singing the AS Path is a topic that is 
> being actively studied now and this is one more addition to their 
> agenda for consideration, then I'd agree, as would the RPSEC 
> working group I guess.

Right.

However, thinking again, An obvious way to deal with it would be for 
any such solution to not sign segment data directly, but sign an 
abstracted version of path-derived data that could be reconstructed 
from AS_PATH.

> If you are saying that there is a solution out there for signing AS 
> paths and this disrupts such a solution then I'm not sure I follow 
> you, as I'm not sure that I see such AS Path signing solutions in 
> place as yet.

Ah, no. I wasn't trying to suggest a solution existed yet ;). Sorry. 
:)

> If you are addressing the actual resource certificates then its my 
> (crude) understanding that the mappable AS would be described as 2 
> octet values and the remainder of the 4-byte AS set would be 
> described as 4 octet values.

Ok, that'd work fine likely. And my concern is withdrawn.

> Again I'm pretty sure that I'm not of the same page as you here, 
> and I don't understand your point - sorry.

Given your paragraph immediately previous, it's therefore likely not 
a problem at all - never mind.

Which leaves the BGP analyser/observer issue as only significant 
practical issue against the draft (I think even the drafts authors 
have conceded btw that it's a minus point. Not a plus point: 
ambiguity != security ;). However the authors obviously do not agree 
with me that the extent of this issue is worth worrying about.).

I'd like to have the draft changed. IMHO, there isn't really that 
much of an installed base or even implementation to justify leaving 
this nit in the draft.

But that's my opinion, I'll rest my case.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Hate the sin and love the sinner.
 		-- Mahatma Gandhi

Date: Tue, 23 Aug 2005 12:04:52 +1000
To: Paul Jakma <[email-masked]>
From: Geoff Huston <[email-masked]>
Subject: re: [Idr] comment on draft-ietf-idr-as4bytes-10.txt 
Cc: [email-masked]
Sender: [email-masked]

>However, with the current draft, it may defeat any kind of mechanism that 
>attempts to provide signatures of an AS_PATH. The current draft provides 
>for the AS_PATH to be rewritten when:
>
>- A NEW speaker passes a route with an OLD path to a NEW speaker

But section 5.1 of the draft says that the NEW speaker MUST pass AS_PATH to 
the NEW peer as
4-bytes - I'm not sure I understand the reference to "OLD path" in this 
context, so I may need some help here in picking up your point.

>- A NEW speaker must send a route with a 4-octet AS_PATH to an OLD
>   speaker

As the draft points out there are two cases here - "mappable" AS numbers, 
where the
4-byte AS value can be converted to a 2-byte by stripping off the high 
order 16 butes and
the "un-mappable" AS numbers - where the transition 2-Byte AS value is 
placed in the AS-PATH and the original 4-byte value is used in NEW_AS_PATH. 
Again I'm not sure I follow your line of argument here.

>This affects the transition period, even if no ASN's are using 4-octet 
>numbers yet.
>
>So any mechanisms that want to get involved in signing AS_PATH's are going 
>to have learn about when an AS_PATH is not what an AS_PATH used to be (and 
>when an AS_PATH that isn't then becomes what it was, and so on).

As I've noted above, I'm not precisely sure what point you are driving at 
here (that may be my fault - sorry) - if your point is that singing the AS 
Path is a topic that is being actively studied now and this is one more 
addition to their agenda for consideration, then I'd agree, as would the 
RPSEC working group I guess. If you are saying that there is a solution out 
there for signing AS paths and this disrupts such a solution then I'm not 
sure I follow you, as I'm not sure that I see such AS Path signing 
solutions in place as yet.

If you are addressing the actual resource certificates then its my (crude) 
understanding that the mappable AS would be described as 2 octet values and 
the remainder of the 4-byte AS set would be described as 4 octet values. 
Again I'm pretty sure that I'm not of the same page as you here, and I 
don't understand your point - sorry.

regards,

    Geoff

Date: Tue, 23 Aug 2005 02:25:00 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Inter-Domain Routing List <[email-masked]>
Subject: re: [Idr] comment on draft-ietf-idr-as4bytes-10.txt 
Mail-Copies-To: [email-masked]
Cc: 
Reply-To: [email-masked], Inter-Domain Routing List <[email-masked]>
Sender: [email-masked]

On Tue, 23 Aug 2005, Geoff Huston wrote:

> merits some form of correction I would interpret as a positive 
> attribute of the specification and I would advocate leaving it as 
> is.

Straw poll:

On the question of the current as4bytes IDR working document 
specifying that the syntax an existing well-known attribute be 
overriden by an OPEN capability:

- anyone in favour of leaving the draft as is in this respect?

(Enke, Geoff, ....?)

- anyone in favour of changing the draft to use the new attribute
   (NEW_AS_PATH) which is specified by the draft?

(paul, ....?)

I've floated my balloon, if it goes nowhere, or in wrong direction 
I'll leave it go :)

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
PnPBIOS is a PC specific affliction. Other platforms have more elegantly
designed but even buggier solutions

Date: Tue, 23 Aug 2005 02:02:33 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Geoff Huston <[email-masked]>
Subject: re: [Idr] comment on draft-ietf-idr-as4bytes-10.txt 
Mail-Copies-To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

On Tue, 23 Aug 2005, Geoff Huston wrote:

> / 4byte world.  The question in my mind in thinking about this 
> motivation is why would I necessarily want to make eavesdropping on 
> the wire by third parties easier to undertake?

First let me note that most BGP speakers which secure their sessions 
do so to /authenticate/ the sessions, they typically do not 
additionally encrypt the data for confidentiality (ie a 'secured' BGP 
session is still monitorable, nearly always).

Reasons to want to observe a BGP stream:

- unintrusive collection of statistics
- IDS
- operational debugging

I might be strange, but fact that many switches offer 'port mirror' 
capabilities makes me think I might not be /that/ strange in this 
respect generally, don't know about BGP though.

> In other words what Paul interprets as a problem in the 
> specification that merits some form of correction I would interpret 
> as a positive attribute of the specification and I would advocate 
> leaving it as is.

There is no positive attribute though. BGP sessions typically want 
authentication, not confidentiality - your point doesn't apply.

Also, you gave a presentation at GRO on need for BGP security 
(path/prefix attestation of some kind particularly).

However, with the current draft, it may defeat any kind of mechanism 
that attempts to provide signatures of an AS_PATH. The current draft 
provides for the AS_PATH to be rewritten when:

- A NEW speaker passes a route with an OLD path to a NEW speaker

- A NEW speaker must send a route with a 4-octet AS_PATH to an OLD
   speaker

This affects the transition period, even if no ASN's are using 
4-octet numbers yet.

So any mechanisms that want to get involved in signing AS_PATH's are 
going to have learn about when an AS_PATH is not what an AS_PATH used 
to be (and when an AS_PATH that isn't then becomes what it was, and 
so on).

> By the way I am _really_ pleased to learn of work on an 
> implementation of this spec in another BGP implementation - this is 
> very heartening to hear!

I intend to complete implementation of 4bytes-ASN, however I think 
it's a shame we have to leave this nit in the draft.

Note that I also think the way this draft is currently is not 
conducive to implementation. Eg, our (Quagga) current aspath 
constructing/deconstructing/updating/checking code has 0 notion of 
what a peer is:

 	$ grep 'struct peer' bgp_aspath.c
 	$

Sadly, that nice modularity (ok, it's not the cleanest code, but at 
least it /was/ modular), may have to disappear to some extent.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
It is the wisdom of crocodiles, that shed tears when they would devour.
 		-- Francis Bacon

Date: Tue, 23 Aug 2005 10:12:58 +1000
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: re: [Idr] comment on draft-ietf-idr-as4bytes-10.txt 
Cc: [email-masked]
Sender: [email-masked]

Paul wrote

 > I am curious why you chose to overload the syntax of the
 > existing AS_PATH attribute according to whether two peers are or > are 
not 4byte ASN capable?
 >
 > My primary concern of this aspect of the draft is that it will
 > become impossible to parse AS_PATH without external reference.
 > This would have implications for protocol analysers which are
 > asked to observe a BGP session in mid-flow (they'll have no way
 > of parsing AS_PATH) and also for 'old' analysers which are asked
 > to observe a session between new peers (at best, such an
 > analyser would produce syntactically incorrect results), as well
 > as implications for modularity of code in BGP implementations.
 >
 > Would it maybe be better to leave the syntax of AS_PATH alone
 > and simply mandate NEW_AS_PATH be used for 4byte ASN and AS_PATH
 > for 2byte (you could even make AS_PATH optional and NEW_AS_PATH > 
well-known between new speakers, so that AS_PATH slowly dies out
 > during the transition period)?

So lets understand precisely what is going on here:

1 - there is no problem identified in this posting when looking at the 
situation of a BGP peering session. The BGP speaker knows its own state 
(NEW or OLD) and establishes the state of its peer at the time of the OPEN, 
and this information is used to guide what the BGP speaker will place in 
the AS_PATH and how it will interpret what is in the received AS_PATH. So 
if you are implementing the 4 byte draft as a BGP speaker than this posting 
does not identify any issues associated with the specification itself. At 
all times the BGP speaker can deterministically interpret the AS-PATH 
attribute.

2 - If a BGP speaker outputs an update log or a dump, then there is still 
no problem here - the BGP speaker presumably has an internal representation 
of AS's that are either 2-byte (OLD) or 4-byte) NEW (although thats an 
implementation detail beyond the scope of the specification) and presumably 
will consistently report according to the internal format. Again as far as 
I can see this posting does not identify any issues associated with the 
specification itself.

3 - So what I see is that a) if you chose NOT to encrypt your BGP session 
and b) if you allow eavesdroppers into the BGP session and c) the 
eavesdropper is not able to capture the entire BGP session, then Paul is 
observing that there is  the potential for confusion on the part of the 
eavesdropper when interpreting the BGP update conversation as the update 
does not contain enough information to decode the AS PATH as either a 
sequence of 2 byte or a sequence of 4 byte values. Paul has then proposed 
changes to the draft in the light of this

I would question the underlying premises of this motivation for this change 
- under what circumstances would I be deploying BGP eavesdroppers, as 
distinct from getting the BGP speakers themselves to provide the session 
information I'm after? And if its my eavesdropper then surely I can 
configure the eavesdropper to let it know how to interpret what its seeing. 
Or maybe set up a common community attribute to trigger my eavesdropper to 
interpret the AS_PATH a certain way? So as I see it what Paul is advocating 
is making interpretation of BGP sessions on the wire easier for third party 
eaverdroppers to perform in a 2byte / 4byte world.  The question in my mind 
in thinking about this motivation is why would I necessarily want to make 
eavesdropping on the wire by third parties easier to undertake?

In other words what Paul interprets as a problem in the specification that 
merits some form of correction I would interpret as a positive attribute of 
the specification and I would advocate leaving it as is.

By the way I am _really_ pleased to learn of work on an implementation of 
this spec in another BGP implementation - this is very heartening to hear!

regards,

    Geoff  Huston

From: "Alok" <[email-masked]>
To: "Inter-Domain Routing List" <[email-masked]>
Subject: Re: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.txt
Date: Mon, 22 Aug 2005 17:52:24 +0530
Sender: [email-masked]

I wonder why too :-)

Wonder why they have an open WG at all when they do not want to take things
forward

>
> Strange.
>
> If this is the case, then why do we still have such 'drafts' for which
we're too late to comment
> on still in the "draft" stage and hanging off the IDR WG shelf for review?
>
> Why dont we take them off and publish 'em as RFCs and standards?
>
> Tulip
>
>

Date: Mon, 22 Aug 2005 22:19:34 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Enke Chen <[email-masked]>
Subject: Re: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.txt
Mail-Copies-To: [email-masked]
Cc: Inter-Domain Routing List <[email-masked]>, [email-masked]
Sender: [email-masked]

On Mon, 22 Aug 2005, Enke Chen wrote:

> Just FYI - There are at least two implementations, and the 
> implementation report is being worked on (see the IDR WG minutes).

Ok, I didn't remember that. But it was there in the doc status 
update.

FWIW, my comments arise directly of out of attempting to implement 
this draft.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Married men should forget their mistakes; there's no use in two people
remembering the same thing!

To: [email-masked]
Subject: Re: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.txt
Date: Mon, 22 Aug 2005 15:49:35 -0400
From: Bill Fenner <[email-masked]>
Versions: dmail (linux) 2.6d/makemail 2.10
Sender: [email-masked]

>...Particularly one marked still with intended status of experimental:
>
>https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=6498

Paul,

  Looks like you found a bug in the I-D Database interface -- as4bytes
doesn't have any intended status recorded, so it seems to have defaulted
to Experimental, but it's indeed intended to be Standards track.

  Bill

Date: Mon, 22 Aug 2005 20:49:04 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Enke Chen <[email-masked]>
Subject: Re: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.txt
Mail-Copies-To: [email-masked]
Cc: Inter-Domain Routing List <[email-masked]>, [email-masked]
Sender: [email-masked]

On Mon, 22 Aug 2005, Enke Chen wrote:

> You will be surprised. AFAIK there are at least hundreds of routers 
> in the field that supports the 4-byte AS.

Ah, by far more than I would have thought. However, still 
insignificant to the number of routers which still need to be 
upgraded to support this draft. ;)

> Just FYI - There are at least two implementations, and the implementation 
> report is being worked on (see the IDR WG minutes).

Ok, well, if you have a look at the changes I suggested (some of 
which apply to either 'method') there is another consideration, see 
security consideration:

Overloading AS_PATH very likely will be, during a transition period, 
incompatible with any future BGP security specification which 
attempts to attest AS_PATH.

However, if you do not overload AS_PATH, you do still have the 
possibility of having AS_PATH attestation working. (NEW speakers can 
originate and attest to authenticity of both).

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
I always turn to the sports pages first, which record people's accomplishments.
The front page has nothing but man's failures.
 		-- Chief Justice Earl Warren

Date: Mon, 22 Aug 2005 12:34:09 -0700
From: Enke Chen <[email-masked]>
To: [email-masked], Inter-Domain Routing List <[email-masked]>
Subject: Re: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.txt
Cc: [email-masked]
Sender: [email-masked]

Paul Jakma wrote:

> On Mon, 22 Aug 2005, Enke Chen wrote:
>
>> To change the encoding and mandating the NEW_AS_PATH, we would have 
>> to deprecate and re-allocate all the code points, including 4-byte AS 
>> Capability, NEW_AS_PATH, and NEW_AGGREGATOR in order to not break 
>> existing deployments.
>
>
> Exactly how many existing non-laboratory deployments are there? :) Do 
> I need one or two hands to count them on, if any at all? :)

You will be surprised. AFAIK there are at least hundreds of routers in 
the field that supports the 4-byte AS.

Just FYI - There are at least two implementations, and the 
implementation report is being worked on (see the IDR WG minutes).

Regards,

-- Enke

Date: Mon, 22 Aug 2005 20:19:03 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Enke Chen <[email-masked]>
Subject: Re: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.txt
Mail-Copies-To: [email-masked]
Cc: Inter-Domain Routing List <[email-masked]>, [email-masked]
Reply-To: [email-masked], Inter-Domain Routing List <[email-masked]>
Sender: [email-masked]

On Mon, 22 Aug 2005, Enke Chen wrote:

> To change the encoding and mandating the NEW_AS_PATH, we would have 
> to deprecate and re-allocate all the code points, including 4-byte 
> AS Capability, NEW_AS_PATH, and NEW_AGGREGATOR in order to not 
> break existing deployments.

Exactly how many existing non-laboratory deployments are there? :) Do 
I need one or two hands to count them on, if any at all? :)

Breaking drafts, if for a good reason, is quite possible. 
Particularly one marked still with intended status of experimental:

 	https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=6498

or not?

> Based on our discussion it seems to me that the differences between 
> re-using the AS_PATH attribute or the NEW_AS_PATH attribute for new 
> peers are mainly the following:  (Let us call the proposals P1 and 
> P2 respectively)

>   1) "standalone" tools:
>        P1:  would require a new parameter to parse UPDATES for a new 
> session.
>                old tool works for old peers.
>                old tool would generate error in parsing UPDATES for a new 
> session.

That is the "at best" result. Much worse could occur, particularly in 
tools which are not well-designed, from crashes to vulnerabilities 
(far fetched in this case, granted but not impossible).

>                P2:  no new parameter is needed to parse an UPDATE for a new 
> session.
>                old tool works for old peers.
>                old tool flags new update as "fatal error - missing AS_PATH", 
> and no useful AS_PATH info.

Or just continues on parsing the other attributes. The tool need not 
be attempting to validate the UPDATE.

>  2) At the end of transition:
>
>        P1:  possibly reclaim NEW_AS_PATH, NEW_AGGREGATOR.
>        P2:  possibly reclaim AS_PATH,  AGGREGATOR.

I'm not sure how you could reclaim either, least not any time soon. 
But no difference either way, no.

> These differences seem to be minor, and I do not think they are compelling 
> enough for us to change the encoding at this late stage.

Conceptually, it's not minor. Overloading is simply quite ugly. It is 
going to be a stain on the BGP protocol for as long as the version == 
4. As a matter of practicality, it's likely not going to make any 
difference to common BGP speakers, agreed, but it is going to have an 
effect on tools and their users ("So, exactly what am I supposed to 
do with that ASN-size knob again?").

So I'd say this depends on existing implementation and deployment. 
And a month ago at GRO there was only one known /implementation/. ;)

If there are no deployments, it is quite possible to address this 
matter. It's A very small nit in a way yes, but it's still easy to 
polish out at this stage, so why not?

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
"Bye, witches! Thanks for not eating me!"

 	--Ralph Wiggum
 	  Treehouse of Horror VIII (Episode 5F02)

Date: Mon, 22 Aug 2005 11:28:00 -0700
From: Enke Chen <[email-masked]>
To: [email-masked], Inter-Domain Routing List <[email-masked]>
Subject: Re: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.txt
Cc: [email-masked]
Sender: [email-masked]

Hi, Paul:

Thanks - but I hope it will not be needed :-)

To change the encoding and mandating the NEW_AS_PATH, we would have to 
deprecate and re-allocate all the code points, including 4-byte AS 
Capability, NEW_AS_PATH, and NEW_AGGREGATOR in order to not break 
existing deployments.

Based on our discussion it seems to me that the differences between 
re-using the AS_PATH attribute or the NEW_AS_PATH attribute for new 
peers are mainly the following:  (Let us call the proposals P1 and P2 
respectively)

    1) "standalone" tools:
         P1:  would require a new parameter to parse UPDATES for a new 
session.
                 old tool works for old peers.
                 old tool would generate error in parsing UPDATES for a 
new session.
         
         P2:  no new parameter is needed to parse an UPDATE for a new 
session.
                 old tool works for old peers.
                 old tool flags new update as "fatal error - missing 
AS_PATH", and no useful AS_PATH info.

   2) At the end of transition:

         P1:  possibly reclaim NEW_AS_PATH, NEW_AGGREGATOR.
         P2:  possibly reclaim AS_PATH,  AGGREGATOR.

These differences seem to be minor, and I do not think they are 
compelling enough for us to change the encoding at this late stage.

Regards,

-- Enke
 
Paul Jakma wrote:

> Hi Enke,
>
> See:
>
>     http://hibernia.jakma.org/~paul/as4bytes.diff
>
> for the changes I would like to see made to the draft.
>
> (For full version see: 
> http://hibernia.jakma.org/~paul/draft-ietf-idr-as4bytes-11.txt)
>
> regards,

To: Tulip Rasputin <[email-masked]>
Subject: Re: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.txt 
Date: Mon, 22 Aug 2005 13:58:46 -0400
From: Curtis Villamizar <[email-masked]>
Cc: Inter-Domain Routing List <[email-masked]>, Paul Jakma <[email-masked]>
Reply-To: [email-masked]
Sender: [email-masked]

In message <[email-masked]>
Tulip Rasputin writes:
>  
> > One general comment first: The 4-byte AS scheme was spec'ed in 2001 
> > after several design iterations (particular on transition). The spec has 
> > been stable for more than four years.  As I understand, there have been 
> > more than one implementations, and some have been deployed for years.  
> > As of last IETF, the implementation report is already under way.  At 
> > this stage the issue you pointed out on using old  tools over  4-byte  
> > peers does not seem to be significant enough for us to consider a change 
> > on the attribute to carry the AS_PATH info. You are 4-5 years too late :-)
>  
> Strange. 
>  
> If this is the case, then why do we still have such 'drafts' for which
> we're too late to comment on still in the "draft" stage and hanging
> off the IDR WG shelf for review?
>  
> Why dont we take them off and publish 'em as RFCs and standards?
>  
> Tulip

We got here because IESG refused to advance anything until RFC1771 got
updated.  What we are doing is dusting them drafts off and advancing
them now that the bottleneck (rfc1771 update) has cleared.

Curtis

To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Date: Mon, 22 Aug 2005 12:10:28 -0400
Cc: [email-masked]
Subject: [Idr] Last Call: 'BGP Route Reflection - An Alternative to Full Mesh IBGP' to Draft Standard 
Reply-To: [email-masked]
Sender: [email-masked]

The IESG has received a request from the Inter-Domain Routing WG to consider 
the following document:

- 'BGP Route Reflection - An Alternative to Full Mesh IBGP '
   <draft-ietf-idr-rfc2796bis-01.txt> as a Draft Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2005-09-05.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2796bis-01.txt

Implementation Report can be accessed at
http://www.ietf.org/IESG/Implementations/RFC2796-implementations.txt

Date: Mon, 22 Aug 2005 15:53:28 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Enke Chen <[email-masked]>
Subject: Re: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.txt
Mail-Copies-To: [email-masked]
Cc: Inter-Domain Routing List <[email-masked]>, [email-masked]
Reply-To: [email-masked], Inter-Domain Routing List <[email-masked]>
Sender: [email-masked]

Hi Enke,

See:

 	http://hibernia.jakma.org/~paul/as4bytes.diff

for the changes I would like to see made to the draft.

(For full version see: 
http://hibernia.jakma.org/~paul/draft-ietf-idr-as4bytes-11.txt)

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Everything can be filed under "miscellaneous".

Date: Mon, 22 Aug 2005 14:19:31 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Enke Chen <[email-masked]>
Mail-Copies-To: [email-masked]
Cc: Inter-Domain Routing List <[email-masked]>, [email-masked]
Subject: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.txt
Sender: [email-masked]

On Mon, 22 Aug 2005, Paul Jakma wrote:

> There will always be two transitions, you can't avoid it.
>
> NEW -> OLD: You'll have to check AS_PATH isn't 4byte, and rewrite it
> OLD -> NEW:
> 	- NEW_AS_PATH present: Cross-check with AS_PATH and 'merge'
> 		               to get full path information

To clarify: The above is how the current draft specifies things.

I would propose:

NEW -> OLD: synthesise AS_PATH if required (or add your ASN as
             normal)
NEW <- OLD: 'merge' NEW_AS_PATH if present, as current draft
 	    specifies

NEW -> NEW:
 	Originate:
 		- NEW_AS_PATH contains canonical path information
 		- AS_PATH is optional, prefered to not include it
 	  	  implementation /MAY/ originate it (eg because some
 		  kind of secure BGP may be deployed which requires
 	          AS_PATH to be maintained, while OLD world still
 	          exists)
 	Pass on:
 		- NEW_AS_PATH -> add yourself to path
 		- AS_PATH (if present only) -> add your mapped ASN to path

NEW <- NEW: NEW_AS_PATH mandatory, AS_PATH discretionary
 	- NEW_AS_PATH is loop checked, it is the canonical
 	  information
 	- AS_PATH is checked for consistency with NEW_AS_PATH
 	  (taking mapping into account)
 	  if not consistent: Invalid UPDATE, ignore

So during the transition period we would see both attributes, and 
we'd have to do extra work at the boundaries between OLD and NEW.

Eventually, when everyone is NEW, the only thing we should see is 
NEW_AS_PATH (and NEW_AGGREGATOR).

Ancillary BGP tools continue to work during transition, whether they 
know of NEW_AS_PATH or not. None will produce garbage, none will need 
user-specified knobs in order to decide how to parse *_PATH 
information, they can use the attribute type code as is normal in 
parsing attributes.

> software will simply continue to work. It may not give you a full picture 
> anymore, becase BGP has been extended, but it will still give you 
> semantically correct results.

Syntactically even. And the semantics also stand a chance of coming 
across (eg AS_PATH between NEW->OLD or OLD-OLD would have full 
hop-count information, even if NEW_AS_PATH is present. The path 
itself may be semantically correct, particularly if there are no 
AS_TRANS numbers in it, and even then a human can still recognise 
AS_TRANS for what it is).

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
A citizen of America will cross the ocean to fight for democracy, but
won't cross the street to vote in a national election.
 		-- Bill Vaughan

Content-class: urn:content-classes:message
Subject: RE: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.txt
Date: Mon, 22 Aug 2005 07:15:34 -0600
From: "Susan Hares" <[email-masked]>
To: "Enke Chen" <[email-masked]>
Cc: Inter-Domain Routing List <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

Enke:

Thanks for your note.  My understanding is given the implementation
experience you feel that the benefits of the current draft outweigh any 
Encoding issues.

Sue

-----Original Message-----
From: Enke Chen [mailto:[email-masked]] 
Sent: Monday, August 22, 2005 1:31 AM
To: Susan Hares
Cc: [email-masked]; Inter-Domain Routing List; [email-masked]; Enke Chen
Subject: Re: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.txt

Hi, Sue:

Please see my reply to Paul on some of the considerations (after digging

out some old notes).

In terms of implementation and customer experience, a couple things come

to my mind:

Using the AS_PATH attribute across has the advantage of being able to 
continue using the "as-path" list policy and displaying the "as-path", 
etc, and avoid supporting "new-as-path" in addition to "as-path" in the 
configuation.

As the NEW_AS_PATH is optional, the check for the required attribute 
portion remains unchanged. (As I mentioned earlier, one of the 
considerations was to avoid introducing another "mandatory" attribute. 
This follows the trandition that new attributes have all been "optional"

after RFC 1771).

-- Enke

Susan Hares wrote:

>Enke:
>
>After implementing the 4-Byte AS specification, do you think the
>avoidance of the new attribute justifies the confusion in the AS PATH
>syntax?
>
>Sue
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Enke Chen
>Sent: Friday, August 19, 2005 1:34 PM
>To: [email-masked]; Inter-Domain Routing List
>Cc: [email-masked]
>Subject: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.txt
>
>Hi, Paul:
>
>Thanks for your comments. My comments are inlined.
>
>Paul Jakma wrote:
>
>  
>
>>Hi,
>>
>>Some comments regarding your draft-ietf-idr-as4bytes-10.txt text:
>>
>>I am curious why you chose to overload the syntax of the existing 
>>AS_PATH attribute according to whether two peers are or are not 4byte 
>>ASN capable?
>>
>>My primary concern of this aspect of the draft is that it will become 
>>impossible to parse AS_PATH without external reference. This would 
>>have implications for protocol analysers which are asked to observe a 
>>BGP session in mid-flow (they'll have no way of parsing AS_PATH) and 
>>also for 'old' analysers which are asked to observe a session between 
>>new peers (at best, such an analyser would produce syntactically 
>>incorrect results), as well as implications for modularity of code in 
>>BGP implementations.
>>    
>>
>
>
>These protocol analysis tools need to be augmented to support the
4-byte
>
>AS numbers regardless. Without the knowledge of whether the 4-byte AS 
>capability is supported over a session,  there are a couple of options 
>for the tools:
>
>     o introduce a button/knob to allow a user to specify whether the 
>session is doing 4-byte or 2-byte.
>     o or parse the AS_PATH using 2-byte encoding first, if there is an

>error, parse it using the 4-byte encoding (this may not be as robust as

>the previous one).
>
>  
>
>>Would it maybe be better to leave the syntax of AS_PATH alone and 
>>simply mandate NEW_AS_PATH be used for 4byte ASN and AS_PATH for 2byte
>>    
>>
>
>  
>
>>(you could even make AS_PATH optional and NEW_AS_PATH well-known 
>>between new speakers, so that AS_PATH slowly dies out during the 
>>transition period)?
>>    
>>
>
>
>One of the consideration was to avoid mandating another attribute.
Also
>
>it seems to be more consistent to use the AS_PATH attribute across the 
>board.
>
>Regards,
>
>-- Enke
> 
>

Date: Mon, 22 Aug 2005 13:41:54 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Enke Chen <[email-masked]>
Subject: Re: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.txt
Mail-Copies-To: [email-masked]
Cc: Susan Hares <[email-masked]>, Inter-Domain Routing List <[email-masked]>, [email-masked]
Sender: [email-masked]

On Sun, 21 Aug 2005, Enke Chen wrote:

> Using the AS_PATH attribute across has the advantage of being able 
> to continue using the "as-path" list policy and displaying the 
> "as-path", etc, and avoid supporting "new-as-path" in addition to 
> "as-path" in the configuation.

Using NEW_AS_PATH instead does /not/ imply you have to change the 
user interface.

The user continues to work with 'as-path', all that changes is a 
behind-the-curtain implementation detail of how that information is 
represented on the wire. (with a new attr code, so what ;) ).

> As the NEW_AS_PATH is optional, the check for the required 
> attribute portion remains unchanged. (As I mentioned earlier, one 
> of the considerations was to avoid introducing another "mandatory" 
> attribute. This follows the trandition that new attributes have all 
> been "optional" after RFC 1771).

You *are* introducing a new well-known and mandatory attribute 
though. Worse, it has the same type code as an existing attribute, 
but with a different and incompatible syntax. And similar with 
AGGREGATOR.

You're also introducing two additional 'temporary' attributes, 
NEW_AS_PATH and NEW_AGGREGATOR, which after the transition period 
will simply no longer be used anywhere on the internet.

The sensible thing to do is to /not/ overload existing attributes and 
make full use of the new attributes you introduce.

I disagree this makes life more difficult for NEW<->OLD scenarios, 
issues are same really.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
All phone calls are obscene.
 		-- Karen Elizabeth Gordon

Date: Mon, 22 Aug 2005 13:33:28 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Enke Chen <[email-masked]>
Mail-Copies-To: [email-masked]
Cc: Inter-Domain Routing List <[email-masked]>, [email-masked]
Subject: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.txt
Sender: [email-masked]

On Sun, 21 Aug 2005, Enke Chen wrote:

> Hi, Paul:
>
> One general comment first: The 4-byte AS scheme was spec'ed in 2001 
> after several design iterations (particular on transition). The 
> spec has been stable for more than four years.  As I understand, 
> there have been more than one implementations, and some have been 
> deployed for years.

As I understand it, there's one implementation I've heard mentioned 
by name (at the GRO WG), and there's a possible second 
implementation, which I've not heard anyone mention by name. Indeed, 
at GRO (i think), Bill Fenner was only aware of one implementation. 
But by time of IDR WG, people seemed to know of two.

I am intending to add a 3rd implementation (Quagga), but it was in 
starting to do so that I ran into the 'external reference' problem: 
You have to push knowledge of peer capabilities all the way down into 
your AS_PATH parsing code (which is slightly icky).

Now, /my/ as-path parsing is icky too, so i have to go clean it up. 
And I'd really much much rather key the decision whether to parse 
with 2 or 4 byte ASNs with information local to the attribute (ie the 
attribute type).

> As of last IETF, the implementation report is already under way.

I must have missed that. What I heard at the last IETF was "we need 
implementations".

> At this stage the issue you pointed out on using old tools over 
> 4-byte peers does not seem to be significant enough for us to 
> consider a change on the attribute to carry the AS_PATH info. You 
> are 4-5 years too late :-)

That's a shame.

> On the technical details, I dig up some old notes, and found out 
> that we actually discussed the idea of using the AS_PATH attribute 
> between old peers, and using of the NEW_AS_PATH attribute between 
> new peers.  The scheme would work - however the idea was dropped, 
> and primarily because of the following considerations based on my 
> recollection (Yakov, Qv and other - please correct me for any 
> inaccuracies):
>
>    o Only one transition. If both the AS_PATH attribute and the NEW_AS_PATH 
> were carried, a second transition would be necessary to get rid of one of 
> them.

There will always be two transitions, you can't avoid it.

NEW -> OLD: You'll have to check AS_PATH isn't 4byte, and rewrite it
OLD -> NEW:
 	- NEW_AS_PATH present: Cross-check with AS_PATH and 'merge'
 		               to get full path information

>    o Minimize/eliminate duplicate and inconsistent info.  Between the new 
> peers if the NEW_AS_PATH were made mandatory, and the AS_PATH optional, then 
> we would have to deal with the scenario that both attributes are present, and 
> possibly inconsistent.

You already have this scenario with OLD->NEW peers in the current 
draft though. For OLD->NEW you must deal with it. For NEW->NEW (if 
NEW is mandatory and AS_PATH is discretionary) you can simply 
cross-check and it can be an error condition (for that UPDATE anyway) 
for them to not be consistent.

However, the only reason I can think of for NEW peers to originate 
AS_PATH (if the draft specified NEW_AS_PATH between NEW always) would 
be if some kind of per-peer AS_PATH signature solution were deployed. 
Hence they should be capable of it, but it should not be the default 
imho.

Essentially, yes: there's extra work to do - during the transition 
period. And within the NEW world there'd simply be /no/ need for 
AS_PATH. The only reason to originate it to NEW peers would be to 
allow, eg, S-BGP to be deployed in an OLD and NEW world.

> More comments are inlined.

> Even if we mandated the use of the NEW_AS_PATH attribute, the old 
> tool would still not work for new peers (that is, would not produce 
> correct result) as the AS_PATH attribute would not exist and would 
> be flagged as a fatal error. (Assuming that AS_PATH and NEW_AS_PATH 
> would not be carried at the same time for the purpose of avoiding a 
> second transition.)

The old tool will still produce syntactically correct results if 
AS_PATH is present though between NEW peers and not overloaded. If it 
isn't present, the tool won't try parse it.

However, if AS_PATH syntax is overloaded as in the current draft, the 
tool will, in the best case, produce an error or pure garbage.

> It is not clear to me if there is an issue here: old tools would 
> continue to work for old sessions, and the tools need to be updated 
> to analyze new peers anyway.

Yes, they need to be updated anyway. If you overload AS_PATH they 
*definitely* need to be updated. Even if updated, the tool will have 
no way to reliably tell whether AS_PATH is 2 or 4 bytes, unless it 
captured the OPEN.

And this isn't just about tools, it's about modularity too. It simply 
will be impossible to decode an AS_PATH attribute without having the 
context of a peer (and its capabilities particularly).

>>>    o introduce a button/knob to allow a user to specify whether the 
>>> session is doing 4-byte or 2-byte.

> The first approach seems to be very reasonable, and should be 
> simple to do.

It still causes 'OLD' analysers to either produce utter gibberish or 
worse, crash - that could be an issue for IDS' btw, though one hopes 
an IDS would be robust. If you don't overload AS_PATH, then all 
existing BGP decoding software will simply continue to work. It may 
not give you a full picture anymore, becase BGP has been extended, 
but it will still give you semantically correct results.

> Another consideration was to minimize changes to the protocol.

And redefining the syntax of an existing and well-known attribute 
constitutes a 'minimal change'? As opposed to extending BGP with a 
new attribute (which you must introduce anyway for the transition 
period) and deprecating the existing attribute.

> BTW, Geoff Huston has recently written a nice article on the AS number, which 
> includes some discussions on various alternatives. Here is a pointer:
>
>    http://www.potaroo.net/ispcol/2005-08/as.html

Aye, saw it. Very interesting and good article.

So it's impossible to change this draft then?

A real shame, as I don't really see any difference between 
overloading AS_PATH or using NEW_AS_PATH other than that latter 
doesn't have the unfortunate property of making AS_PATH unparseable 
without external reference.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Whistler's Law:
 	You never know who is right, but you always know who is in charge.

Date: Sun, 21 Aug 2005 22:30:35 -0700
From: Enke Chen <[email-masked]>
To: Susan Hares <[email-masked]>
Subject: Re: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.txt
Cc: Inter-Domain Routing List <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

Hi, Sue:

Please see my reply to Paul on some of the considerations (after digging 
out some old notes).

In terms of implementation and customer experience, a couple things come 
to my mind:

Using the AS_PATH attribute across has the advantage of being able to 
continue using the "as-path" list policy and displaying the "as-path", 
etc, and avoid supporting "new-as-path" in addition to "as-path" in the 
configuation.

As the NEW_AS_PATH is optional, the check for the required attribute 
portion remains unchanged. (As I mentioned earlier, one of the 
considerations was to avoid introducing another "mandatory" attribute. 
This follows the trandition that new attributes have all been "optional" 
after RFC 1771).

-- Enke

Susan Hares wrote:

>Enke:
>
>After implementing the 4-Byte AS specification, do you think the
>avoidance of the new attribute justifies the confusion in the AS PATH
>syntax?
>
>Sue
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Enke Chen
>Sent: Friday, August 19, 2005 1:34 PM
>To: [email-masked]; Inter-Domain Routing List
>Cc: [email-masked]
>Subject: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.txt
>
>Hi, Paul:
>
>Thanks for your comments. My comments are inlined.
>
>Paul Jakma wrote:
>
>  
>
>>Hi,
>>
>>Some comments regarding your draft-ietf-idr-as4bytes-10.txt text:
>>
>>I am curious why you chose to overload the syntax of the existing 
>>AS_PATH attribute according to whether two peers are or are not 4byte 
>>ASN capable?
>>
>>My primary concern of this aspect of the draft is that it will become 
>>impossible to parse AS_PATH without external reference. This would 
>>have implications for protocol analysers which are asked to observe a 
>>BGP session in mid-flow (they'll have no way of parsing AS_PATH) and 
>>also for 'old' analysers which are asked to observe a session between 
>>new peers (at best, such an analyser would produce syntactically 
>>incorrect results), as well as implications for modularity of code in 
>>BGP implementations.
>>    
>>
>
>
>These protocol analysis tools need to be augmented to support the 4-byte
>
>AS numbers regardless. Without the knowledge of whether the 4-byte AS 
>capability is supported over a session,  there are a couple of options 
>for the tools:
>
>     o introduce a button/knob to allow a user to specify whether the 
>session is doing 4-byte or 2-byte.
>     o or parse the AS_PATH using 2-byte encoding first, if there is an 
>error, parse it using the 4-byte encoding (this may not be as robust as 
>the previous one).
>
>  
>
>>Would it maybe be better to leave the syntax of AS_PATH alone and 
>>simply mandate NEW_AS_PATH be used for 4byte ASN and AS_PATH for 2byte
>>    
>>
>
>  
>
>>(you could even make AS_PATH optional and NEW_AS_PATH well-known 
>>between new speakers, so that AS_PATH slowly dies out during the 
>>transition period)?
>>    
>>
>
>
>One of the consideration was to avoid mandating another attribute.  Also
>
>it seems to be more consistent to use the AS_PATH attribute across the 
>board.
>
>Regards,
>
>-- Enke
> 
>

Date: Sun, 21 Aug 2005 22:26:18 -0700
From: Enke Chen <[email-masked]>
To: Tulip Rasputin <[email-masked]>
Subject: Re: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.txt
Cc: Inter-Domain Routing List <[email-masked]>, Paul Jakma <[email-masked]>
Sender: [email-masked]

Tulip Rasputin wrote:

>>One general comment first: The 4-byte AS scheme was spec'ed in 2001 
>>after several design iterations (particular on transition). The spec has 
>>been stable for more than four years.  As I understand, there have been 
>>more than one implementations, and some have been deployed for years.  
>>As of last IETF, the implementation report is already under way.  At 
>>this stage the issue you pointed out on using old  tools over  4-byte  
>>peers does not seem to be significant enough for us to consider a change 
>>on the attribute to carry the AS_PATH info. You are 4-5 years too late :-)
>>    
>>
>
>Strange. 
>
>If this is the case, then why do we still have such 'drafts' for which we're too late to comment
>on still in the "draft" stage and hanging off the IDR WG shelf for review?
>  
>

I did not say "too late for comment".  It is just too late to change 
encoding.

>Why dont we take them off and publish 'em as RFCs and standards?
>  
>

That was the plan, and should happen soon.

-- Enke

Date: Mon, 22 Aug 2005 01:22:07 -0400 (EDT)
From: Tulip Rasputin <[email-masked]>
Subject: Re: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.txt
To: Enke Chen <[email-masked]>, Paul Jakma <[email-masked]>
Cc: Inter-Domain Routing List <[email-masked]>
Sender: [email-masked]

> One general comment first: The 4-byte AS scheme was spec'ed in 2001 
> after several design iterations (particular on transition). The spec has 
> been stable for more than four years.  As I understand, there have been 
> more than one implementations, and some have been deployed for years.  
> As of last IETF, the implementation report is already under way.  At 
> this stage the issue you pointed out on using old  tools over  4-byte  
> peers does not seem to be significant enough for us to consider a change 
> on the attribute to carry the AS_PATH info. You are 4-5 years too late :-)

Strange. 

If this is the case, then why do we still have such 'drafts' for which we're too late to comment
on still in the "draft" stage and hanging off the IDR WG shelf for review?

Why dont we take them off and publish 'em as RFCs and standards?

Tulip

Date: Sun, 21 Aug 2005 22:00:03 -0700
From: Enke Chen <[email-masked]>
To: Paul Jakma <[email-masked]>
Cc: Inter-Domain Routing List <[email-masked]>, [email-masked]
Subject: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.txt
Sender: [email-masked]

Hi, Paul:

One general comment first: The 4-byte AS scheme was spec'ed in 2001 
after several design iterations (particular on transition). The spec has 
been stable for more than four years.  As I understand, there have been 
more than one implementations, and some have been deployed for years.  
As of last IETF, the implementation report is already under way.  At 
this stage the issue you pointed out on using old  tools over  4-byte  
peers does not seem to be significant enough for us to consider a change 
on the attribute to carry the AS_PATH info. You are 4-5 years too late :-)

On the technical details, I dig up some old notes, and found out that we 
actually discussed the idea of using the AS_PATH attribute between old 
peers, and using of the NEW_AS_PATH attribute between new peers.  The 
scheme would work - however the idea was dropped, and primarily because 
of the following considerations based on my recollection (Yakov, Qv and 
other - please correct me for any inaccuracies):

     o Only one transition. If both the AS_PATH attribute and the 
NEW_AS_PATH were carried, a second transition would be necessary to get 
rid of one of them.
     o Minimize/eliminate duplicate and inconsistent info.  Between the 
new peers if the NEW_AS_PATH were made mandatory, and the AS_PATH 
optional, then we would have to deal with the scenario that both 
attributes are present, and possibly inconsistent.

More comments are inlined.

Paul Jakma wrote:

> On Fri, 19 Aug 2005, Enke Chen wrote:
>
>> These protocol analysis tools need to be augmented to support the 
>> 4-byte AS numbers regardless.
>
>
> Yes they would indeed. But by overloading AS_PATH you turn the case of 
> an old analyser showing syntactically correct values, eg:
>
>     AS_PATH <AS_TRANS>
>
> or simply not finding an AS_PATH at all if it isn't there, into it 
> showing complete gibberish.

Even if we mandated the use of the NEW_AS_PATH attribute, the old tool 
would still not work for new peers (that is, would not produce correct 
result) as the AS_PATH attribute would not exist and would be flagged as 
a fatal error.  (Assuming that AS_PATH and NEW_AS_PATH would not be 
carried at the same time for the purpose of avoiding a second transition.)

>
> Then there is the second issue, which would affect both 'new' and 
> 'old' analysers, which is that it will be impossible to analyse a BGP 
> stream and be able to reliably interpret AS_PATH without having 
> observed the OPEN. Because the only time the information as to which 
> kind of overloaded AS_PATH is being sent is present on the wire will 
> be at OPEN.
>
> This would be an issue during the transition period particularly, 
> where there would be no safe default assumption one could make of what 
> size ASN's are used in an AS_PATH.

It is not clear to me if there is an issue here: old tools would 
continue to work for old sessions, and the tools need to be updated to 
analyze new peers anyway.

>
>> Without the knowledge of whether the 4-byte AS capability is 
>> supported over a session, there are a couple of options for the tools:
>
>
>>    o introduce a button/knob to allow a user to specify whether the 
>> session is doing 4-byte or 2-byte.
>>    o or parse the AS_PATH using 2-byte encoding first, if there is an 
>> error, parse it using the 4-byte encoding (this may not be as robust 
>> as the previous one).
>
>
> Not sure either of these are ideal. I'd concur that latter could not 
> be done reliably: I'm reasonably sure you could construct a byte 
> stream which, syntactically, would be both a valid 2 and 4 byte AS_PATH.

The first approach seems to be very reasonable, and should be simple to do.

>
>> One of the consideration was to avoid mandating another attribute.
>
>
> But the draft must anyway, NEW_AS_PATH. So given it can not be 
> avoided, let's use it properly :).
>
>> Also it seems to be more consistent to use the AS_PATH attribute 
>> across the board.
>
>
> I'd say it's more consistent to *not* overload the on-wire syntax of 
> an existing attribute (particularly not according to a once-off 
> capability negotation), and just use the old for 2byte and the new for 
> 4byte.
>
> Indeed, add a 'ASN bytes' field to the NEW_AS_PATH so we never, ever, 
> ever, have to worry about sizeof (ASN) again ;).

Another consideration was to minimize changes to the protocol.

BTW, Geoff Huston has recently written a nice article on the AS number, 
which includes some discussions on various alternatives. Here is a pointer:

     http://www.potaroo.net/ispcol/2005-08/as.html

Regards,

-- Enke

Date: Sun, 21 Aug 2005 18:10:51 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Susan Hares <[email-masked]>
Subject: RE: [Idr] comment on draft-ietf-idr-as4bytes-10.txt
Mail-Copies-To: [email-masked]
Cc: Inter-Domain Routing List <[email-masked]>, Russ White <[email-masked]>
Sender: [email-masked]

On Sun, 21 Aug 2005, Susan Hares wrote:

> Did you ever answer his original concept - that we should create a "new
> AS path" attribute?

Well, the draft as it stands /does/ create a NEW_AS_PATH, but only 
for purpose of propogating 4byte ASNs across OLD speakers. Between 
NEW speakers the existing AS_PATH type is used, but overloaded to 
4byte format.

I'd rather simply see AS_PATH stay 2 byte and NEW_AS_PATH always used 
for 4byte. I'm hacking on the draft at moment to reflect this opinion 
of mine ;).

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Someone thought The Big Red Button was a light switch.

Content-class: urn:content-classes:message
Subject: RE: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.txt
Date: Sun, 21 Aug 2005 11:04:53 -0600
From: "Susan Hares" <[email-masked]>
To: "Enke Chen" <[email-masked]>, <[email-masked]>, "Inter-Domain Routing List" <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

Enke:

After implementing the 4-Byte AS specification, do you think the
avoidance of the new attribute justifies the confusion in the AS PATH
syntax?

Sue

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Enke Chen
Sent: Friday, August 19, 2005 1:34 PM
To: [email-masked]; Inter-Domain Routing List
Cc: [email-masked]
Subject: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.txt

Hi, Paul:

Thanks for your comments. My comments are inlined.

Paul Jakma wrote:

> Hi,
>
> Some comments regarding your draft-ietf-idr-as4bytes-10.txt text:
>
> I am curious why you chose to overload the syntax of the existing 
> AS_PATH attribute according to whether two peers are or are not 4byte 
> ASN capable?
>
> My primary concern of this aspect of the draft is that it will become 
> impossible to parse AS_PATH without external reference. This would 
> have implications for protocol analysers which are asked to observe a 
> BGP session in mid-flow (they'll have no way of parsing AS_PATH) and 
> also for 'old' analysers which are asked to observe a session between 
> new peers (at best, such an analyser would produce syntactically 
> incorrect results), as well as implications for modularity of code in 
> BGP implementations.

These protocol analysis tools need to be augmented to support the 4-byte

AS numbers regardless. Without the knowledge of whether the 4-byte AS 
capability is supported over a session,  there are a couple of options 
for the tools:

     o introduce a button/knob to allow a user to specify whether the 
session is doing 4-byte or 2-byte.
     o or parse the AS_PATH using 2-byte encoding first, if there is an 
error, parse it using the 4-byte encoding (this may not be as robust as 
the previous one).

>
> Would it maybe be better to leave the syntax of AS_PATH alone and 
> simply mandate NEW_AS_PATH be used for 4byte ASN and AS_PATH for 2byte

> (you could even make AS_PATH optional and NEW_AS_PATH well-known 
> between new speakers, so that AS_PATH slowly dies out during the 
> transition period)?

One of the consideration was to avoid mandating another attribute.  Also

it seems to be more consistent to use the AS_PATH attribute across the 
board.

Regards,

-- Enke

Content-class: urn:content-classes:message
Subject: RE: [Idr] comment on draft-ietf-idr-as4bytes-10.txt
Date: Sun, 21 Aug 2005 11:01:52 -0600
From: "Susan Hares" <[email-masked]>
To: "Russ White" <[email-masked]>, <[email-masked]>, "Inter-Domain Routing List" <[email-masked]>
Cc: 
Sender: [email-masked]

Russ:

Ok - that option requires extended communities - another overloading of
syntax. 

Did you ever answer his original concept - that we should create a "new
AS path" attribute?

Sue

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Russ White
Sent: Friday, August 19, 2005 11:23 AM
To: [email-masked]; Inter-Domain Routing List
Subject: Re: [Idr] comment on draft-ietf-idr-as4bytes-10.txt

Another option is to store the path in extended communities, as in 
draft-ward...

:-)

Russ

Paul Jakma wrote:
> Hi,
> 
> Some comments regarding your draft-ietf-idr-as4bytes-10.txt text:
> 
> I am curious why you chose to overload the syntax of the existing 
> AS_PATH attribute according to whether two peers are or are not 4byte 
> ASN capable?
> 
> My primary concern of this aspect of the draft is that it will become 
> impossible to parse AS_PATH without external reference. This would
have 
> implications for protocol analysers which are asked to observe a BGP 
> session in mid-flow (they'll have no way of parsing AS_PATH) and also 
> for 'old' analysers which are asked to observe a session between new 
> peers (at best, such an analyser would produce syntactically incorrect

> results), as well as implications for modularity of code in BGP 
> implementations.
> 
> Would it maybe be better to leave the syntax of AS_PATH alone and
simply 
> mandate NEW_AS_PATH be used for 4byte ASN and AS_PATH for 2byte (you 
> could even make AS_PATH optional and NEW_AS_PATH well-known between
new 
> speakers, so that AS_PATH slowly dies out during the transition
period)?
> regards,

- -- 
[email-masked] CCIE <>< Grace Alone

Date: Fri, 19 Aug 2005 18:47:10 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Enke Chen <[email-masked]>
Mail-Copies-To: [email-masked]
Cc: Inter-Domain Routing List <[email-masked]>, [email-masked]
Subject: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.txt
Sender: [email-masked]

On Fri, 19 Aug 2005, Enke Chen wrote:

> These protocol analysis tools need to be augmented to support the 
> 4-byte AS numbers regardless.

Yes they would indeed. But by overloading AS_PATH you turn the case 
of an old analyser showing syntactically correct values, eg:

 	AS_PATH <AS_TRANS>

or simply not finding an AS_PATH at all if it isn't there, into it 
showing complete gibberish.

Then there is the second issue, which would affect both 'new' and 
'old' analysers, which is that it will be impossible to analyse a BGP 
stream and be able to reliably interpret AS_PATH without having 
observed the OPEN. Because the only time the information as to which 
kind of overloaded AS_PATH is being sent is present on the wire will 
be at OPEN.

This would be an issue during the transition period particularly, 
where there would be no safe default assumption one could make of 
what size ASN's are used in an AS_PATH.

> Without the knowledge of whether the 4-byte AS capability is 
> supported over a session, there are a couple of options for the 
> tools:

>    o introduce a button/knob to allow a user to specify whether the session 
> is doing 4-byte or 2-byte.
>    o or parse the AS_PATH using 2-byte encoding first, if there is an error, 
> parse it using the 4-byte encoding (this may not be as robust as the previous 
> one).

Not sure either of these are ideal. I'd concur that latter could not 
be done reliably: I'm reasonably sure you could construct a byte 
stream which, syntactically, would be both a valid 2 and 4 byte 
AS_PATH.

> One of the consideration was to avoid mandating another attribute.

But the draft must anyway, NEW_AS_PATH. So given it can not be 
avoided, let's use it properly :).

> Also it seems to be more consistent to use the AS_PATH attribute 
> across the board.

I'd say it's more consistent to *not* overload the on-wire syntax of 
an existing attribute (particularly not according to a once-off 
capability negotation), and just use the old for 2byte and the new 
for 4byte.

Indeed, add a 'ASN bytes' field to the NEW_AS_PATH so we never, ever, 
ever, have to worry about sizeof (ASN) again ;).

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
You've been telling me to relax all the way here, and now you're telling
me just to be myself?
 		-- The Return of the Secaucus Seven

Date: Fri, 19 Aug 2005 10:33:52 -0700
From: Enke Chen <[email-masked]>
To: [email-masked], Inter-Domain Routing List <[email-masked]>
Cc: [email-masked]
Subject: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.txt
Sender: [email-masked]

Hi, Paul:

Thanks for your comments. My comments are inlined.

Paul Jakma wrote:

> Hi,
>
> Some comments regarding your draft-ietf-idr-as4bytes-10.txt text:
>
> I am curious why you chose to overload the syntax of the existing 
> AS_PATH attribute according to whether two peers are or are not 4byte 
> ASN capable?
>
> My primary concern of this aspect of the draft is that it will become 
> impossible to parse AS_PATH without external reference. This would 
> have implications for protocol analysers which are asked to observe a 
> BGP session in mid-flow (they'll have no way of parsing AS_PATH) and 
> also for 'old' analysers which are asked to observe a session between 
> new peers (at best, such an analyser would produce syntactically 
> incorrect results), as well as implications for modularity of code in 
> BGP implementations.

These protocol analysis tools need to be augmented to support the 4-byte 
AS numbers regardless. Without the knowledge of whether the 4-byte AS 
capability is supported over a session,  there are a couple of options 
for the tools:

     o introduce a button/knob to allow a user to specify whether the 
session is doing 4-byte or 2-byte.
     o or parse the AS_PATH using 2-byte encoding first, if there is an 
error, parse it using the 4-byte encoding (this may not be as robust as 
the previous one).

>
> Would it maybe be better to leave the syntax of AS_PATH alone and 
> simply mandate NEW_AS_PATH be used for 4byte ASN and AS_PATH for 2byte 
> (you could even make AS_PATH optional and NEW_AS_PATH well-known 
> between new speakers, so that AS_PATH slowly dies out during the 
> transition period)?

One of the consideration was to avoid mandating another attribute.  Also 
it seems to be more consistent to use the AS_PATH attribute across the 
board.

Regards,

-- Enke

Date: Fri, 19 Aug 2005 11:54:41 -0400
From: Russ White <[email-masked]>
To: [email-masked]
Subject: Re: [Idr] comment on draft-ietf-idr-as4bytes-10.txt
Cc: Inter-Domain Routing List <[email-masked]>
Sender: [email-masked]

Never mind, that draft didn't ever get published....

:-)

Russ

Russ White wrote:
> 
> Another option is to store the path in extended communities, as in 
> draft-ward...
> 
> :-)
> 
> Russ
> 
> Paul Jakma wrote:
> 
>> Hi,
>>
>> Some comments regarding your draft-ietf-idr-as4bytes-10.txt text:
>>
>> I am curious why you chose to overload the syntax of the existing 
>> AS_PATH attribute according to whether two peers are or are not 4byte 
>> ASN capable?
>>
>> My primary concern of this aspect of the draft is that it will become 
>> impossible to parse AS_PATH without external reference. This would 
>> have implications for protocol analysers which are asked to observe a 
>> BGP session in mid-flow (they'll have no way of parsing AS_PATH) and 
>> also for 'old' analysers which are asked to observe a session between 
>> new peers (at best, such an analyser would produce syntactically 
>> incorrect results), as well as implications for modularity of code in 
>> BGP implementations.
>>
>> Would it maybe be better to leave the syntax of AS_PATH alone and 
>> simply mandate NEW_AS_PATH be used for 4byte ASN and AS_PATH for 2byte 
>> (you could even make AS_PATH optional and NEW_AS_PATH well-known 
>> between new speakers, so that AS_PATH slowly dies out during the 
>> transition period)?
>>
>> regards,
> 
> 

- -- 
[email-masked] CCIE <>< Grace Alone

Date: Fri, 19 Aug 2005 11:22:56 -0400
From: Russ White <[email-masked]>
To: [email-masked], Inter-Domain Routing List <[email-masked]>
Subject: Re: [Idr] comment on draft-ietf-idr-as4bytes-10.txt
Cc: 
Sender: [email-masked]

Another option is to store the path in extended communities, as in 
draft-ward...

:-)

Russ

Paul Jakma wrote:
> Hi,
> 
> Some comments regarding your draft-ietf-idr-as4bytes-10.txt text:
> 
> I am curious why you chose to overload the syntax of the existing 
> AS_PATH attribute according to whether two peers are or are not 4byte 
> ASN capable?
> 
> My primary concern of this aspect of the draft is that it will become 
> impossible to parse AS_PATH without external reference. This would have 
> implications for protocol analysers which are asked to observe a BGP 
> session in mid-flow (they'll have no way of parsing AS_PATH) and also 
> for 'old' analysers which are asked to observe a session between new 
> peers (at best, such an analyser would produce syntactically incorrect 
> results), as well as implications for modularity of code in BGP 
> implementations.
> 
> Would it maybe be better to leave the syntax of AS_PATH alone and simply 
> mandate NEW_AS_PATH be used for 4byte ASN and AS_PATH for 2byte (you 
> could even make AS_PATH optional and NEW_AS_PATH well-known between new 
> speakers, so that AS_PATH slowly dies out during the transition period)?
> 
> regards,

- -- 
[email-masked] CCIE <>< Grace Alone

Date: Fri, 19 Aug 2005 14:44:42 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: [email-masked], [email-masked]
Mail-Copies-To: [email-masked]
Cc: Inter-Domain Routing List <[email-masked]>
Subject: [Idr] comment on draft-ietf-idr-as4bytes-10.txt
Reply-To: [email-masked], Inter-Domain Routing List <[email-masked]>
Sender: [email-masked]

Hi,

Some comments regarding your draft-ietf-idr-as4bytes-10.txt text:

I am curious why you chose to overload the syntax of the existing 
AS_PATH attribute according to whether two peers are or are not 4byte 
ASN capable?

My primary concern of this aspect of the draft is that it will become 
impossible to parse AS_PATH without external reference. This would 
have implications for protocol analysers which are asked to observe a 
BGP session in mid-flow (they'll have no way of parsing AS_PATH) and 
also for 'old' analysers which are asked to observe a session between 
new peers (at best, such an analyser would produce syntactically 
incorrect results), as well as implications for modularity of code in 
BGP implementations.

Would it maybe be better to leave the syntax of AS_PATH alone and 
simply mandate NEW_AS_PATH be used for 4byte ASN and AS_PATH for 
2byte (you could even make AS_PATH optional and NEW_AS_PATH 
well-known between new speakers, so that AS_PATH slowly dies out 
during the transition period)?

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Nearly every complex solution to a programming problem that I
have looked at carefully has turned out to be wrong.
 		-- Brent Welch

Content-Class: urn:content-classes:message
From: "Vijayanand C - CTD, Chennai." <[email-masked]>
To: <[email-masked]>
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc 
Date: Fri, 19 Aug 2005 13:01:56 +0530
Sender: [email-masked]

Using community, local pref or MED would entail carrying prefixes/NLRIs,
whereas using some form of CEASE would be a simple way which would apply for
the entire session.

 I would vote for a single draft discussing the pros and cons of all
approaches along with the recommended approach as a good start.

Regards,
Vijay
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> DECRAENE Bruno RD-CORE-ISS
> Sent: Wednesday, August 17, 2005 3:30 PM
> To: [email-masked]
> Cc: [email-masked]; FONDEVIOLE Benoit RD-CORE-ISS; DUBOIS Nicolas
> ROSI-DAS-ARI
> Subject: RE: [idr] BGP planned maintenance requirements as an 
> IDR WG doc
> 
> 
> 
> Hi Curtis, 
> 
> > From: Curtis Villamizar [mailto:[email-masked]] 
> 
> > For the benefit of your peer router some indication that its 
> > time for them to "cost out" your routes (or poison your 
> > peering in the above
> > terminology) might help.  The advantage of using a CEASE 
> > subcode is that any router that doesn't understand will just 
> > treat it as any other CEASE.  Backwards compatibility is 
> > always nice.  If both routers understand, they'd just 
> > LOCAL_PREF poison each side of the peering and then after 
> > some delay (probably best to specify a default and 
> > "configured on the local router") send MP_UNREACH for all 
> the routes.
> > A disadvantage of a CEASE subcode is that if a specific 
> > prefix went unreachable there is no longer a way to send an 
> > MP_UNREACH across the peering, unless this is made a 
> > non-fatal CEASE to be followed by another CEASE very shortly.
> > 
> > If I'm not mistaken, then all that is needed is an 
> > internet-draft with a CEASE subcode and some wording to 
> > indicate that it should be treated as non-fatal and result in 
> > both sides setting a very high LOCAL_PREF for all routes on 
> > the peering regardless of local policy.  I suggest that each 
> > router should enforce a maximum time to keep the peering 
> > after getting one of these CEASE, making sure that it is only 
> > used as a temporarily non-fatal policy override.
> 
> Thank you for you proposition which seems reasonnable to me.
> 
> There are multiple solutions to advertise the planned maintenance to
> eBGP peers. Using the "CEASE" message is one. To name a few, one could
> also use a dynamic capability, a well-known community, a specific MED
> value "MAX METRIC"... Each solution has its advantage and 
> disadvantage.
> We "just" have to agree on one; and I'm not sure to know how we should
> proceed for this. (one solution draft proposing one solution, one
> solution draft listing all reasonable solution and their pro & con, N
> solution drafts each proposition a solution, one requirement 
> draft ...)
> 
> I'd be pleased if you could contribute to this by writing an
> internet-draft describing your solution and addressing the 
> requirements.
> 
> > Lets see what other on the IDR list have to say about this as 
> > a potential solution.
> 
> 
> 
> 
>  
> > Curtis
> 
> Thanks,
> Best regards,
> Bruno 
> 
DISCLAIMER 
This message and any attachment(s) contained here are information that is confidential, proprietary to HCL Technologies 
and its customers. Contents may be privileged or otherwise protected by law. The information is solely intended for the 
individual or the entity it is addressed to. If you are not the intended recipient of this message, you are not authorized to 
read, forward, print, retain, copy or disseminate this message or any part of it. If you have received this e-mail in error, 
please notify the sender immediately by return e-mail and delete it from your computer

Content-class: urn:content-classes:message
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc 
Date: Wed, 17 Aug 2005 12:00:15 +0200
From: "DECRAENE Bruno RD-CORE-ISS" <[email-masked]>
To: <[email-masked]>
Cc: [email-masked], FONDEVIOLE Benoit RD-CORE-ISS <[email-masked]>, DUBOIS Nicolas ROSI-DAS-ARI <[email-masked]>
Sender: [email-masked]

Hi Curtis, 

> From: Curtis Villamizar [mailto:[email-masked]] 

> For the benefit of your peer router some indication that its 
> time for them to "cost out" your routes (or poison your 
> peering in the above
> terminology) might help.  The advantage of using a CEASE 
> subcode is that any router that doesn't understand will just 
> treat it as any other CEASE.  Backwards compatibility is 
> always nice.  If both routers understand, they'd just 
> LOCAL_PREF poison each side of the peering and then after 
> some delay (probably best to specify a default and 
> "configured on the local router") send MP_UNREACH for all the routes.
> A disadvantage of a CEASE subcode is that if a specific 
> prefix went unreachable there is no longer a way to send an 
> MP_UNREACH across the peering, unless this is made a 
> non-fatal CEASE to be followed by another CEASE very shortly.
> 
> If I'm not mistaken, then all that is needed is an 
> internet-draft with a CEASE subcode and some wording to 
> indicate that it should be treated as non-fatal and result in 
> both sides setting a very high LOCAL_PREF for all routes on 
> the peering regardless of local policy.  I suggest that each 
> router should enforce a maximum time to keep the peering 
> after getting one of these CEASE, making sure that it is only 
> used as a temporarily non-fatal policy override.

Thank you for you proposition which seems reasonnable to me.

There are multiple solutions to advertise the planned maintenance to
eBGP peers. Using the "CEASE" message is one. To name a few, one could
also use a dynamic capability, a well-known community, a specific MED
value "MAX METRIC"... Each solution has its advantage and disadvantage.
We "just" have to agree on one; and I'm not sure to know how we should
proceed for this. (one solution draft proposing one solution, one
solution draft listing all reasonable solution and their pro & con, N
solution drafts each proposition a solution, one requirement draft ...)

I'd be pleased if you could contribute to this by writing an
internet-draft describing your solution and addressing the requirements.

> Lets see what other on the IDR list have to say about this as 
> a potential solution.

> Curtis

Thanks,
Best regards,
Bruno 

To: [email-masked]
Subject: Re: [Idr] WG Last Call on IANA Considerations for 2858bis
Date: Tue, 16 Aug 2005 20:31:25 -0400
From: Bill Fenner <[email-masked]>
Versions: dmail (linux) 2.6d/makemail 2.10
Cc: [email-masked]
Sender: [email-masked]

>On Tue, 2005-08-16 at 14:52 -0700, Yakov Rekhter wrote:
>> Would it be sufficient if IANA documents these (current) allocations, 
>> and then manages the rest of [128-140] on FCFS basis ?
>
>No objection from my part. Is IANA ok with this ?

In my conversations with IANA, I believe they would be amenable to
this - we say that 128-140 is FCFS but document the existing
allocations (after all, if it's FCFS you can just get a number
by asking).  We can even mark the others you mention such as
130 and 131 as reserved by IANA, to put off problems with
collisions with undeployed stuff that uses them.

What about the apparent 129 conflict in your list?

  Bill

Subject: Re: [Idr] WG Last Call on IANA Considerations for 2858bis
From: Pedro Roque Marques <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Date: Tue, 16 Aug 2005 15:02:56 -0700
Cc: Bill Fenner <[email-masked]>, [email-masked]
Sender: [email-masked]

On Tue, 2005-08-16 at 14:52 -0700, Yakov Rekhter wrote:

> 
> Would it be sufficient if IANA documents these (current) allocations, 
> and then manages the rest of [128-140] on FCFS basis ?

No objection from my part. Is IANA ok with this ?

  Pedro.

To: Pedro Roque Marques <[email-masked]>
Subject: Re: [Idr] WG Last Call on IANA Considerations for 2858bis 
Date: Tue, 16 Aug 2005 14:52:23 -0700
From: Yakov Rekhter <[email-masked]>
Cc: Bill Fenner <[email-masked]>, [email-masked]
Sender: [email-masked]

Pedro,

> On Tue, 2005-08-16 at 14:26 -0700, Yakov Rekhter wrote:
> 
> > If in fact there are no used SAFI above 140, then how about
> > changing IANA FCFS to [64-140] (as to cover all the known
> > used SAFI), and changing reserved to [141-254].
> 
> I'm concerned w/ the space between 128 - 140. There are allocations
> there that are in use that i'd like to make sure IANA doesn't try to
> allocate over. I'd like to see that clarified.
>
> I think we are in rough agreement on the following:
> 
>   Have IANA manage [64 - 128] (including current allocations 64, 65,
> 66).
> 
>   Leave unused space as reserved [141 - 254]. Can be allocated in future
> to IANA, depends on future experience.
> 
> As far as the space [128 - 140],
>   I'd like to mark it as "space not managed by iana", given the presence
> of current allocations. In my previous e-mail i didn't include 130 and
> 131 but i believe these where in use at some point (or at least
> documented).

Would it be sufficient if IANA documents these (current) allocations, 
and then manages the rest of [128-140] on FCFS basis ?

Yakov.

Subject: Re: [Idr] WG Last Call on IANA Considerations for 2858bis
From: Pedro Roque Marques <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Date: Tue, 16 Aug 2005 14:47:35 -0700
Cc: Bill Fenner <[email-masked]>, [email-masked]
Sender: [email-masked]

On Tue, 2005-08-16 at 14:26 -0700, Yakov Rekhter wrote:

> If in fact there are no used SAFI above 140, then how about
> changing IANA FCFS to [64-140] (as to cover all the known
> used SAFI), and changing reserved to [141-254].

I'm concerned w/ the space between 128 - 140. There are allocations
there that are in use that i'd like to make sure IANA doesn't try to
allocate over. I'd like to see that clarified.

I think we are in rough agreement on the following:

  Have IANA manage [64 - 128] (including current allocations 64, 65,
66).

  Leave unused space as reserved [141 - 254]. Can be allocated in future
to IANA, depends on future experience.

As far as the space [128 - 140],
  I'd like to mark it as "space not managed by iana", given the presence
of current allocations. In my previous e-mail i didn't include 130 and
131 but i believe these where in use at some point (or at least
documented).

  Pedro.

To: Pedro Roque Marques <[email-masked]>
Subject: Re: [Idr] WG Last Call on IANA Considerations for 2858bis 
Date: Tue, 16 Aug 2005 14:26:50 -0700
From: Yakov Rekhter <[email-masked]>
Cc: Bill Fenner <[email-masked]>, [email-masked]
Sender: [email-masked]

Pedro,

> On Tue, 2005-08-16 at 13:49 -0700, Yakov Rekhter wrote:
> > Please indicate your preference wrt these two alternatives (or if you
> > have yet another alternative please post it to the list) as soon
> > as possible, as the deadline for comments is Aug 22.
> 
> Yakov,
> 
> This is the SAFI values that i believe are currently in use:
> 1, 2     (unicast, multicast)
> 4        (label-unicast)
> 64       (tunnel)                             [iana assigned]
> 65       (vpls)                               [iana assigned]
> 66       (mdt)                                [iana assigned]
> 128, 129 (2547 ucast, mcast)
> 129      (vr-based autodiscovery)
> 132      (rt-constrain)
> 133, 134 (flow-spec)
> 140      (l2 auto discovery ?)
> 
> I'd like to see:
> [64-127] Iana FCFS
> [128 - 160] reserved + current usage documented.
> [160 - 254] reserved to be released in future for iana.

If in fact there are no used SAFI above 140, then how about
changing IANA FCFS to [64-140] (as to cover all the known
used SAFI), and changing reserved to [141-254].

Yakov.

Subject: Re: [Idr] WG Last Call on IANA Considerations for 2858bis
From: Pedro Roque Marques <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Date: Tue, 16 Aug 2005 14:14:28 -0700
Cc: Bill Fenner <[email-masked]>, [email-masked]
Sender: [email-masked]

On Tue, 2005-08-16 at 13:49 -0700, Yakov Rekhter wrote:
> Please indicate your preference wrt these two alternatives (or if you
> have yet another alternative please post it to the list) as soon
> as possible, as the deadline for comments is Aug 22.

Yakov,

This is the SAFI values that i believe are currently in use:
1, 2     (unicast, multicast)
4        (label-unicast)
64       (tunnel)                             [iana assigned]
65       (vpls)                               [iana assigned]
66       (mdt)                                [iana assigned]
128, 129 (2547 ucast, mcast)
129      (vr-based autodiscovery)
132      (rt-constrain)
133, 134 (flow-spec)
140      (l2 auto discovery ?)

I'd like to see:
[64-127] Iana FCFS
[128 - 160] reserved + current usage documented.
[160 - 254] reserved to be released in future for iana.

  Pedro.

Date: Tue, 16 Aug 2005 17:00:14 -0400
From: Larry Blunk <[email-masked]>
To: Russ White <[email-masked]>
Subject: Re: [Idr] BGP Monitoring Protocol
Cc: [email-masked], Pedro Roque Marques <[email-masked]>, [email-masked]
Sender: [email-masked]

Russ White wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>  
>
>>>Y'all:
>>>
>>>http://www.ietf.org/internet-drafts/draft-scudder-bmp-00.txt
>>>
>>>BGP Monitoring Protocol, latest draft, posted.
>>>
>>>      
>>>
>>Russ,
>>    
>>
>
>  
>
>>grow WG seems to be working on:
>>    
>>
>
>  
>
>>http://ietf.org/internet-drafts/draft-ietf-grow-mrt-00.txt
>>
>>Any chance the 2 efforts can be coordinated / merged ?
>>It seems that the objectives are similar...
>>    
>>
>
>Yep...
>
>Glancing through the MRT spec, it looks a little different. It looks 
>like MRT is encoding, rather than transport (or did I just miss that??). 
>I would envision a working systems as something like this:
>  
>

     Yes, it primarily deals with encoding rather than transport.  There 
were some rudimentary
efforts at dealing with transport (see control types in draft).  But it 
is not fully fleshed out and
has not been implemented to my knowledge.

>- -- Router implements BMP, which just reflects BGP packets to a listener.
>- -- Listener implements some application that converts from BGP to MRT 
>format for local storage.
>
>My main concern with MRT is that it uses a different storage format for 
>each different BGP message type, which means new ones need to be defined 
>as new BGP message types are created (if they ever are). It looks like 
>the same thing for all of the other protocols, as well. Would we really 
>want to support each possible change on a router, along with the 
>processing from the received BGP format into the MRT format before 
>sending it to a monitoring station? Further, if we convert on the 
>router, are we possibly losing some information critical to security 
>systems trying to analyze traffic at a given BGP speaker?
>
>Don't know the answers myself, just asking questions.
>  
>

   The deprecated BGP type has a different subtype for each BGP message 
type, but the
newer BGP4MP type (used by Zebra/Quagga and others) simply encodes the 
entire
BGP message.

 -Larry

>:-)
>
>Russ
>
>- -- 
>[email-masked] CCIE <>< Grace Alone
>
>
>  
>

To: [email-masked]
Subject: Re: [Idr] WG Last Call on IANA Considerations for 2858bis
Date: Tue, 16 Aug 2005 13:49:19 -0700
From: Yakov Rekhter <[email-masked]>
Cc: Bill Fenner <[email-masked]>
Sender: [email-masked]

Folks,

So far we have two proposals for the IANA Consideration Section
on the table:

1. As specified in this document, the MP_REACH_NLRI and MP_UNREACH_NLRI
   attributes contain the Subsequence Address Family Identifier (SAFI)
   field. The SAFI name space is defined in this document. The IANA will
   maintain and register values for the SAFI namespace as follows. 
   
   SAFI values 1 and 2 are assigned in this document.  SAFI values
   4 through 63, 65, and 128 are to be assigned by IANA using either
   the "IETF Consensus" policy defined in RFC2434 or the "Early
   IANA Allocation" policy defined in RFC4020. SAFI values 64 and
   66 through 127 are to be assigned by IANA, using the "First  Come
   First Served" policy defined in RFC2434. SAFI values 240 through
   255 are for "private use", and are not to be assigned by IANA.
   SAFI values 0, 3, and 129 through 239 are reserved.

2.  As specified in this document, the MP_REACH_NLRI and MP_UNREACH_NLRI
    attributes contain the Subsequence Address Family Identifier (SAFI)
    field. The SAFI name space is defined in this document. The IANA will
    maintain and register values for the SAFI namespace as follows. 
    
    SAFI values 1 and 2 are assigned in this document.  SAFI values
    4 through 63, 65, and 128 are to be assigned by IANA using either
    the "IETF Consensus" policy defined in RFC2434 or the "Early
    IANA Allocation" policy defined in RFC4020. SAFI values 64 and
    66 through 239 are to be assigned by IANA, using the "First  Come
    First Served" policy defined in RFC2434. SAFI values 240 through
    254 are for "private use", and are not to be assigned by IANA.
    SAFI values 0, 3, and 129 through 239 and 255 are reserved.

The difference between the two is the size of the range for FCFS 
and for Reserved. 

Please indicate your preference wrt these two alternatives (or if you
have yet another alternative please post it to the list) as soon
as possible, as the deadline for comments is Aug 22.

Yakov.

From: "Manav Bhatia" <[email-masked]>
To: "Yakov Rekhter" <[email-masked]>
Subject: Re: [Idr] advertising more than one route to a destination
Date: Tue, 16 Aug 2005 18:07:20 +0530
Cc: [email-masked]
Sender: [email-masked]

> 
> > 2. Should the IDR WG start work on extending BGP to support
> > such applications ?
> 
> Yes

Yes.

Manav

Date: Tue, 16 Aug 2005 12:06:00 +0200
From: Olivier Bonaventure <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Subject: Re: [Idr] advertising more than one route to a destination
Cc: [email-masked], [email-masked], Cristel Pelsser <[email-masked]>
Sender: [email-masked]

Yakov,
> 
> As you know the basic BGP spec currently restricts a BGP speaker
> to advertise at most a single route to a given destination (given
> address prefix).
> 
> The purpose of this e-mail is to solicit opinions on (a) what
> applications could benefit if the above restriction is relaxed, as
> to allow a BGP speaker to advertise multiple routes to a given
> destination, and (b) whether the IDR WG should start work on extending
> BGP to support these applications.
> 
> With this in mind, please answer the following two questions:
> 
> 1. What applications could benefit from allowing a BGP speaker
> to advertise multiple routes to a destination ? 

In addition to the other applications mentionned by Enke and Paul :

* Route-server type applications such as :
  - a monitoring server that learns via iBGP sessions both the active
and candidate routes available inside an AS
  - a PCE could use such an iBGP extension to collect multiple routes to
external destinations from the RR or border routers. This will aid in
the establishment of interdomain LSPs, see
http://www.info.ucl.ac.be/~cpe/Pelsser_IPOM.pdf

* Load-balancing situations where route reflectors advertise multiple
routes to their clients to allow them to load-balance their traffic

* Fast-convergence situations where route reflectors advertise both the
best paths and alternate paths to their clients to allow them to react
quickly (i.e. without waiting for an iBGP convergence) to failures

> 2. Should the IDR WG start work on extending BGP to support
> such applications ?

Yes

Best regards,

Olivier

Date: Mon, 15 Aug 2005 18:38:23 -0400 (EDT)
From: Subhendu Ghosh <[email-masked]>
To: Russ White <[email-masked]>
Subject: Re: [Idr] BGP Monitoring Protocol
Cc: [email-masked]
Sender: [email-masked]

On Mon, 15 Aug 2005, Russ White wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Y'all:
>
> http://www.ietf.org/internet-drafts/draft-scudder-bmp-00.txt
>
> BGP Monitoring Protocol, latest draft, posted.
>
> :-)
>
> Russ
>

Needs a few line wraps for the message formats.

-- 
-rgds
sg

Date: Mon, 15 Aug 2005 15:21:03 -0700
From: David Meyer <[email-masked]>
To: Russ White <[email-masked]>
Subject: Re: [Idr] BGP Monitoring Protocol
Cc: [email-masked], Pedro Roque Marques <[email-masked]>, [email-masked]
Sender: [email-masked]

--===============0181857694==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="oyUTqETQ0mS9luUI"
Content-Disposition: inline

--oyUTqETQ0mS9luUI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 15, 2005 at 06:07:02PM -0400, Russ White wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
>=20
> >>Y'all:
> >>
> >>http://www.ietf.org/internet-drafts/draft-scudder-bmp-00.txt
> >>
> >>BGP Monitoring Protocol, latest draft, posted.
> >>
> > Russ,
>=20
> > grow WG seems to be working on:
>=20
> > http://ietf.org/internet-drafts/draft-ietf-grow-mrt-00.txt
> >=20
> > Any chance the 2 efforts can be coordinated / merged ?
> > It seems that the objectives are similar...
>=20
> Yep...
>=20
> Glancing through the MRT spec, it looks a little different. It looks=20
> like MRT is encoding, rather than transport (or did I just miss that??).=
=20
> I would envision a working systems as something like this:
>=20
> - -- Router implements BMP, which just reflects BGP packets to a listener.
> - -- Listener implements some application that converts from BGP to MRT=
=20
> format for local storage.
>=20
> My main concern with MRT is that it uses a different storage format for=
=20
> each different BGP message type, which means new ones need to be defined=
=20
> as new BGP message types are created (if they ever are). It looks like=20
> the same thing for all of the other protocols, as well. Would we really=
=20
> want to support each possible change on a router, along with the=20
> processing from the received BGP format into the MRT format before=20
> sending it to a monitoring station? Further, if we convert on the=20
> router, are we possibly losing some information critical to security=20
> systems trying to analyze traffic at a given BGP speaker?
>=20
> Don't know the answers myself, just asking questions.

	Russ,

	Both your and Pedro's points are well taken (and as such
	require more thought). And not that this should really
	gate what we eventually do, but there is quite a bit of
	code (and related analyzes) that rely on MRT format, so
	that is something else that requires some thought (to
	some extent and due to the zebra implmentation, MRT
	format became the de-facto standard). That being said,
	there is still a lot of code around that parses Cisco=20
	'sh ip bgp' format archives, which we are still
	collecting...=20

	Dave

--oyUTqETQ0mS9luUI
Content-Type: application/pgp-signature
Content-Disposition: inline

--oyUTqETQ0mS9luUI--

--===============0181857694==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--===============0181857694==--

Subject: Re: [Idr] BGP Monitoring Protocol
From: Pedro Roque Marques <[email-masked]>
To: Russ White <[email-masked]>
Date: Mon, 15 Aug 2005 15:17:46 -0700
Cc: [email-masked], [email-masked]
Sender: [email-masked]

On Mon, 2005-08-15 at 18:07 -0400, Russ White wrote:

> Yep...
> 
> Glancing through the MRT spec, it looks a little different. It looks 
> like MRT is encoding, rather than transport (or did I just miss that??). 
> I would envision a working systems as something like this:
> 
> - -- Router implements BMP, which just reflects BGP packets to a listener.
> - -- Listener implements some application that converts from BGP to MRT 
> format for local storage.
> 

What is the difference between a socket and a file ? :-)
Would help to have a single format that can be output to a "storage"
location whether it is local or remote.

At least, at the moment, i don't see the advantage in having 2 formats.

> My main concern with MRT is that it uses a different storage format for 
> each different BGP message type, which means new ones need to be defined 
> as new BGP message types are created (if they ever are). It looks like 
> the same thing for all of the other protocols, as well. Would we really 
> want to support each possible change on a router, along with the 
> processing from the received BGP format into the MRT format before 
> sending it to a monitoring station? Further, if we convert on the 
> router, are we possibly losing some information critical to security 
> systems trying to analyze traffic at a given BGP speaker?
> 
> Don't know the answers myself, just asking questions.

All valid points. Seems like these are issues for the MRT format
regardless... i.e. if message conversion is a potential concern, it
would appear to be a concern for a collector that translates a BGP
session to a MRT file as well.

  Pedro.

Date: Mon, 15 Aug 2005 18:07:02 -0400
From: Russ White <[email-masked]>
To: Pedro Roque Marques <[email-masked]>
Subject: Re: [Idr] BGP Monitoring Protocol
Cc: [email-masked], [email-masked]
Sender: [email-masked]

>>Y'all:
>>
>>http://www.ietf.org/internet-drafts/draft-scudder-bmp-00.txt
>>
>>BGP Monitoring Protocol, latest draft, posted.
>>
> Russ,

> grow WG seems to be working on:

> http://ietf.org/internet-drafts/draft-ietf-grow-mrt-00.txt
> 
> Any chance the 2 efforts can be coordinated / merged ?
> It seems that the objectives are similar...

Yep...

Glancing through the MRT spec, it looks a little different. It looks 
like MRT is encoding, rather than transport (or did I just miss that??). 
I would envision a working systems as something like this:

- -- Router implements BMP, which just reflects BGP packets to a listener.
- -- Listener implements some application that converts from BGP to MRT 
format for local storage.

My main concern with MRT is that it uses a different storage format for 
each different BGP message type, which means new ones need to be defined 
as new BGP message types are created (if they ever are). It looks like 
the same thing for all of the other protocols, as well. Would we really 
want to support each possible change on a router, along with the 
processing from the received BGP format into the MRT format before 
sending it to a monitoring station? Further, if we convert on the 
router, are we possibly losing some information critical to security 
systems trying to analyze traffic at a given BGP speaker?

Don't know the answers myself, just asking questions.

:-)

Russ

- -- 
[email-masked] CCIE <>< Grace Alone

Date: Mon, 15 Aug 2005 15:02:56 -0700
From: David Meyer <[email-masked]>
To: Pedro Roque Marques <[email-masked]>
Subject: Re: [Idr] BGP Monitoring Protocol
Cc: [email-masked], [email-masked], Russ White <[email-masked]>
Sender: [email-masked]

--===============0903743839==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="VS++wcV0S1rZb1Fb"
Content-Disposition: inline

--VS++wcV0S1rZb1Fb
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

	Pedro,

On Mon, Aug 15, 2005 at 02:50:38PM -0700, Pedro Roque Marques wrote:
> On Mon, 2005-08-15 at 17:32 -0400, Russ White wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >=20
> > Y'all:
> >=20
> > http://www.ietf.org/internet-drafts/draft-scudder-bmp-00.txt
> >=20
> > BGP Monitoring Protocol, latest draft, posted.
> >=20
>=20
> Russ,
> grow WG seems to be working on:
> http://ietf.org/internet-drafts/draft-ietf-grow-mrt-00.txt
>=20
> Any chance the 2 efforts can be coordinated / merged ?
> It seems that the objectives are similar...

	Possibly, though MRT talks about an output format, and
	BMP is talking about a way to collect the data (which
	might be output in MRT format, for example). However, the
	two are to large extent independent. For example, I may
	want to write a BGP listener that implements BMP and has
	flexible (e.g., pluggable) output formats, one of which
	may be MRT.

	Dave

--VS++wcV0S1rZb1Fb
Content-Type: application/pgp-signature
Content-Disposition: inline

--VS++wcV0S1rZb1Fb--

--===============0903743839==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--===============0903743839==--

Subject: Re: [Idr] BGP Monitoring Protocol
From: Pedro Roque Marques <[email-masked]>
To: Russ White <[email-masked]>
Date: Mon, 15 Aug 2005 14:50:38 -0700
Cc: [email-masked], [email-masked]
Sender: [email-masked]

On Mon, 2005-08-15 at 17:32 -0400, Russ White wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Y'all:
> 
> http://www.ietf.org/internet-drafts/draft-scudder-bmp-00.txt
> 
> BGP Monitoring Protocol, latest draft, posted.
> 

Russ,
grow WG seems to be working on:
http://ietf.org/internet-drafts/draft-ietf-grow-mrt-00.txt

Any chance the 2 efforts can be coordinated / merged ?
It seems that the objectives are similar...

  Pedro.

Date: Mon, 15 Aug 2005 17:32:00 -0400
From: Russ White <[email-masked]>
To: [email-masked]
Subject: [Idr] BGP Monitoring Protocol
Sender: [email-masked]

Y'all:

http://www.ietf.org/internet-drafts/draft-scudder-bmp-00.txt

BGP Monitoring Protocol, latest draft, posted.

:-)

Russ

- -- 
[email-masked] CCIE <>< Grace Alone

Date: Mon, 15 Aug 2005 10:59:38 -0700
From: Enke Chen <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Subject: Re: [Idr] advertising more than one route to a destination
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Hi, Yakov:

Yakov Rekhter wrote:

>Folks,
>
>As you know the basic BGP spec currently restricts a BGP speaker
>to advertise at most a single route to a given destination (given
>address prefix).
>
>The purpose of this e-mail is to solicit opinions on (a) what
>applications could benefit if the above restriction is relaxed, as
>to allow a BGP speaker to advertise multiple routes to a given
>destination, and (b) whether the IDR WG should start work on extending
>BGP to support these applications.
>
>With this in mind, please answer the following two questions:
>
>1. What applications could benefit from allowing a BGP speaker
>to advertise multiple routes to a destination ?
>

Two important ibgp applications:

a) for eliminating persistent route oscillations by route reflection or 
confederation.
b) for eliminating forwarding loops with ibgp multipath and route 
reflection.

> 
>
>2. Should the IDR WG start work on extending BGP to support
>such applications ?
>  
>
Yes.

-- Enke

Date: Mon, 15 Aug 2005 12:30:36 -0400
From: Jeffrey Haas <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Subject: Re: WG Last Call on IANA Considerations (was Re: [Idr] IDR WG Minutes)
Cc: [email-masked]
Sender: [email-masked]

Yakov,

On Mon, Aug 15, 2005 at 09:06:08AM -0700, Yakov Rekhter wrote:
> What is the rationale for having one range for the IETF Consensus
> policy and another range for the FCFS policy ?  In other words, why
> not have just a single block from which IANA could allocate
> either based on the IETF Consensus or on the FCFS policy ?

Just for list reference, we haven't really changed the classes of
allocations we'd be allowing.  We're tweaking the ranges.

As to why we'd want those particular classes, here's my opinion:

We want a range that says, "Here's what IETF wants".  It implies 
organizational "support" for a given mechanism.  This is the IETF
Consensus range.

We want a range that says, "If you want to do something that uses
this mechanism but don't want to get full 'IETF buy-in'", there's
another range.  This is the FCFS range.

We want a range for private experimentation.  This range has a strong
implication that "do what you want here, it probably wont work with
someone else".  This is the private range.  

I think your question is why have blocks at all?  IMO, we want to 
set aside space so that IETF has room to grow in the (unlikely) case
that FCFS gets exhausted too quickly.  It's a shared playground and
there's a limited number of marbles to give away.

> Yakov.

-- 
Jeff Haas 
NextHop Technologies

To: [email-masked]
Date: Mon, 15 Aug 2005 09:25:55 -0700
From: Yakov Rekhter <[email-masked]>
Subject: [Idr] minutes
Sender: [email-masked]

Folks,

The revised minutes have been posted (see below). 

Yakov.
------- Forwarded Message

Date:    Mon, 15 Aug 2005 12:21:20 -0400
From:    Rebecca Bunch <[email-masked]>
To:      Yakov Rekhter <[email-masked]>
Subject: Re: IETF-63 Proceedings Submission

Your proceeding submissions have been posted, please review them on line 
and send any corrections to [email-masked]. The deadline for 
submitting corrections is Monday, September 19, 2005 at 17:00 ET.

https://datatracker.ietf.org/public/proceeding_interim.cgi?meeting_num=63

Yakov Rekhter wrote:

>Hi,
>
>Attached are the IDR WG minutes.
>
>Yakov.
>---------------------------------------------------------------------
>
>IDR WG Minutes 2005.08.04 
>-------------------------
>
>Doc status
>see ppt for info
>
>Danny McPherson to finish Confed implementation report in one month.
>
>Geoff Houston to complete the implementation report for 4-octet AS 
>number space.
>
>New MIB editor see draft
>
>-------------------------
>Tony Li AS Hop count Attribute
>
>see ppt for info
>Essence: Add TTL to each prefix, decrement at AS boundary
>Drop route when TTL hits zero
>Transitive attribute
>
>Alt: Distribution Lists
>List contains ASs that can rx and cannot exclusion
>
>NOTE: NO_EXPORT and AS_HOPCOUNT can be combined
>
>Geoff Houston: is NO_EXPORT dropped or continued when combined?
>
>NOTE:  Can scope 'anycast'
>
>Geoff Houston: when aspath prepending, is that expressed in the HOP_COUNT?
>Tony Li: Decremented by one always
>
>Sue Hares: Two more ASPATHS per route? How does scaling work?
>Tony Li: In the worst case, when setting up a list you can have an 
>arbitrary  number in incl or excl list?
>
>Sue Hares: Is order semantics true but,
>
>Yakov Rekhter: An ASPATH cannot carry all AS in the internet as it
>would exceed the maximum size of the BGP Update message.
>
>Tony Li: An avg ASPATH has ~4 AS' in it so, we are going to have on avg 
>roughly two X
>
>Sue Hares: Why do you say proxy usage is diffficult in Dist List case? 
>TTL is lighter but, why choose between two? Might have both.
>
>Tony Li: From an implementors POV, it is easier to do one and not two
>
>Yakov Rekhter: The increase in number of AS' per route is not a practical 
>issue
>
>Geoff Houston: At the edge, it may work but, topology is dense and we nee
>
>Jason Schiller (UUNET): Scope - useful in subconfeds ... need  a 
>separate counter?
>
>Tony Li: Want to see draft first. Technically what is required is a 
>separate attribute but, look almost identical
>
>Geoff Houston: When comparing the two mechanisms need to look at "what is 
>going on." Distribution lists require complete knowledge of topology. 
>Problem is that you cannot insure that they do not leak. HOPCOUNT 
>does not have 'knowledge' problem but, focuses on accuracy.
>
>Sue Hares: Inclusion requires enumeration but exclusion does not
>
>Geoff Houston: HOPCOUNT allows more specifics w/ a boundary. 
>Advocates HOPCOUNT
>
>Pedro Roque: No productive compare the two. Want to select upstream 
>provider w/ targeted ext comms. HOPCOUNT might prevent this 
>technique. Most common TE technique; customers preferring transit AS' 
>per prefix. Not applicable for transit exit scenario. Two issues and 
>solutions are orthogonal but, neither solution is devalued.
>
>Chris Morrow (UUNET): proxy means "I can add" and/or "I can delete"
>
>Tony Li: Yes and not violate
>
>Chris Morrow: Will it get used if provider ignores or removes
>
>Yakov Rekhter: Who is entity that benefits from this? Which SP.
>
>Tony Li: Table size reduction is goal. One SP adds does the work but, gets 
>no benefits. Altruism or hope of it is a good reason.
>
>Geoff Houston: Zhang drafts in GROW show that altruism is bunk instead 
>self-interest. Most UPDATEs come from lower tier points. Most 
>computation happens at lower level of peering .. therefore, small 
>folks get most thrash. If "I" do this, I help my problem ... 
>therefore altruism is there for the folks that use it and tag it.
>
>David Ward: Affect Hop count?
>
>Tony Li: Not significantly as it would be longer prefixes.
>
>Enke Chen: Can we inject an AS numer as 'signature' of who adds attribute?
>
>May be added to draft. No comments
>
>-------------------------
>Zhang Renhai Entire Route Reflect
>
>Comments held until after Walton's draft
>see ppt for info
>
>-------------------------
>Walton Add Paths
>Alvaro Retana (Cisco) presenter.
>see ppt for info
>
>NOTE: RFC 3107 must be updated
>
>-------------------------
>Walton Oscillation Stop
>Alvaro Retana (Cisco) presenter
>info in same ppt as "Add Paths"
>
>George Swallow: What is frequency of oscillation?
>
>Alvaro Retana: dependent on update timer setting (MIN ADVERT INTERVAL)
>
>Combined questions for both draft authors:
>Danny (unaffiliated) - We are increasing and decreasing table size. 
>Walton's draft is more general and flexible then Zhang's.
>
>Alvaro Retana: Most of increase of table size is internal to an AS (almost all
)
>
>Zhang: I don't understand question.
>
>Zhang: Walton's draft is more general. 
>
>Alvaro Retana: NLRI will be bigger but, no impact on packing.
>
>Gargi (Cisco): Zhang's draft - must specify that you explicitly WD 
>when a nexthop changes or how to announce new NH?  How do you delete 
>the first NH?
>
>Zhang: If NH changes, just add it. To solve the problem there will 
>taken offline to email.
>
>Paul Jakma: If in ECMP case, what AS sequence? How to pass multiple 
>paths to a legacy speaker?
>
>Alvaro Retana:  Cap advert defines who can learn add_path. Other 
>applications like EBGP ECMP and propagating multiple paths will have 
>to be addressed.
>
>Alvaro Retana: Constrained scope.
>
>Pedro Roque: Although you say impact of deployment is localized.
>We need a better understanding of what impact will be. For each
>route prefix, path attrs in Adj RIB Out. Generally announcement,
>is only  when Adj-RIB-Out changes. What is expectation of propagating
>changes when inbound updates would cause outbound content. What are
>consequences?  Size of Adj-RIB-Out? What is key of Adj-RIB-Out?  etc.
>
>Alvaro Retana: Spec says send on path. Change is that we would have
>tracking of two or more paths.
>
>Yakov Rekhter: We can have as many ad hoc solutions as we want or
>a more general solution. We, as a group, should decide on a more
>general solution. We should look at potential new functionality
>once we have more than one path being advertised.
>
>Suggestion is that the authors of three proposals should find common
>solution to all problems that WG would like to address. A mailing
>list will be set up to discuss this problem and solution. On the
>IDR mailing list please identify problems.
>
>Yakov Rekhter: Do we need requirements document?
>
>Ward: No, absolutely not.
>
>-------------------------
>Dubois PM Reqmts
>
>see ppt for info
>
>Yakov Rekhter: Send note to list on whether or not we should take as a WG doc.
>
>Dubois: Earlier solution was not meeting requirements and there are 
>many possible solutions. We need a solution that fits the 
>requirements; we are not encouraging one solution over another:
>
>Ted Seely (Sprint): Why not weight traffic away from peer or 
>interface? There are other techniques that don't require change to 
>protocol.
>
>Ruediger Volk: I lose traffic when I do this technique.
>
>Ruediger Volk: The convergence problem I see is due to the previous issue 
>of config change.
>
>Jason Schiller (UUNET): Is there a hard requirement that this does 
>not require a config change ... taken to the list.
>
>-------------------------
>Hares Dynamic Confed AS
>
>Not requested to be WG item.
>see ppt for info
>
>Roque: I would assume that you would want to do restoration in a 
>seamless way. What is motivation to make failure restoration a 
>visible outside the confederation?
>
>Sue Hares: Goal is to not drop the peering session. Therefore, the purpose 
>is policy rerouting wants to 'hang by itself.' If I drop out of the 
>AS confed, I would have had to drop the session.
>
>Roque: Why not just tunnel back?
>
>Sue Hares: No IGP connectivity and tunnels ran into problems.
>Sue Hares: will send scenarios to list
>
>Chandra Appanna (Cisco): I think you need a few more failsafes. 
>Resend is a MUST, and some mechanisms is nec. that moved did not 
>suddenly change. Need to resend routes due to policy change potential.
>
>Sue Hares: We have added failsafe. We delayed resend, it would be abnormal 
>to send all routes if nothing changed. Will send scenario in email.
>
>Gargi (Cisco): Are there any mechanisms in mind for NO resend if ones 
>moves from one confed to another?
>
>-------------------------
>Multisession update - Chandra Appanna
>
>See ppt for info
>
>Added flexibility for any capability code to cause/create multiple sessions
>
>No comments
>
>-------------------------
>Kapoor SSA - Gargi, Scott Wainner
>
>see ppt for info
>
>-------------------------
>Kapoor Tunnel SAFI
>
>combined w/ SSA preso, same ppt
>
>Gargi did technical side and changes to docs:
>
>more TLVs to express encap:
>
>MPLS, IPsec, GRE in IPsec, L2TPv3 in IPsec
>
>added application scenarios: MPLS over IP tunnels
>
>Scott presented motivations
>
>Combined comments:
>
>Sue Hares: Can you explain status of this mechanism w/in each of these 
>groups (on referenced drafts)? What is approved, required, etc. We 
>need to see something from those chairs that the ref'ed drafts are 
>"blessed."
>
>Scott Wainner:  Walked through
>
>Gargi: We have chicken and egg to get this done. Encoding first or 
>formats first?
>
>Intro work on L3VPN list.
>
>Yakov Rekhter: Very reasonable model where must have both WGs review 
>dependent docs.
>
>Bill Fenner:  Must work w/ other WG for encoding.
>
>Yakov Rekhter: Two possible models - first: semantics or encoding need to 
>be done in L3VPN; second: L2/L3VPN WGs tell us semantics and IDR produces 
>encoding.
>
>Rahul Aggarwal: there were two problems in the past: 1) Motivation wasn't
>clear 2) Authors of draft-raggarwa-ppvpn-tunnel-encap and authors
>of the drafts presented at this IDR meeting were unable to come up
>with a joint proposal. Suggested that since motivations are clearer
>now, this work should be discussed again in the L3VPN WG.
>
>Pedro Roque: Disagree w/ motivations. IGP can provide reachability. I think 
>you use BGP as signaling protocol which is not a problem. But, 
>presentation states that BGP needs to know this information. Please 
>clarify the layering split.
>
>Yakov Rekhter: Can this move to L3VPN
>
>SOLUTION: Joint Last Call in IDR and L3VPN.
>
>-------------------------
>SAFI Space Partition
>In reply to Jeff Hass email on list.
>
>Bill Fenner to send notes on how to alloc SAFI space.
>
>Proposal: take private use space and turn it into reserved and 
>perhaps 16 or so as private use. Reserved is reserved so we can 
>decide later on FCFS or otherwise managed.
>
>Are folks using private space? Do we need to skip some?
>
>Yakov Rekhter: How long will it take to use up first come first served?
>
>Bill Fenner: We should be able to straighten this out quickly and IANA is 
>keeping up. 30 days deadline.
>
>Danny McPherson: Needs to be uniform across all WGs and Areas. Make 
>it IETF aligned.
>
>Pedro Roque: I do not want to see vendor specific space go away altogether. 
>There is much more usage than one case alluded to. Today is only 
>practical alternative, cannot be locked out. Can it be shown to work 
>before we assume 30 days?
>
>Bill Fenner: There are publications on these agreements and promises that 
>it will be done in 30 days. FCFS is you get it now .... no draft, no 
>wait.
>
>Chandra: Cannot get rid of vendor space.  AF/SAFI has lost meaning and 
>is a way to differentiate addrs between two peers. Just need opaque 
>space that we can use between two peers.
>
>Gargi: Must have vendor space perhaps reduced is ok. Second, IANA is 
>faster but, it seems to required Routing ADs having lunch w/ IANA.
>
>Yakov Rekhter: IANA must have strict 30 days max as rule.
>
>Bill Fenner: We are working on this and the stats show that 30 days 
>is being met.
>
>  
>

------- End of Forwarded Message

Date: Mon, 15 Aug 2005 17:17:09 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Subject: Re: [Idr] advertising more than one route to a destination
Mail-Copies-To: [email-masked]
Mail-Followup-To: [email-masked]
Cc: [email-masked], Inter-Domain Routing List <[email-masked]>, "Nipper, Arnold" <[email-masked]>
Sender: [email-masked]

On Mon, 15 Aug 2005, Yakov Rekhter wrote:

> Folks,
>
> As you know the basic BGP spec currently restricts a BGP speaker
> to advertise at most a single route to a given destination (given
> address prefix).
>
> The purpose of this e-mail is to solicit opinions on (a) what 
> applications could benefit if the above restriction is relaxed, as 
> to allow a BGP speaker to advertise multiple routes to a given 
> destination, and (b) whether the IDR WG should start work on 
> extending BGP to support these applications.

a) eBGP Route-servers at IXes, to act as 'dumb'
   (non-best-path-selecting) reflectors so as to reduce eBGP 'mesh'
   between IX users.

   iBGP reflectors, to reduce route-oscillations (see Walton, et al).

b) Yes.

    Note: there's at least one private draft examining this.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Consultant, n.:
 	An ordinary man a long way from home.

To: [email-masked]
Date: Mon, 15 Aug 2005 09:09:44 -0700
From: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: [Idr] advertising more than one route to a destination
Sender: [email-masked]

Folks,

As you know the basic BGP spec currently restricts a BGP speaker
to advertise at most a single route to a given destination (given
address prefix).

The purpose of this e-mail is to solicit opinions on (a) what
applications could benefit if the above restriction is relaxed, as
to allow a BGP speaker to advertise multiple routes to a given
destination, and (b) whether the IDR WG should start work on extending
BGP to support these applications.

With this in mind, please answer the following two questions:

1. What applications could benefit from allowing a BGP speaker
to advertise multiple routes to a destination ? 

2. Should the IDR WG start work on extending BGP to support
such applications ?

The deadline for response is August 29.

Yakov.

To: Jeffrey Haas <[email-masked]>
Subject: Re: WG Last Call on IANA Considerations (was Re: [Idr] IDR WG Minutes) 
Date: Mon, 15 Aug 2005 09:06:08 -0700
From: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

Jeff,

[speaking as a WG member...]

> Yakov had requested that I forward my proposed wording changes to
> the list.  Here they are:
> 
> : > Are you ok with the proposed text I sent to the list yesterday ?
> : > If not, could you propose and post an alternative text.
> : 
> : Presuming you're talking about the last call, here's how I'd change it:
> : 
> :   - Keep 1-63 as "IETF Consensus/Early Allocation"
> :   - Reclassify 64-223 as "FCFS"
> :     Make special that 128 will remain allocated
> :   - Reclassify 224-239 as "Reserved".
> :   - Retain 240-254 as "private use".
> :   - Reclassify 255 as "Reserved"
> :   - As needed, register values in the Reserved or FCFS range if
> :     previously-deployed protocols come into or are already in
> :     progress within the IETF.
> :   - Recommend that new developments use FCFS or RFC4020 method to get
> :     code points
> :   - In the future, if we run out of FCFS or IETF Consensus numbers,
> :     start using the "Reserved" space as needed.
> : 
> : The modified IANA Consideration section will look as follows:
> : 
> :    As specified in this document, the MP_REACH_NLRI and MP_UNREACH_NLRI
> :    attributes contain the Subsequence Address Family Identifier (SAFI)
> :    field. The SAFI name space is defined in this document. The IANA will
> :    maintain and register values for the SAFI namespace as follows. 
> :    
> :    SAFI values 1 and 2 are assigned in this document.  SAFI values
> :    4 through 63, 65, and 128 are to be assigned by IANA using either
> :    the "IETF Consensus" policy defined in RFC2434 or the "Early
> :    IANA Allocation" policy defined in RFC4020. SAFI values 64 and
> :    66 through 239 are to be assigned by IANA, using the "First  Come
> :    First Served" policy defined in RFC2434. SAFI values 240 through
> :    254 are for "private use", and are not to be assigned by IANA.
> :    SAFI values 0, 3, and 129 through 239 and 255 are reserved.

What is the rationale for having one range for the IETF Consensus
policy and another range for the FCFS policy ?  In other words, why
not have just a single block from which IANA could allocate
either based on the IETF Consensus or on the FCFS policy ?

Yakov.

Date: Mon, 15 Aug 2005 11:37:44 -0400
From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Subject: Re: WG Last Call on IANA Considerations (was Re: [Idr] IDR WG Minutes)
Sender: [email-masked]

Yakov had requested that I forward my proposed wording changes to
the list.  Here they are:

: > Are you ok with the proposed text I sent to the list yesterday ?
: > If not, could you propose and post an alternative text.
: 
: Presuming you're talking about the last call, here's how I'd change it:
: 
:   - Keep 1-63 as "IETF Consensus/Early Allocation"
:   - Reclassify 64-223 as "FCFS"
:     Make special that 128 will remain allocated
:   - Reclassify 224-239 as "Reserved".
:   - Retain 240-254 as "private use".
:   - Reclassify 255 as "Reserved"
:   - As needed, register values in the Reserved or FCFS range if
:     previously-deployed protocols come into or are already in
:     progress within the IETF.
:   - Recommend that new developments use FCFS or RFC4020 method to get
:     code points
:   - In the future, if we run out of FCFS or IETF Consensus numbers,
:     start using the "Reserved" space as needed.
: 
: The modified IANA Consideration section will look as follows:
: 
:    As specified in this document, the MP_REACH_NLRI and MP_UNREACH_NLRI
:    attributes contain the Subsequence Address Family Identifier (SAFI)
:    field. The SAFI name space is defined in this document. The IANA will
:    maintain and register values for the SAFI namespace as follows. 
:    
:    SAFI values 1 and 2 are assigned in this document.  SAFI values
:    4 through 63, 65, and 128 are to be assigned by IANA using either
:    the "IETF Consensus" policy defined in RFC2434 or the "Early
:    IANA Allocation" policy defined in RFC4020. SAFI values 64 and
:    66 through 239 are to be assigned by IANA, using the "First  Come
:    First Served" policy defined in RFC2434. SAFI values 240 through
:    254 are for "private use", and are not to be assigned by IANA.
:    SAFI values 0, 3, and 129 through 239 and 255 are reserved.

-- 
Jeff Haas 
NextHop Technologies

Content-class: urn:content-classes:message
Subject: RE: [Idr] IDR WG Minutes
Date: Mon, 15 Aug 2005 08:09:53 -0600
From: "Susan Hares" <[email-masked]>
To: "Rahul Aggarwal" <[email-masked]>, "Yakov Rekhter" <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Rahul:

I've included this change in the updated minutes.  Please confirm
I've got it correctly.

Sue

==================================

IDR WG notes 2005.08.04 -(Dave Ward) 
-------------------------
Agenda:

Agenda: 
1. IDR Documents status update 5 mins 
2. Tony Li
	draft-li-as-hopcount-01.txt  30 mins 
3. Zhang Renhai 
	draft-zhang-idr-bgp-entire-routes-reflect-01.txt 15 mins 
4. 
    draft-walton-bgp-add-paths-03.txt 
    draft-walton-bgp-route-oscillation-stop-01.txt 
    20 mins 
5. Nicolas Dubois
    draft-dubois-bgp-pm-reqs-01.txt 15 mins 
6. Sue Hares 
   draft-hares-bose-dynamic_as-01.txt 10 mins
  
7. Chandra Appanna 
    draft-ietf-idr-bgp-multisession-01.txt 10 mins 

8. Gargi 
    draft-kapoor-nalawade-idr-bgp-ssa-02.txt
draft-nalawade-kapoor-tunnel-safi-03.txt. 15 mins 

==================================================

Doc status

Danny McPherson to finish Confed implementation report in one month
Geoff Houston to complete 4-octet AS number
New MIB editor see draft

see ppt

-------------------------
Li AS Hop count Attribute

see ppt for info
Essence: Add TTL to each prefix, decrement at AS boundary Drop route
when TTL hits zero Transitive attribute

Alt: Distribution Lists
List contains ASs that can rx and cannot exclusion

NOTE: NO_EXPORT and AS_HOPCOUNT can be combined

Houston: is NO_EXPORT dropped or continued when combined?

NOTE:  Can scope 'anycast'

Houston: when aspath prepending, is that expressed in the HOP_COUNT?
Li: Decremented by one always

Hares: Two more ASPATHS per route? How does scaling work?
Li: In the worst case, when setting up a list you can have an arbitrary
number in incl or excl list?

Hares: Is order semantics true but,

Rekhter: An ASPATH cannot carry all AS in the internet as not enough
space

Li: An avg ASPATH has ~4 AS' in it so, we are going to have on avg
roughly two X

Hares: Why do you say proxy usage is diffficult in Dist List case? 
TTL is lighter but, why choose between two? Might have both.

Li: From an implementors POV, it is easier to do one and not two

Rekhter: The increase in number of AS' per route is not a practical
issue

Houston: At the edge, it may work but, topology is dense and we nee

Jason Schiller (UUNET): Scope - useful in subconfeds ... need  a
separate counter?

Li: Want to see draft first. Technically what is required is a separate
attribute but, look almost identical

Houston: When comparing the two mechanisms need to look at "what is
going on." Distribution lists require complete knowledge of topology. 
Problem is that you cannot insure that they do not leak. HOPCOUNT does
not have 'knowledge' problem but, focuses on accuracy.

Hares: Inclusion requires enumeration but exclusion does not.

Houston: HOPCOUNT allows more specifics w/ a boundary. Advocates
HOPCOUNT

Roque: No productive compare the two. Want to select upstream provider
w/ targeted ext comms. HOPCOUNT might prevent this technique. Most
common TE technique; customers preferring transit AS' 
per prefix. Not applicable for transit exit scenario. Two issues and
solutions are orthogonal but, neither solution is devalued.

Chris Morrow (UUNET): proxy means "I can add" and/or "I can delete"

Li: Yes and not violate

Chris; Will it get used if provider ignores or removes

Rekhter: Who is entity that benefits from this? Which SP.

Li: Table size reduction is goal. One SP adds does the work but, gets no
benefits. Altruism or hope of it is a good reason.

Houston: Zhang drafts in GROW show that altruism is bunk instead
self-interest. Most UPDATEs come from lower tier points. Most
computation happens at lower level of peering .. therefore, small folks
get most thrash. If "I" do this, I help my problem ... 
therefore altruism is there for the folks that use it and tag it.

David Ward: Affect Hop count?

Li: Not significantly as it would be longer prefixes.

Enke: Can we inject an AS numer as 'signature' of who adds attribute?

May be added to draft. No comments

-------------------------
Zhang Renhai Entire Route Reflect

Comments held until after Walton's draft see ppt for info

-------------------------
Walton Add Paths
Alvaro Retana (Cisco) presenter.
see ppt for info

NOTE: RFC 3107 must be updated

-------------------------
Walton Oscillation Stop
Alvaro Retana (Cisco) presenter
info in same ppt as "Add Paths"

Swallow: What is frequency of oscillation?

Retana: dependent on update timer setting (MIN ADVERT INTERVAL)

Combined questions for both draft authors:
Danny (unaffiliated) - We are increasing and decreasing table size. 
Walton's draft is more general and flexible then Zhang's.

Retana: Most of increase of table size is internal to an AS (almost all)

zhang: I don't understand question.

Zhang: Walton's draft is more general. Because you add attribute, do you
think that efficiency of packing will be affected?

Retana: NLRI will be bigger but, no impact on packing.

Gargi (Cisco): Zhang's draft - must specify that you explicitly WD when
a nexthop changes or how to announce new NH?  How do you delete the
first NH?

Zhang: If NH changes, just add it. To solve the problem there will taken
offline to email.

Paul ??: If in ECMP case, what AS sequence? How to pass multiple paths
to a legacy speaker?

Retana:  Cap advert defines who can learn add_path. Other applications
like EBGP ECMP and propagating multiple paths will have to be addressed.

Retana: Constrained scope.

Roque: Although you say impact of deployment is localized. We need a
better understanding of what impact will be. For each route prefix, path
attrs in Adj RIB Out. Generally announcement, is only  when Adj-RIB-Out
changes. What is expectation of propagating changes when inbound updates
would cause outbound content. What are consequences? 
Size of Adj-RIB-Out? What is key of Adj-RIB-Out? etc.

Retana: Spec says send on path. Change is that we would have tracking of
two or more paths.

Rekhter: We can have as many ad hoc solutions as we want or a more
general solution. We as a group should decide on a more general
solution. We should look at potential new functionality once we have
more than one path being advertised.
Suggestion is that the authors of three proposals should find common
solution to all problems that WG would like to address. A mailing list
will be set up to discuss this problem and solution. On the IDR mailing
list please identify problems.

[3 proposals are:

draft-bhatia-ecmp-routes-in-bgp-01.txt
draft-zhang-idr-bgp-entire-routes-reflect-00.txt
draft-walton-bgp-add-paths-03.txt]

Rekhter: Do we need requirements document?

Ward: No, absolutely not.

-------------------------
Dubois PM Reqmts

see ppt for info

Rekhter: Send note to list on whether or not we should take as a WG doc.

Dubois: Earlier solution was not meeting requirements and there are many
possible solutions. We need a solution that fits the requirements; we
are not encouraging one solution over another:

Ted Seely (Sprint): Why not weight traffic away from peer or interface?
There are other techniques that don't require change to protocol.

Ruediger Volk: I lose traffic when I do this technique.

Ruediger: The convergence problem I see is due to the previous issue of
config change.

Jason Schiller (UUNET): Is there a hard requirement that this does not
require a config change ... taken to the list.

-------------------------
Hares Dynamic Confed AS

Not requested to be WG item.
see ppt for info

Roque: I would assume that you would want to do restoration in a
seamless way. What is motivation to make failure restoration a visible
outside the confederation?

SKH: Goal is to not drop the peering session. Therefore, the purpose is
policy rerouting wants to 'hang by itself.' If I drop out of the AS
confed, I would have had to drop the session.

Roque: Why not just tunnel back?

SKH: No IGP connectivity and tunnels ran into problems.
SKH: will send scenarios to list

Chandra Appanna (Cisco): I think you need a few more failsafes. 
Resend is a MUST, and some mechanisms is nec. that moved did not
suddenly change. Need to resend routes due to policy change potential.

SKH: We have added failsafe. We delayed resend, it would be abnormal to
send all routes if nothing changed. Will send scenario in email.

Gargi (Cisco): Are there any mechanisms in mind for NO resend if ones
moves from one confed to another?

-------------------------
Multisession update - Chandra Appanna

See ppt for info

Added flexibility for any capability code to cause/create multiple
sessions

No comments

-------------------------
Kapoor SSA - Gargi, Scott Wainner

see ppt for info

-------------------------
Kapoor Tunnel SAFI

combined w/ SSA preso, same ppt

Gargi did technical side and changes to docs:

more TLVs to express encap:

MPLS, IPsec, GRE in IPsec, L2TPv3 in IPsec

added application scenarios: MPLS over IP tunnels

Scott presented motivations

Combined comments:

SKH: Can you explain status of this mechanism w/in each of these groups
(on referenced drafts)? What is approved, required, etc. We need to see
something from those chairs that the ref'ed drafts are "blessed."

Scott:  Walked through

Gargi: We have chicken and egg to get this done. Encoding first or
formats first?

Intro work on L3VPN list.

Rekhter: Very reasonable model where must have both WGs review dependent
docs.

Bill Fenner:  Must work w/ other WG for encoding.

Rekhter: Two possible models - first: semantics or encoding need to be
done in L3VPN
    second: L2/L3VPN WGs tell us semantics and IDR produces codepoints

Rahul: There were two problems in the past: 1) Motivation wasn't clear
2) Authors of draft-raggarwa-ppvpn-tunnel-encap and authors of the
drafts presented at this IDR meeting were unable to come up with a joint
proposal. I suggested that since motivations are clearer now, this work
should be discussed again in the L3VPN WG.

Roque: Disagree w/ motivations. IGP can provide reachability. I think
you use BGP as signaling protocol which is not a problem. But,
presentation states that BGP needs to know this information. Please
clarify the layering split.

Rekhter: Can this move to L3VPN

SOLUTION: Joint Last Call in IDR and L3VPN.

-------------------------
SAFI Space Partition
In reply to Jeff Hass email on list.

Fenner to send notes on how to alloc SAFI space.

Proposal: take private use space and turn it into reserved and perhaps
16 or so as private use. Reserved is reserved so we can decide later on
FCFS or otherwise managed.

Are folks using private space? Do we need to skip some?

Rekhter: How long will it take to use up first come first served?

Fenner: We should be able to straighten this out quickly and IANA is
keeping up. 30 days deadline.

Danny McPherson: Needs to be uniform across all WGs and Areas. Make it
IETF aligned.

Roque: I do not want to see vendor specific space go away altogether. 
There is much more usage than one case alluded to. Today is only
practical alternative, cannot be locked out. Can it be shown to work
before we assume 30 days?

Fenner: There are publications on these agreements and promises that it
will be done in 30 days. FCFS is you get it now .... no draft, no wait.

Chandra; Cannot get rid of vendor space.  AF/SAFI has lost meaning and
is a way to differentiate addrs between two peers. Just need opaque
space that we can use between two peers.

Gargi: Must have vendor space perhaps reduced is ok. Second, IANA is
faster but, it seems to required Routing ADs having lunch w/ IANA.

Rekhter: IANA must have strict 30 days max as rule.

Fenner: We are working on this and the stats show that 30 days is being
met.

To: "DECRAENE Bruno RD-CORE-ISS" <[email-masked]>
Subject: Re: [idr] BGP planned maintenance requirements as an IDR WG doc 
Date: Sun, 14 Aug 2005 20:20:00 -0400
From: Curtis Villamizar <[email-masked]>
Cc: [email-masked], FONDEVIOLE Benoit RD-CORE-ISS <[email-masked]>, DUBOIS Nicolas ROSI-DAS-ARI <[email-masked]>
Reply-To: [email-masked]
Sender: [email-masked]

In message <[email-masked]>
"DECRAENE Bruno RD-CORE-ISS" writes:
>  
> We raise the issue, which is a first step.

OK.  You've successfully raised the issue.  Thanks for doing so.
There may not be a need for a separate RFC to raise the issue if the
issue can be clearly and very concisely stated and if there is a very
simple solution.  So lets consider solving it for a moment.

If you are trying to remove routes from your own IGP costing out is
the best solution.  In ISIS you use the OVERLOAD bit.  In OSPF you can
cost out all links.

For the case where you are removing EBGP learned routes from your own
IBGP you can cost out your advertisements with a high LOCAL_PREF.
Costing out with LOCAL_PREF is better than sending MP_UNREACH since no
router is ever temporarily without a route if an alternate exists but
the advertisement is suppressed by normal BGP rules including RR
topologies.

For this case at most you could ask your favorite router vendor for a
"poison-peer" command that changes the LOCAL_PREF of all routes to a
very high value (make up your own keyword and syntax which specifies
the peer and value).  If taking the whole router down, then a
"poison-peer all" or "poison-self" variation would be handy.

For the benefit of your peer, prior notification to their NOC of your
maintenance is still needed if you plan to take an EBGP session down
or take a router down.

For the benefit of your peer router some indication that its time for
them to "cost out" your routes (or poison your peering in the above
terminology) might help.  The advantage of using a CEASE subcode is
that any router that doesn't understand will just treat it as any
other CEASE.  Backwards compatibility is always nice.  If both routers
understand, they'd just LOCAL_PREF poison each side of the peering and
then after some delay (probably best to specify a default and
"configured on the local router") send MP_UNREACH for all the routes.
A disadvantage of a CEASE subcode is that if a specific prefix went
unreachable there is no longer a way to send an MP_UNREACH across the
peering, unless this is made a non-fatal CEASE to be followed by
another CEASE very shortly.

If I'm not mistaken, then all that is needed is an internet-draft with
a CEASE subcode and some wording to indicate that it should be treated
as non-fatal and result in both sides setting a very high LOCAL_PREF
for all routes on the peering regardless of local policy.  I suggest
that each router should enforce a maximum time to keep the peering
after getting one of these CEASE, making sure that it is only used as
a temporarily non-fatal policy override.

Lets see what other on the IDR list have to say about this as a
potential solution.

Curtis

To: "DECRAENE Bruno RD-CORE-ISS" <[email-masked]>
Subject: Re: [idr] BGP planned maintenance requirements as an IDR WG doc 
Date: Sun, 14 Aug 2005 19:09:36 -0400
From: Curtis Villamizar <[email-masked]>
Cc: [email-masked], [email-masked], FONDEVIOLE Benoit RD-CORE-ISS <[email-masked]>, DUBOIS Nicolas ROSI-DAS-ARI <[email-masked]>, Paul Jakma <[email-masked]>
Reply-To: [email-masked]
Sender: [email-masked]

In message <[email-masked]>
"DECRAENE Bruno RD-CORE-ISS" writes:
> > 
> > Would it not be enough to simply withdraw the advertised 
> > routes before bringing the session down towards given peer ? 
> > If operator enters shutdown on BGP session this should not 
> > trigger any immediate BGP/TCP action .. instead one could 
> > send MP_UNREACH then at some decent timeout actually bring 
> > the sessions down.
>  
> It's indeed a possible solution. In fact it's exactly what we proposed
> in "draft-dubois-bgp-planned-maintenance-00.txt" in San Diego.
> Unfortunately, it's not working for all the iBGP topologies:
> - If you have a full iBGP mesh, all your peers already know the backup
> path and will select it. So this will work fine.
> - If you have RRs, iBGP routers (including your RR) may not have the
> backup path. The RR will propagate the withdraw and the destination will
> be removed from the RIB. 

Use LOCAL_PREF instead of MP_UNREACH.  The RR will use the best route
it has with the high LOCAL_PREF until another router announces a route
with a lower LOCAL_PREF.

This is easy to do.  If the peering goes down a one liner sets the
LOCAL_PREF for the peer.  If its the entire router going down, its
easy enough to set the default LOCAL_PREF to a high number.  If you
already use LOCAL_PREF, then you'll need to remove LOCAL_PREF lines
but not write out the config so things go back to normal after the
router comes up again.

Curtis

ps - Sorry for the noise if this is already suggested.  Didn't read to
the end of this thread yet.

Date: Fri, 12 Aug 2005 11:33:50 -0700 (PDT)
From: Rahul Aggarwal <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Subject: Re: [Idr] IDR WG Minutes
Cc: [email-masked]
Sender: [email-masked]

Hi Yakov,

A comment inline:

[snipped]

> Kapoor SSA - Gargi, Scott Wainner
>
> see ppt for info
>
> -------------------------
> Kapoor Tunnel SAFI
>
> combined w/ SSA preso, same ppt
>
> Gargi did technical side and changes to docs:
>
> more TLVs to express encap:
>
> MPLS, IPsec, GRE in IPsec, L2TPv3 in IPsec
>
> added application scenarios: MPLS over IP tunnels
>
> Scott presented motivations
>
> Combined comments:
>
> SKH: Can you explain status of this mechanism w/in each of these
> groups (on referenced drafts)? What is approved, required, etc. We
> need to see something from those chairs that the ref'ed drafts are
> "blessed."
>
> Scott:  Walked through
>
> Gargi: We have chicken and egg to get this done. Encoding first or
> formats first?
>
> Intro work on L3VPN list.
>
> Rekhter: Very reasonable model where must have both WGs review dependent docs.
>
> Bill Fenner:  Must work w/ other WG for encoding.
>
> Rekhter: Two possible models - first: semantics or encoding need to
> be done in L3VPN
>     second: L2/L3VPN WGs tell us semantics and IDR produces codepoints
>
> Rahul:  C/E problem wasn't problem in the past but, applicability.
> Applicability has been cleared up. Now that motivations are clear,
> the multiple proposal should be conjoined. Do work wherever ADs state
>

More specifically I said that there were two problems in the past: 1)
Motivation wasn't clear 2) Authors of draft-raggarwa-ppvpn-tunnel-encap
and authors of the drafts presented at this IDR meeting were unable to
come up with a joint proposal. I suggested that since motivations are
clearer now, this work should be discussed again in the L3VPN WG.

thanks,
rahul

> Roque: Disagree w/ motivations. IGP can provide reachability. I think
> you use BGP as signaling protocol which is not a problem. But,
> presentation states that BGP needs to know this information. Please
> clarify the layering split.
>
> Rekhter: Can this move to L3VPN
>
> SOLUTION: Joint Last Call in IDR and L3VPN.
>
>
> -------------------------
> SAFI Space Partition
> In reply to Jeff Hass email on list.
>
> Fenner to send notes on how to alloc SAFI space.
>
> Proposal: take private use space and turn it into reserved and
> perhaps 16 or so as private use. Reserved is reserved so we can
> decide later on FCFS or otherwise managed.
>
> Are folks using private space? Do we need to skip some?
>
> Rekhter: How long will it take to use up first come first served?
>
> Fenner: We should be able to straighten this out quickly and IANA is
> keeping up. 30 days deadline.
>
> Danny McPherson: Needs to be uniform across all WGs and Areas. Make
> it IETF aligned.
>
> Roque: I do not want to see vendor specific space go away altogether.
> There is much more usage than one case alluded to. Today is only
> practical alternative, cannot be locked out. Can it be shown to work
> before we assume 30 days?
>
> Fenner: There are publications on these agreements and promises that
> it will be done in 30 days. FCFS is you get it now .... no draft, no
> wait.
>
> Chandra; Cannot get rid of vendor space.  AF/SAFI has lost meaning and
> is a way to differentiate addrs between two peers. Just need opaque
> space that we can use between two peers.
>
> Gargi: Must have vendor space perhaps reduced is ok. Second, IANA is
> faster but, it seems to required Routing ADs having lunch w/ IANA.
>
> Rekhter: IANA must have strict 30 days max as rule.
>
> Fenner: We are working on this and the stats show that 30 days is being met.
>

Date: Fri, 12 Aug 2005 18:10:34 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Bill Fenner <[email-masked]>
Subject: Re: [Idr] AD Review comments on draft-ietf-idr-restart
Mail-Copies-To: [email-masked]
Mail-Followup-To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On Fri, 12 Aug 2005, Bill Fenner wrote:

> In fact, you don't know that it's a restarting connection until 
> you've gotten the OPEN on the new connection, right?

A concern here, is that the GR peer assumes forwarding will stay up. 
So NOTIFY/CEASE now becomes (between GR negotiated peers):

 	"I'm shutting down (implicit: assume I keep forwarding in place)"

However, in light of other discussions, that assumption presents a 
problem for possible future IDR work that intends to try gracefully 
handle shutdown of forwarding - ie the ability to say:

 	"I'm shutting down"

without any assumptions is lost between GR peers.

(The assumption is bounded by timers, but that introduces delays for 
any graceful full-shutdown work..)

It /might/ be an idea to require GR peers to explicitely signal their 
intent to keep forwarding up during restart, or even just:

 	"I'm restarting"

And let this new CEASE sub-code carry the assumption (or maybe 
ADMIN_RESET would suffice?)

(No idea whether it's a good idea to use sub-codes for anything other 
than informational content).

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
He who is flogged by fate and laughs the louder is a masochist.

Date: Fri, 12 Aug 2005 17:51:26 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Olivier Bonaventure <[email-masked]>
Subject: Re: [idr] BGP planned maintenance requirements as an IDR WG doc
Mail-Copies-To: [email-masked]
Mail-Followup-To: [email-masked]
Cc: DECRAENE Bruno RD-CORE-ISS <[email-masked]>, Inter-Domain Routing List <[email-masked]>, vijay gill <[email-masked]>
Sender: [email-masked]

Hi Olivier,

> You need at least to be able to distinguish between :

> - a NOTIFY/CEASE that must be processed immediately
> - a NOTIFY/CEASE that must be processed after N seconds (note that
> selecting the good value for N is an issue)

The receiving router or the sender? As for selecting a good value, 
yes :), tis an issue.

> The solution to be used will depend on how packets are forwarded inside
> the AS. There are two possible solutions :

> - pervasive BGP where all routers run BGP and consult their FIB to
> forward each received transit packet

> - encapsulation such as an MPLS-enabled network. In this case, the
> ingress router selects the egress router and forward the packets
> directly to the egress router (no transit router need to consult its BGP
> FIB to forward the packet).
>
> With pervasive BGP, the solution must ensure that no transient 
> forwarding loop will occcur during the update of the FIBs of all 
> routers. This is more complex than simply setting a delay of N 
> seconds on one router.

Generally, yes, I'm sure it is. Seems it could work for the scenario 
presented though, if the two 'edge' routers (CUST-ASBR{1,2}) both 
delayed their FIB updates, thus giving time for interior iBGP 
speakers (P1, P2) to update their paths. (Ie if N is greater than the 
time it takes for P1 and P2, then there is no time during which 
either ASBR1 or ASBR2 will refuse to forward to P2).

It likely wouldn't work for more complex edge scenarios, but that's 
(hopefully) what you guys are considering ;).

> Note that this document considers the ordered update of FIBs with 
> only a link-state routing protocol. It does not consider any 
> interaction with BGP.

Indeed.

Your (plural) work applies generally though to topology updates, 
doesn't it?

Further, given iBGP should not result in complex forwarding (iBGP 
topology should nearly always be 'flat' in the abstract - nexthops 
are abstracted, should always point to the 'edge'), it means, from an 
iBGP POV, you should not have a complex topology to contend with.

Eg, in the example scenario given previously, consider some other 
router within AS 2, call it P3. It's interior path to the routers 
ASBR{1,2} is arbitrary (be it: many hops, lots of redundant paths; or 
maybe its directly to one or both of P1 and P2, who knows). However, 
as iBGP abstracts interior topology it's iBGP path to CUST is always:

 	x/y via CUST

The only sane place to distribute this external nexthop into iBGP (if 
at all, if using IGP - then we dont need to worry at all) is on 
either ASBR1 or ASBR2.

So the delayed update trick on ASBR1 will work fine, as long as the 
delay is sufficient for iBGP to converge on ASBR2.

Similarly, if CUST's sessions to ASBR1 and ASBR2 have different 
nexthops, in iBGP we will have one of:

 	x/y via CUST-nh1 (connected to ASBR1)

or

 	x/y via CUST-nh2 (connected to ASBR2)

installed throughout the rest of the iBGP domain. And again, the 
delayed FIB update on ASBR1 should allow anyone in the iBGP of AS2 
using the former path to update to the latter.

In both cases, while others converge, ASBR1 will still forward to 
CUST (as will ASBR2 obviously). Once convergence is complete, ASBR1 
should no longer see any packets destined for x/y at all, and it 
doesnt matter what it does really.

Ie, the abstracted topology which iBGP propogates makes analysis of 
this quite easy, doesn't it? At least for the shutdown case, not 
considering the 'up' case.

Obviously, if the nexthops are carried in IGP, then updates of those 
are an IGP problem - which is being looked at, AIUI (by yourself and 
others).

> There is a full paper on the FIB update order with mathematical 
> proofs, see Pierre Francois' INFOCOM paper available from 
> http://www.info.ucl.ac.be/people/OBO/biblio.html

Ah, bedankt! I'll have a read.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Old MacDonald had an agricultural real estate tax abatement.

To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Date: Fri, 12 Aug 2005 11:13:49 -0400
From: Bill Fenner <[email-masked]>
Versions: dmail (linux) 2.6d/makemail 2.10
Cc: [email-masked]
Subject: [Idr] AD Review comments on draft-ietf-idr-restart
Sender: [email-masked]

I'm sorry that these are so late, especially since I found only a couple of
concerns.

1. Very minor - the document needs an IANA Considerations section,
probably just one sentence asking to change the reference for
64 from [Chen] to this document.

2. There's a new timer introduced (upper bound on the amount of time a
router defers its route selection) which MUST be supported but there's
no guidance on a default value or whether it should be used at all
by default.  (It may be easiest to just say that it SHOULD not be
configured to be used by default, and the upper bound is left to be
chosen by configuration by the user; if there's some guidance as to
how to set it that'd be even better)

3. In the description of the state machine modification, I'm concerned
that the literal interpretation of

      If the Graceful Restart capability with one or more AFI/SAFI has
      been received for the session, then TcpConnectionConfirmed (Event
      17) is treated as TcpConnectionFails (Event 18).

is that the new connection is torn down -- in Established state,
the FSM says that receiving a TcpConnectionFails means

              - sets the ConnectRetryTimer to zero,
              - deletes all routes associated with this connection,
              - releases all the BGP resources,
              - drops the TCP connection,
              - increments the ConnectRetryCounter by 1,
              - changes its state to Idle.

and clearly in graceful restart you don't want to do most of those things.

In fact, you don't know that it's a restarting connection until you've
gotten the OPEN on the new connection, right?  You probably want to
be modifying the "If a valid OPEN message (BGPOpen (Event 19)) is received"
condition in the Established state of the FSM?

  Bill

From: "john smith" <[email-masked]>
To: [email-masked]
Subject: RE: [Idr] IDR WG Minutes
Date: Fri, 12 Aug 2005 12:26:05 +0000
Sender: [email-masked]

John,

>
> > Paul ??: If in ECMP case, what AS sequence? How to pass multiple
> > paths to a legacy speaker?
> >
> > Retana:  Cap advert defines who can learn add_path. Other
> > applications like EBGP ECMP and propagating multiple paths will have
> > to be addressed.
> >
> > Retana: Constrained scope.
>
>I dont think we should be considering proposals that preclude advertising 
>and using BGP
>ECMP routes. More so when the WG is considering taking this up as an item.
>
Given the assumption that
a. CPUs will grow faster that ASICs.
b. memory on control plane will be cheaper than those in the forwarding 
plane components,

i see a benefit in signalling paths to solve a problem that BGP may not 
solve in its current form.

the only advantage this gives is help solve negative arcs.
Closer to Local_pref on eBGP/MED oscillations scenarios.

the only reason I brought up this topic was that i was not dead sure how 
weights are used on eBGP peers.
Could be my lack of knowledge of coupled be too much obfuscation around the 
correct solution :-).

It does make sense to have the feature though.

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar - get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/

Date: Wed, 10 Aug 2005 21:16:57 +0200
From: Olivier Bonaventure <[email-masked]>
To: Paul Jakma <[email-masked]>
Subject: Re: [idr] BGP planned maintenance requirements as an IDR WG doc
Cc: DECRAENE Bruno RD-CORE-ISS <[email-masked]>, Inter-Domain Routing List <[email-masked]>, vijay gill <[email-masked]>
Sender: [email-masked]

Paul,

>> Could you be a little more specific about your proposition?
> 
> 
> Put a delay in between NOTIFY/CEASE and updating your FIB.

You need at least to be able to distinguish between :
- a NOTIFY/CEASE that must be processed immediately
- a NOTIFY/CEASE that must be processed after N seconds (note that
selecting the good value for N is an issue)

>> If this is a correct understanding, let's take the following topology
>> (from the requirement draft):
>>                             '
>>                             '
>>                             '
>>                       AS1   '      AS2
>>                             '
>>
>>
>>                       /-----------ASBR1-----P1----
>>                      /                      |
>>                     /                       |
>>                 CUST                        |
>>                     \                       |
>>              X.Y/16  \                      |
>>                       \-----------ASBR2-----P2----
>>
>>
>>                             '
>>                             '
>>                       AS1   '      AS2
>>                             '
>>
>>                   Figure 1: Redundant peering example.
>>
>>
>> We want to close CUST-ASBR1 link.
>>
>> After sending the "CEASE" to CUST, ASBR1 removes the routes learned
>> through this eBGP session. You have 2 cases:
>>
>> -0- BGP don't know the backup path, so it will remove the destination
>> from the RIB. ==> packets to the destination X.Y/16 (your customer) are
>> dropped on ASBR1.
> 

Note that this can happen simply if CUST-ASBR2 has a lower local-pref
than CUST-ASBR1

> Not sure what you mean by "BGP" here - ASBR1 or P1?
> 
> 1. ASBR1 Sends CEASE/NOTIFY to CUST1
> 2. ASBR1 processes any routes it may have received from CUST1
>     2a. Form withdrawals and send to P1
>     2b. Queue up FIB updates to process with some delay X
> 3. After delay X expires, process the FIB updates due to 2a
> 
> P1 will get the withdrawal. If it doesn't know the backup path via P2,
> it's surely in trouble regardless of what you propose for BGP ;). If you
> mean ASBR1 is not aware - that's ok, it will continue forwarding to
> CUST1 for a while.
> 
> The delay X, if large enough, gives P1 sufficient time to process the
> withdrawal, calculate the new path via P2 and install it.

The solution to be used will depend on how packets are forwarded inside
the AS. There are two possible solutions :
- pervasive BGP where all routers run BGP and consult their FIB to
forward each received transit packet
- encapsulation such as an MPLS-enabled network. In this case, the
ingress router selects the egress router and forward the packets
directly to the egress router (no transit router need to consult its BGP
FIB to forward the packet).

With pervasive BGP, the solution must ensure that no transient
forwarding loop will occcur during the update of the FIBs of all
routers. This is more complex than simply setting a delay of N seconds
on one router.

...
> 
> This is all essentially what several people have been considering
> already, eg the "Ordered FIB Updates" draft (i think you're aware of it,
> no?):
> 
>     http://bgp.potaroo.net/ietf/idref/draft-francois-ordered-fib/

Note that this document considers the ordered update of FIBs with only a
link-state routing protocol. It does not consider any interaction with BGP.

> Essentially, seems to me there are two rules of thumb:
> 
>     - for a path shutdown, FIB updates should lag RIB updates
> 
>     - for a path addition, FIB updates should lead RIB updates
>       and propogation.
> 
> (iirc) Francois had a very interesting presentation at the routing area
> meeting on this. They're looking deeply at this already, mathematically
> AIUI (havn't seen any papers on that side of things though), so
> hopefully some really useful techniques will come out of that in time.

There is a full paper on the FIB update order with mathematical proofs,
see Pierre Francois' INFOCOM paper available from
http://www.info.ucl.ac.be/people/OBO/biblio.html

Best regards

Olivier

Date: Wed, 10 Aug 2005 19:10:40 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: DECRAENE Bruno RD-CORE-ISS <[email-masked]>
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
Mail-Copies-To: [email-masked]
Mail-Followup-To: [email-masked]
Cc: Inter-Domain Routing List <[email-masked]>, vijay gill <[email-masked]>, Olivier Bonaventure <[email-masked]>
Sender: [email-masked]

On Wed, 10 Aug 2005, DECRAENE Bruno RD-CORE-ISS wrote:

> To adress the other direction of the IP flow, it would probably 
> require that on reception of a BGP NOTIFY/CEASE, you activate the 
> same trick.

If P1 were to be shutdown? Yes, then you'd want P1 to support this 
"trick". However, it's still useful in a mixed environment. Eg, for 
your ASBR1 case, even if P1 doesn't support this, it still should 
enhance routing.

> And it would require some extra trick if you have multiple RR 
> between the 2 ASBR advertising the path to the destination. (for 
> example full-reflection as you mention, but that also has a cost).

Yes. I'd suggest looking at the 3 drafts which potentially could 
solve the full-reflection + "CEASE + wait" optimisation case.

> If we come back to the requirement doc, it does not state that the 
> BGP protocol should necessarily be modified. It merely points out 
> an issue which could possibly be resolved with an informational or 
> BCP doc.

Fair enough.

> I guess most of us agree on the issue with the default behavior, but we
> disagree on what should be done:

> - Some expressed that it could already be solved now using specific
> route policies, manually configured or scripted.

> - I guess your point is that the issue could be resolved by an
> implementation without requiring any BGP modification and as such IDR
> should not be involved.

Yes, or at least that one could implement "CEASE and wait" first and 
garner some experience first before attempting to see what needs to 
be done at IDR. (I'm an IETF/IDR process newbie though, so my opinion 
might be incompatible with IETF/IDR practice).

> - Our point is that currently no popular implementation has 
> addressed this issue and that IDR could discuss this point. The 
> result of this discussion may be that it should be left to each 
> implementation but why presuppose the conclusion.

Hmm, well, I don't know when I'll get around to it (no promises), but 
hacking CEASE+wait into a Free Software BGP implemention is now on my 
lower-priority TODO list.

Mightn't be useful for you for deployment, but likely would be useful 
for laboratory testing to see how well CEASE+wait could work.

> It deals with link state IGP. I'd be fine if someone wrote an 
> equivalent draft for BGP.

It deals with topology changes in general, and discusses them in 
context of IGP - the topology change stuff is obviously still 
applicable to BGP to some extent.. interesting stuff anyway.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
A New York City ordinance prohibits the shooting of rabbits from the
rear of a Third Avenue street car -- if the car is in motion.

Content-class: urn:content-classes:message
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
Date: Wed, 10 Aug 2005 19:32:08 +0200
From: "DECRAENE Bruno RD-CORE-ISS" <[email-masked]>
To: "Paul Jakma" <[email-masked]>
Cc: Inter-Domain Routing List <[email-masked]>, vijay gill <[email-masked]>, Olivier Bonaventure <[email-masked]>
Sender: [email-masked]

Hi Paul,

> > Could you be a little more specific about your proposition?
> 
> Put a delay in between NOTIFY/CEASE and updating your FIB.
 
Fine. It's a possible solution.

To adress the other direction of the IP flow, it would probably require
that on reception of a BGP NOTIFY/CEASE, you activate the same trick.
And it would require some extra trick if you have multiple RR between
the 2 ASBR advertising the path to the destination. (for example
full-reflection as you mention, but that also has a cost).

If we come back to the requirement doc, it does not state that the BGP
protocol should necessarily be modified. It merely points out an issue
which could possibly be resolved with an informational or BCP doc. 
I guess most of us agree on the issue with the default behavior, but we
disagree on what should be done:
- Some expressed that it could already be solved now using specific
route policies, manually configured or scripted.
- I guess your point is that the issue could be resolved by an
implementation without requiring any BGP modification and as such IDR
should not be involved.
- Our point is that currently no popular implementation has addressed
this issue and that IDR could discuss this point. The result of this
discussion may be that it should be left to each implementation but why
presuppose the conclusion.

> This is all essentially what several people have been considering
already, eg the "Ordered FIB Updates" draft (i think you're aware of it,
no?):
> 	http://bgp.potaroo.net/ietf/idref/draft-francois-ordered-fib/

I'm aware of this draft which is indeed very interesting.
It deals with link state IGP. I'd be fine if someone wrote an equivalent
draft for BGP.

Regards,
Bruno

Date: Wed, 10 Aug 2005 15:36:30 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: DECRAENE Bruno RD-CORE-ISS <[email-masked]>
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
Mail-Copies-To: [email-masked]
Mail-Followup-To: [email-masked]
Cc: Inter-Domain Routing List <[email-masked]>, vijay gill <[email-masked]>, Olivier Bonaventure <[email-masked]>
Sender: [email-masked]

On Wed, 10 Aug 2005, DECRAENE Bruno RD-CORE-ISS wrote:

> Could you be a little more specific about your proposition?

Put a delay in between NOTIFY/CEASE and updating your FIB.

> If this is a correct understanding, let's take the following topology
> (from the requirement draft):
>                             '
>                             '
>                             '
>                       AS1   '      AS2
>                             '
>
>
>                       /-----------ASBR1-----P1----
>                      /                      |
>                     /                       |
>                 CUST                        |
>                     \                       |
>              X.Y/16  \                      |
>                       \-----------ASBR2-----P2----
>
>
>                             '
>                             '
>                       AS1   '      AS2
>                             '
>
>                   Figure 1: Redundant peering example.
>
>
> We want to close CUST-ASBR1 link.
>
> After sending the "CEASE" to CUST, ASBR1 removes the routes learned
> through this eBGP session. You have 2 cases:
>
> -0- BGP don't know the backup path, so it will remove the destination
> from the RIB. ==> packets to the destination X.Y/16 (your customer) are
> dropped on ASBR1.

Not sure what you mean by "BGP" here - ASBR1 or P1?

1. ASBR1 Sends CEASE/NOTIFY to CUST1
2. ASBR1 processes any routes it may have received from CUST1
 	2a. Form withdrawals and send to P1
 	2b. Queue up FIB updates to process with some delay X
3. After delay X expires, process the FIB updates due to 2a

P1 will get the withdrawal. If it doesn't know the backup path via 
P2, it's surely in trouble regardless of what you propose for BGP ;). 
If you mean ASBR1 is not aware - that's ok, it will continue 
forwarding to CUST1 for a while.

The delay X, if large enough, gives P1 sufficient time to process the 
withdrawal, calculate the new path via P2 and install it.

ASBR1, during this time, will continue forwarding any packets P1 
sends via it on to CUST1. If ASBR1 does not know about the backup 
path, that's ok, because when ASBR1 eventually updates it's FIB, P1 
should already have updated its FIB and will no longer be sending 
packets to it for CUST1.

Eventually P1 should pass an announcement for CUST1 (learned from P2) 
to ASBR1 and ASBR1 updates its FIB. ASBR1 shouldn't see any traffic 
at all directed towards CUST1 though - it will be idle.

> -1- BGP knows the backup path, so it will install it in the RIB ==>
> packets to that destination are sent back to P1. Unfortunately, P1
> doesn't know yet that CUST-ASBR1 eBGP session is down. So it sends back
> to packet to ASBR1 ==> packets are looped between ASBR1 and P1.

If ASBR1 knows the backup path, that's ok. Because it will not update 
its FIB for a while - sufficient time for P1 to update its own RIB 
and FIB to point CUST1 route in the direction of P2.

This is all essentially what several people have been considering 
already, eg the "Ordered FIB Updates" draft (i think you're aware of 
it, no?):

 	http://bgp.potaroo.net/ietf/idref/draft-francois-ordered-fib/

Essentially, seems to me there are two rules of thumb:

 	- for a path shutdown, FIB updates should lag RIB updates

 	- for a path addition, FIB updates should lead RIB updates
 	  and propogation.

(iirc) Francois had a very interesting presentation at the routing 
area meeting on this. They're looking deeply at this already, 
mathematically AIUI (havn't seen any papers on that side of things 
though), so hopefully some really useful techniques will come out of 
that in time.

> Could you please have a look at slide 4 in our presentation?

Where is your presentation exactly? I remember the presentation only 
vaguely at this stage - note that powerpoint format is inconvenient 
for me.

> It looks to me that your proposition has been tested (The BGP 
> session have been shutdown, the interface has not even been 
> shutdown) and yet you lose some trafic.

If the FIB was updated, i can imagine so, yes.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
We'll try to cooperate fully with the IRS, because, as citizens, we feel
a strong patriotic duty not to go to jail.
 		-- Dave Barry

Content-class: urn:content-classes:message
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
Date: Wed, 10 Aug 2005 15:29:36 +0200
From: "DECRAENE Bruno RD-CORE-ISS" <[email-masked]>
To: "Paul Jakma" <[email-masked]>, "AHMAD Zubair EQUANT" <[email-masked]>
Cc: [email-masked], [email-masked], Olivier Bonaventure <[email-masked]>, vijay gill <[email-masked]>
Sender: [email-masked]

Hi Paul,

> At least one signalling method exists (CEASE) - why not implement 
> CEASE+wait first and get some experience of it before considering
> what protocol changes could make it work better?

Could you be a little more specific about your proposition?

>From your description, I understand that you close the BGP session
according to the BGP spec, then wait some time, then shut down the
interface and proceed with the maintenance.

If this is a correct understanding, let's take the following topology
(from the requirement draft):
                             '  
                             '  
                             '  
                       AS1   '      AS2  
                             '  

                       /-----------ASBR1-----P1----  
                      /                      |   
                     /                       |  
                 CUST                        | 
                     \                       | 
              X.Y/16  \                      | 
                       \-----------ASBR2-----P2---- 

                             '  
                             '  
                       AS1   '      AS2  
                             '  
                                      
                   Figure 1: Redundant peering example.  

We want to close CUST-ASBR1 link.

After sending the "CEASE" to CUST, ASBR1 removes the routes learned
through this eBGP session. You have 2 cases:

-0- BGP don't know the backup path, so it will remove the destination
from the RIB. ==> packets to the destination X.Y/16 (your customer) are
dropped on ASBR1.
-1- BGP knows the backup path, so it will install it in the RIB ==>
packets to that destination are sent back to P1. Unfortunately, P1
doesn't know yet that CUST-ASBR1 eBGP session is down. So it sends back
to packet to ASBR1 ==> packets are looped between ASBR1 and P1.

>I'd like to see:

> - implementation of the CEASE and wait solution
> - some field experience of it
> - maybe kind of informational ID discussing the previous two points

> *Then* and only then is it sensible to start talking about a 
> potential requirements draft for tackling any shortcomings in BGP wrt 
>maintainance, and possible suitable changes to it.

> Understand the problem first please (surely?).

Could you please have a look at slide 4 in our presentation?
It looks to me that your proposition has been tested (The BGP session
have been shutdown, the interface has not even been shutdown) and yet
you lose some trafic.

Regards,
Bruno

From: "Alok" <[email-masked]>
To: "Paul Jakma" <[email-masked]>
Subject: Re: [idr] BGP planned maintenance requirements as an IDR WG doc
Date: Wed, 10 Aug 2005 18:06:04 +0530
Cc: [email-masked]
Sender: [email-masked]

hi Paul,

just a couple of questions?

Why cant you simply what for the GR timers to time out before actually
pulling the router out of service?

In other words GR makes the assumption AFAIK that the remote router has to
come up in sometime.

if it doesnt, BGP declares the peer as down.

Simply dont pull the router out of service till the timers expire?
The remote end would automatically discover the peer is down in that time.
(coupled with the other post where you could track the incoming traffic on
forwarding plane to ensure static/policy routed peers also change their
routes)

-thanks
Alok
----- Original Message ----- 
From: "Paul Jakma" <[email-masked]>
To: <[email-masked]>
Cc: "DECRAENE Bruno RD-CORE-ISS" <[email-masked]>;
<[email-masked]>; <[email-masked]>; "Olivier Bonaventure"
<[email-masked]>; "vijay gill" <[email-masked]>
Sent: Wednesday, August 10, 2005 5:47 PM
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc

> Hi Zubair,
>
> On Wed, 10 Aug 2005, [email-masked] wrote:
>
> > ZA>> Well the signalling of maintenance action is definitely
> > needed.
> > only a requirements draft, I believe we should better focus on
> > clarifying and refining the requirements for planned maintenance
> > and leave the discussion about potential solutions for the next
> > step (solution proposal/draft)..
>
> Horse before cart please.
>
> At least one signalling method exists (CEASE) - why not implement
> CEASE+wait first and get some experience of it before considering
> what protocol changes could make it work better?
>
> I don't see how one can even know what the requirements are at this
> point in time.
>
> Get some operational experience of the 'CEASE + wait + shutdown
> forwarding' solution, only then can you know what would be useful to
> add to the actual BGP protocol.
>
> > ZA>> I agree that it would be nice if we can achieve the desired
> > behavior (i.e. graceful shutdown that eliminates or minimizes
> > packet loss during BGP convergence) using the so called 'trick'
> > implemented only locally (without requiring any protocol extensions
> > on the peers). However, such implementation must cover the various
> > topologies of interest that are presented in the draft.
>
> It does. The wait period just has to be long enough to allow everyone
> else to converge.
>
> > Again, I would suggest to leave this discussion on possible
> > soutions for the Solutions draft.
>
> What solutions draft?
>
> > ZA>> Interaction with GR is dependent on the type of solution
> > (trick) that gets implemented.  I think we should include this
> > point in the requirement draft that any solutions for BGP Graceful
> > Shutdown must consider & ensure compatibility with BGP GR (if GR
> > capability is enabled).
>
> I'd like to see:
>
> - implementation of the CEASE and wait solution
> - some field experience of it
> - maybe kind of informational ID discussing the previous two points
>
> *Then* and only then is it sensible to start talking about a
> potential requirements draft for tackling any shortcomings in BGP wrt
> maintainance, and possible suitable changes to it.
>
> Understand the problem first please (surely?).
>
> My recursion detector is telling me i've now been here before several
> times in this thread, so I'll bow out.
>
> regards,
> -- 
> Q: What is purple and concord the world?
> A: Alexander the Grape.
>

Date: Wed, 10 Aug 2005 13:17:17 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: [email-masked]
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
Mail-Copies-To: [email-masked]
Mail-Followup-To: [email-masked]
Cc: DECRAENE Bruno RD-CORE-ISS <[email-masked]>, [email-masked], [email-masked], Olivier Bonaventure <[email-masked]>, vijay gill <[email-masked]>
Sender: [email-masked]

Hi Zubair,

On Wed, 10 Aug 2005, [email-masked] wrote:

> ZA>> Well the signalling of maintenance action is definitely 
> needed.
> only a requirements draft, I believe we should better focus on 
> clarifying and refining the requirements for planned maintenance 
> and leave the discussion about potential solutions for the next 
> step (solution proposal/draft)..

Horse before cart please.

At least one signalling method exists (CEASE) - why not implement 
CEASE+wait first and get some experience of it before considering 
what protocol changes could make it work better?

I don't see how one can even know what the requirements are at this 
point in time.

Get some operational experience of the 'CEASE + wait + shutdown 
forwarding' solution, only then can you know what would be useful to 
add to the actual BGP protocol.

> ZA>> I agree that it would be nice if we can achieve the desired 
> behavior (i.e. graceful shutdown that eliminates or minimizes 
> packet loss during BGP convergence) using the so called 'trick' 
> implemented only locally (without requiring any protocol extensions 
> on the peers). However, such implementation must cover the various 
> topologies of interest that are presented in the draft.

It does. The wait period just has to be long enough to allow everyone 
else to converge.

> Again, I would suggest to leave this discussion on possible 
> soutions for the Solutions draft.

What solutions draft?

> ZA>> Interaction with GR is dependent on the type of solution 
> (trick) that gets implemented.  I think we should include this 
> point in the requirement draft that any solutions for BGP Graceful 
> Shutdown must consider & ensure compatibility with BGP GR (if GR 
> capability is enabled).

I'd like to see:

- implementation of the CEASE and wait solution
- some field experience of it
- maybe kind of informational ID discussing the previous two points

*Then* and only then is it sensible to start talking about a 
potential requirements draft for tackling any shortcomings in BGP wrt 
maintainance, and possible suitable changes to it.

Understand the problem first please (surely?).

My recursion detector is telling me i've now been here before several 
times in this thread, so I'll bow out.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Q:	What is purple and concord the world?
A:	Alexander the Grape.

From: "Alok" <[email-masked]>
To: <[email-masked]>
Subject: Re: [idr] BGP planned maintenance requirements as an IDR WG doc
Date: Wed, 10 Aug 2005 16:38:29 +0530
Sender: [email-masked]

>
> ZA>> I agree that it would be nice if we can achieve the desired behavior
> (i.e. graceful shutdown that eliminates or minimizes packet loss during
BGP
> convergence) using the so called 'trick' implemented only locally (without
> requiring any protocol extensions on the peers). However, such
> implementation must cover the various topologies of interest that are
> presented in the draft.  Again, I would suggest to leave this discussion
on
> possible soutions for the Solutions draft.
>
> The main immediate thing to look at is interaction of above
> implementation trick with the GR draft, maybe GR needs some changes
> to allow it to work nicely with above. Immediate in the "while GR is
> still a draft" sense ;). (this trick has some incompatibilies with GR
> it seems to me. If GR is enabled, the remote peer will assume your
> forwarding plane is staying up, initially at least).
>
> ZA>> Interaction with GR is dependent on the type of solution (trick) that
> gets implemented.  I think we should include this point in the requirement
> draft that any solutions for BGP Graceful Shutdown must consider & ensure
> compatibility with BGP GR (if GR capability is enabled).

Can someone please figure out how one can possibly *know* that there is no
traffic coming from peers?
How about: dont allow shutdown command if interface stats are increasing or
selective links, which can be specified are still up?

From: [email-masked]
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
To: Paul Jakma <[email-masked]>
Date: Wed, 10 Aug 2005 01:30:45 -0400
Cc: DECRAENE Bruno RD-CORE-ISS <[email-masked]>, [email-masked], [email-masked], Olivier Bonaventure <[email-masked]>, vijay gill <[email-masked]>
Sender: [email-masked]

Pls see some comments inline.
cheers,
Zubair

Zubair Ahmad
Equant - Network Technology & Architecture
13775 McLearen Road, Oak Hill VA
Phone: +1-703-375-8152

            Paul Jakma <[email-masked]>                                                                                                 
            Sent by: [email-masked]                                                                                              
            08/09/2005 03:46 PM                To: DECRAENE Bruno RD-CORE-ISS <[email-masked]>                       
                                               cc: [email-masked], vijay gill <[email-masked]>, Olivier Bonaventure                 
                                                  <[email-masked]>                                                         
                                               bcc:                                                                                    
                                               Subject:  RE: [idr] BGP planned maintenance requirements as an IDR WG doc               

On Tue, 9 Aug 2005, DECRAENE Bruno RD-CORE-ISS wrote:

> And signaling the future unreachability of some destinations before
> closing the BGP session could be part of the BGP signaling.

Just to reiterate points made already (given above comment suggets it
doesn't seem to have gotten through):

- Means for signalling /already/ exist within BGP, either:
      - (NOTIFY,CEASE), an implicit withdraw of all advertised routes
           as per normal when you shutdown a session.
      - obviously, withdrawing individual specific prefixes

- Hence: No support in protocol is directly required for an
   implementation to signal shutdown well before it actually performs
   its shut down

ZA>> Well the signalling of maintenance action is definitely needed.
However, it may rely on implicit BGP behavior (such as implicit Withdraw as
you mention).  The draft already clearly mentions that such signalling
mechanism may be either "implicit" or "explicit" (see section 4 - Goals &
Requirements).  Since this is only a requirements draft, I believe we
should better focus on clarifying and refining the requirements for planned
maintenance and leave the discussion about potential solutions for the next
step (solution proposal/draft)..

There is no /immediate/ need for protocol changes for the one "trick"
we've discussed here so far.

The route-reflector case you raised is a different thing imho,
requires full-reflection really and there are other drafts looking at
that.

ZA>> I agree that it would be nice if we can achieve the desired behavior
(i.e. graceful shutdown that eliminates or minimizes packet loss during BGP
convergence) using the so called 'trick' implemented only locally (without
requiring any protocol extensions on the peers). However, such
implementation must cover the various topologies of interest that are
presented in the draft.  Again, I would suggest to leave this discussion on
possible soutions for the Solutions draft.

The main immediate thing to look at is interaction of above
implementation trick with the GR draft, maybe GR needs some changes
to allow it to work nicely with above. Immediate in the "while GR is
still a draft" sense ;). (this trick has some incompatibilies with GR
it seems to me. If GR is enabled, the remote peer will assume your
forwarding plane is staying up, initially at least).

ZA>> Interaction with GR is dependent on the type of solution (trick) that
gets implemented.  I think we should include this point in the requirement
draft that any solutions for BGP Graceful Shutdown must consider & ensure
compatibility with BGP GR (if GR capability is enabled).

Other considerations:

- The delay between signalling shutdown and shutting down forwarding
probably should be larger than the time for all routers in your iBGP
to converge on the new set of routes, not the time for your immediate
peers. This delay factor is likely something an operator can
empirically determine for themselves. It may be interesting to
examine how the protocol could determine this automatically at some
stage in the future (once the 'trick' is implemented widely and there
is experience of it).

- Another thing to consider (or even, is being actively considered by
others, at least for IGP) is stuff like that 'Ordered FIB removal'
work and whether some of its tricks could apply to iBGP. Eg, as we've
discussed that shutdown of protocol should ideally occur before
forwarding shutdown, that draft also suggests that on starting up it
might be a good idea to 'listen but not speak' initially, before
proceeding to announce anything (self-originated or not). Ie
stabilise your forwarding plane first, before telling anyone they may
forward through you (maybe).

I suspect right now what is needed are implementations of the 'wait
between CEASE and forwarding shutdown' and field experience of it,
given no protocol work is actually needed, before proceeding
contemplating what actual protocol changes/additions would or would
not be useful.

I.e., right now, this is probably something to discuss with your
vendor, no?

regards,
--
Paul Jakma  [email-masked]     [email-masked]    Key ID: 64A2FF6A
Fortune:
If *I* had a hammer, there'd be no more folk singers.

Date: Tue, 9 Aug 2005 20:46:09 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: DECRAENE Bruno RD-CORE-ISS <[email-masked]>
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
Mail-Copies-To: [email-masked]
Mail-Followup-To: [email-masked]
Cc: [email-masked], vijay gill <[email-masked]>, Olivier Bonaventure <[email-masked]>
Sender: [email-masked]

On Tue, 9 Aug 2005, DECRAENE Bruno RD-CORE-ISS wrote:

> And signaling the future unreachability of some destinations before
> closing the BGP session could be part of the BGP signaling.

Just to reiterate points made already (given above comment suggets it 
doesn't seem to have gotten through):

- Means for signalling /already/ exist within BGP, either:
 	- (NOTIFY,CEASE), an implicit withdraw of all advertised routes
           as per normal when you shutdown a session.
 	- obviously, withdrawing individual specific prefixes

- Hence: No support in protocol is directly required for an
   implementation to signal shutdown well before it actually performs
   its shut down

There is no /immediate/ need for protocol changes for the one "trick" 
we've discussed here so far.

The route-reflector case you raised is a different thing imho, 
requires full-reflection really and there are other drafts looking at 
that.

The main immediate thing to look at is interaction of above 
implementation trick with the GR draft, maybe GR needs some changes 
to allow it to work nicely with above. Immediate in the "while GR is 
still a draft" sense ;). (this trick has some incompatibilies with GR 
it seems to me. If GR is enabled, the remote peer will assume your 
forwarding plane is staying up, initially at least).

Other considerations:

- The delay between signalling shutdown and shutting down forwarding 
probably should be larger than the time for all routers in your iBGP 
to converge on the new set of routes, not the time for your immediate 
peers. This delay factor is likely something an operator can 
empirically determine for themselves. It may be interesting to 
examine how the protocol could determine this automatically at some 
stage in the future (once the 'trick' is implemented widely and there 
is experience of it).

- Another thing to consider (or even, is being actively considered by 
others, at least for IGP) is stuff like that 'Ordered FIB removal' 
work and whether some of its tricks could apply to iBGP. Eg, as we've 
discussed that shutdown of protocol should ideally occur before 
forwarding shutdown, that draft also suggests that on starting up it 
might be a good idea to 'listen but not speak' initially, before 
proceeding to announce anything (self-originated or not). Ie 
stabilise your forwarding plane first, before telling anyone they may 
forward through you (maybe).

I suspect right now what is needed are implementations of the 'wait 
between CEASE and forwarding shutdown' and field experience of it, 
given no protocol work is actually needed, before proceeding 
contemplating what actual protocol changes/additions would or would 
not be useful.

I.e., right now, this is probably something to discuss with your 
vendor, no?

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
If *I* had a hammer, there'd be no more folk singers.

Content-class: urn:content-classes:message
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
Date: Tue, 9 Aug 2005 20:26:04 +0200
From: "DECRAENE Bruno RD-CORE-ISS" <[email-masked]>
To: "Ted Seely" <[email-masked]>, "vijay gill" <[email-masked]>
Cc: [email-masked], Olivier Bonaventure <[email-masked]>
Sender: [email-masked]

> > > If you send an email, you warn the human operators. If you send
BGP 
> > > messages, you warn the routers. I would prefer a model where BGP 
> > > routers  can automatically react to planned failures compared to a

> > > model where a human intervention is required to handle a planned
failure elsewhere.
> > >
> >
> > We do a lot of maintenances on our routers and we have a tool that 
> > automatically sends out mail to each contact that is on that 
> > particular router. The reason we do this is that people get irate
when 
> > sessions or traffic flows get disrupted (notice I said people, not 
> > routers) and they would like for prior notification so they aren't 
> > surprised when something alarms on their monitoring system. As
someone 
> > who is on-call, having a BGP session flap will almost always result
in 
> > a page. I'd rather my monitoring desk already be aware that there
will 
> > be an event and therefore, not page me.
> >
> > Also, for major peers etc, it is important to get notification, 
> > because it could be that we are in scheduled jeopardy and as such,
we 
> > can disallow that maintenance if necessary, esp. if we have backup 
> > capacity being down. Eg, one of my peers is upgrading code in 
> > frankfurt, and I'm upgrading code in london and frankfurt is acting
as a backup for london.
> > Having the routers understand the failure is completely useless to
me. 
> > I want people to understand so I can plan around the issue.
> 
> Well said Vijay.  This captures exactly why automation (signalled or
> invoked) can burn you.  Large networks where large amounts of 
> traffic will swing ( 500M to 1G+ ) when circuits go down 
> because of planned events must be coordinated at the human level.

I see two independent steps:
-1- Coordination at the human level using e-mail/phone/fax/letters.
-2- Having the networks/routers/BGP reroute the traffic with minimal
impact/loss.

The draft only deals with step 2. It doesn't mention that step 1 should
be skipped.

Coordination and carefull planification can only be done by humans.
IMO, BGP signaling can be done by routers without human intervention.
And signaling the future unreachability of some destinations before
closing the BGP session could be part of the BGP signaling. 

Date: Tue, 9 Aug 2005 14:01:17 -0400 (EDT)
From: Ted Seely <[email-masked]>
To: vijay gill <[email-masked]>
Subject: Re: [idr] BGP planned maintenance requirements as an IDR WG doc
Cc: [email-masked], Olivier Bonaventure <[email-masked]>
Sender: [email-masked]

On Mon, 8 Aug 2005, vijay gill wrote:

> Olivier Bonaventure wrote:
>
> >
> >
> > If you send an email, you warn the human operators. If you send BGP
> > messages, you warn the routers. I would prefer a model where BGP routers
> >  can automatically react to planned failures compared to a model where a
> > human intervention is required to handle a planned failure elsewhere.
> >
>
> We do a lot of maintenances on our routers and we have a tool that
> automatically sends out mail to each contact that is on that particular
> router. The reason we do this is that people get irate when sessions or
> traffic flows get disrupted (notice I said people, not routers) and they
> would like for prior notification so they aren't surprised when
> something alarms on their monitoring system. As someone who is on-call,
> having a BGP session flap will almost always result in a page. I'd
> rather my monitoring desk already be aware that there will be an event
> and therefore, not page me.
>
> Also, for major peers etc, it is important to get notification, because
> it could be that we are in scheduled jeopardy and as such, we can
> disallow that maintenance if necessary, esp. if we have backup capacity
> being down. Eg, one of my peers is upgrading code in frankfurt, and I'm
> upgrading code in london and frankfurt is acting as a backup for london.
> Having the routers understand the failure is completely useless to me. I
> want people to understand so I can plan around the issue.

Well said Vijay.  This captures exactly why automation (signalled or
invoked) can burn you.  Large networks where large amounts of traffic
will swing ( 500M to 1G+ ) when circuits go down because of planned events
must be coordinated at the human level.

-ted

> /vijay

To: Enke Chen <[email-masked]>
Subject: Re: [Idr] IDR WG Minutes 
Date: Tue, 09 Aug 2005 07:50:25 -0700
From: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

Enke,

> Hi, Yakov:
> 
> One comment below.
> 
> Yakov Rekhter wrote:
> 
> >Folks,
> >
> >Attached are the minutes. Please review for correctness *before*
> >end of this week.
> >
> >Yakov.
> >-------------------------------------------------------------------
> >
> >IDR WG notes 2005.08.04 -DWard
> >-------------------------
> >
> >Doc status
> >see ppt
> >
> >Danny McPherson to finish Confed implementation report in one month
> >
> >Geoff Houston to complete 4-octet AS number space
> >  
> >
> Some words are missing here - I believe that this one refers to the 
> "implementation report for the 4-octet AS Number".

Correct.

Yakov.

From: "john smith" <[email-masked]>
To: [email-masked]
Subject: Re: [idr] BGP planned maintenance requirements as an IDR WG doc
Date: Tue, 09 Aug 2005 07:43:40 +0000
Sender: [email-masked]

well all said and done,
I know atleast one router vendor who could possibly consider using the 
"rollback" feature to achieve this.

>From: vijay gill <[email-masked]>
>To: Olivier Bonaventure <[email-masked]>
>CC: [email-masked]
>Subject: Re: [idr] BGP planned maintenance requirements as an IDR WG doc
>Date: Mon, 08 Aug 2005 22:47:51 -0400

>
>Also, for major peers etc, it is important to get notification, because it 
>could be that we are in scheduled jeopardy and as such, we can disallow 
>that maintenance if necessary, esp. if we have backup capacity being down. 
>Eg, one of my peers is upgrading code in frankfurt, and I'm upgrading code 
>in london and frankfurt is acting as a backup for london. Having the 
>routers understand the failure is completely useless to me. I want people 
>to understand so I can plan around the issue.
>
>/vijay
>

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar - get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/

Date: Mon, 08 Aug 2005 21:46:41 -0700
From: Enke Chen <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Subject: Re: [Idr] IDR WG Minutes
Cc: [email-masked]
Sender: [email-masked]

Hi, Yakov:

One comment below.

Yakov Rekhter wrote:

>Folks,
>
>Attached are the minutes. Please review for correctness *before*
>end of this week.
>
>Yakov.
>-------------------------------------------------------------------
>
>IDR WG notes 2005.08.04 -DWard
>-------------------------
>
>Doc status
>see ppt
>
>Danny McPherson to finish Confed implementation report in one month
>
>Geoff Houston to complete 4-octet AS number space
>  
>
Some words are missing here - I believe that this one refers to the 
"implementation report for the 4-octet AS Number".

-- Enke

Date: Mon, 08 Aug 2005 22:47:51 -0400
From: vijay gill <[email-masked]>
To: Olivier Bonaventure <[email-masked]>
Subject: Re: [idr] BGP planned maintenance requirements as an IDR WG doc
Cc: [email-masked]
Sender: [email-masked]

Olivier Bonaventure wrote:

> 
> 
> If you send an email, you warn the human operators. If you send BGP
> messages, you warn the routers. I would prefer a model where BGP routers
>  can automatically react to planned failures compared to a model where a
> human intervention is required to handle a planned failure elsewhere.
> 

We do a lot of maintenances on our routers and we have a tool that 
automatically sends out mail to each contact that is on that particular 
router. The reason we do this is that people get irate when sessions or 
traffic flows get disrupted (notice I said people, not routers) and they 
would like for prior notification so they aren't surprised when 
something alarms on their monitoring system. As someone who is on-call, 
having a BGP session flap will almost always result in a page. I'd 
rather my monitoring desk already be aware that there will be an event 
and therefore, not page me.

Also, for major peers etc, it is important to get notification, because 
it could be that we are in scheduled jeopardy and as such, we can 
disallow that maintenance if necessary, esp. if we have backup capacity 
being down. Eg, one of my peers is upgrading code in frankfurt, and I'm 
upgrading code in london and frankfurt is acting as a backup for london. 
Having the routers understand the failure is completely useless to me. I 
want people to understand so I can plan around the issue.

/vijay

From: "john smith" <[email-masked]>
To: [email-masked]
Subject: Re: [idr] BGP planned maintenance requirements as an IDR WG doc
Date: Mon, 08 Aug 2005 21:44:21 +0000
Sender: [email-masked]

Well  i guess if they say so then they must be right.
Lets go ahead with this feature!! what are we waiting for! :)

>From: Olivier Bonaventure <[email-masked]>
>To: john smith <[email-masked]>
>CC: [email-masked], [email-masked]
>Subject: Re: [idr] BGP planned maintenance requirements as an IDR WG doc
>Date: Mon, 08 Aug 2005 23:22:39 +0200
>
>John,
>
> >
> >> All those solutions try to avoid as much as possible packet losses. The
> >> document proposed by Nicolas and Bruno is another useful step in this
> >> direction. Reacting to planned failures is important as measurements
> >> done in ISP networks have shown that a large fraction of the failures
> >> are indeed planned.
> >>
> >
> > Please let me know which is the institute invests time and money only to
> > come to a conclusion that "failures are planned".
> > I would like to see the data and their defination of a so called
> > "planned failure". :)
>
>Basically, they assumed that if the failures occur during maintenance
>hours they are caused by manual operations and thus are planned. See e.g. :
>http://www.cambridge.intel-research.net/~gianluca/talks/icnp-tutorial.pdf
>, slide 61
>
>http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-routing-fcp.pdf,
>slide 5
>
>
> >
> >> Another point to consider when evaluating this document is the
> >> following. Today, most operators perform their maintenance operations
> >> early in the morning, e.g. 4-6 am to reduce the impact of the
> >> maintenance. From a human ressource viewpoint, this implies that 
>special
> >> staff is required during the night shift. This increases the costs of
> >> the ISP. If it was possible to perform maintenance operations during 
>the
> >> day *without impacting traffic and causing any packet loss*, I'm sure
> >> that ISPs would prefer to perform their maintenace during the day while
> >> all the engineers are available to react in case of problems.
> >
> >
> > How has the time of day got anything to do with the matter? Your peers
> > will never be able to rewrite their policies in 3 minutes, whether you
> > perform the "planned failure" at 2am or 2pm. You would have to give them
> > a few hours of prior notification.
>
>You assume that the peer should perform manual operations to handle the
>planned failure. I would prefer a solution where the BGP routers in the
>peer automatically adapt to the planned failure.
>
> >
> >> This would
> >> require the ability  to change any configuration without causing any
> >> packet loss. Nicolas and Bruno's draft are one step in this direction
> >> for eBGP.
> >>
> >
> > I think I just pointed out above how a just a few minutes of warning can
> > lead to packet loss. While I do understand what you are trying to say, I
> > do not get why you feel signalling a "planned failure" gives one any
> > greater advantage than sending an email?
> >
>
>If you send an email, you warn the human operators. If you send BGP
>messages, you warn the routers. I would prefer a model where BGP routers
>  can automatically react to planned failures compared to a model where a
>human intervention is required to handle a planned failure elsewhere.
>
>
>
>Olivier

_________________________________________________________________
Don't just search. Find. Check out the new MSN Search! 
http://search.msn.com/

Date: Mon, 08 Aug 2005 23:22:39 +0200
From: Olivier Bonaventure <[email-masked]>
To: john smith <[email-masked]>
Subject: Re: [idr] BGP planned maintenance requirements as an IDR WG doc
Cc: [email-masked], [email-masked]
Sender: [email-masked]

John,

> 
>> All those solutions try to avoid as much as possible packet losses. The
>> document proposed by Nicolas and Bruno is another useful step in this
>> direction. Reacting to planned failures is important as measurements
>> done in ISP networks have shown that a large fraction of the failures
>> are indeed planned.
>>
> 
> Please let me know which is the institute invests time and money only to
> come to a conclusion that "failures are planned".
> I would like to see the data and their defination of a so called
> "planned failure". :)

Basically, they assumed that if the failures occur during maintenance
hours they are caused by manual operations and thus are planned. See e.g. :
http://www.cambridge.intel-research.net/~gianluca/talks/icnp-tutorial.pdf
, slide 61

http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-routing-fcp.pdf,
slide 5

> 
>> Another point to consider when evaluating this document is the
>> following. Today, most operators perform their maintenance operations
>> early in the morning, e.g. 4-6 am to reduce the impact of the
>> maintenance. From a human ressource viewpoint, this implies that special
>> staff is required during the night shift. This increases the costs of
>> the ISP. If it was possible to perform maintenance operations during the
>> day *without impacting traffic and causing any packet loss*, I'm sure
>> that ISPs would prefer to perform their maintenace during the day while
>> all the engineers are available to react in case of problems.
> 
> 
> How has the time of day got anything to do with the matter? Your peers
> will never be able to rewrite their policies in 3 minutes, whether you
> perform the "planned failure" at 2am or 2pm. You would have to give them
> a few hours of prior notification.

You assume that the peer should perform manual operations to handle the
planned failure. I would prefer a solution where the BGP routers in the
peer automatically adapt to the planned failure.

> 
>> This would
>> require the ability  to change any configuration without causing any
>> packet loss. Nicolas and Bruno's draft are one step in this direction
>> for eBGP.
>>
> 
> I think I just pointed out above how a just a few minutes of warning can
> lead to packet loss. While I do understand what you are trying to say, I
> do not get why you feel signalling a "planned failure" gives one any
> greater advantage than sending an email?
> 

If you send an email, you warn the human operators. If you send BGP
messages, you warn the routers. I would prefer a model where BGP routers
 can automatically react to planned failures compared to a model where a
human intervention is required to handle a planned failure elsewhere.

Olivier

From: "john smith" <[email-masked]>
To: [email-masked]
Subject: Re: [idr] BGP planned maintenance requirements as an IDR WG doc
Date: Mon, 08 Aug 2005 21:09:05 +0000
Cc: [email-masked], [email-masked]
Sender: [email-masked]

> >
> > What about "his" customers? His SLAs may be more stringent than your
> > SLAs...
> >
> > I would agree with Howard in a way, GROW would be a nice place to bring
> > this up.
> > As far as i know most people rely on exchanging information a few hours
> > prior to a restart.
> >
>
>To understand the requirements from Nicolas and Bruno, we have to
>consider that the Internet has changed. Ten years ago, routing protocols
>were used to support mainly researchers sending best effort packets. For
>those users, loosing ten seconds worth of packets was not a problem.

ok

>
>Today, IP routing protocols are used to support IP and MPLS-based
>networks carrying various types of mission critical data including :
>- Voice over IP
>- Video over IP
>- Virtual Private Networks
>- various types of leased line emulation

ok

>
>For many of those services, SPs are pushed by their customers to offer
>stringent Service Level Agreements. If those SLAs are not met, the
>customer is often eligible for a refund. To avoid losing packets,
>Service Providers use various types of techniques. In the data plane,
>marking, scheduling, buffer acceptance are commonly used to favor
>important packets over others. In the control plane, several approaches
>are used :
>- tune the implementation of the routing protocols to achieve sub-second
>convergence. This is possible with ISIS/OSPF, but is more challenging
>with BGP
>- use MPLS-based fast reroute techniques to protect important LSPs in
>case of failures
>- develope IP-based fast reroute techniques to provide similar
>mechanisms for pure IP networks
>

ok.

>All those solutions try to avoid as much as possible packet losses. The
>document proposed by Nicolas and Bruno is another useful step in this
>direction. Reacting to planned failures is important as measurements
>done in ISP networks have shown that a large fraction of the failures
>are indeed planned.
>

Please let me know which is the institute invests time and money only to 
come to a conclusion that "failures are planned".
I would like to see the data and their defination of a so called "planned 
failure". :)

>Another point to consider when evaluating this document is the
>following. Today, most operators perform their maintenance operations
>early in the morning, e.g. 4-6 am to reduce the impact of the
>maintenance. From a human ressource viewpoint, this implies that special
>staff is required during the night shift. This increases the costs of
>the ISP. If it was possible to perform maintenance operations during the
>day *without impacting traffic and causing any packet loss*, I'm sure
>that ISPs would prefer to perform their maintenace during the day while
>all the engineers are available to react in case of problems.

How has the time of day got anything to do with the matter? Your peers will 
never be able to rewrite their policies in 3 minutes, whether you perform 
the "planned failure" at 2am or 2pm. You would have to give them a few hours 
of prior notification.

>This would
>require the ability  to change any configuration without causing any
>packet loss. Nicolas and Bruno's draft are one step in this direction
>for eBGP.
>

I think I just pointed out above how a just a few minutes of warning can 
lead to packet loss. While I do understand what you are trying to say, I do 
not get why you feel signalling a "planned failure" gives one any greater 
advantage than sending an email?

>
>Best regards,
>
>
>Olivier
>
>
>
>
>--
>CSE Dept. UCL, Belgium - http://www.info.ucl.ac.be/people/OBO/
^^^^^^^^^^^^^^^^

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Date: Mon, 08 Aug 2005 22:42:06 +0200
From: Olivier Bonaventure <[email-masked]>
To: john smith <[email-masked]>
Subject: Re: [idr] BGP planned maintenance requirements as an IDR WG doc
Cc: [email-masked], [email-masked]
Sender: [email-masked]

John,
> 
> What about "his" customers? His SLAs may be more stringent than your
> SLAs...
> 
> I would agree with Howard in a way, GROW would be a nice place to bring
> this up.
> As far as i know most people rely on exchanging information a few hours
> prior to a restart.
> 

To understand the requirements from Nicolas and Bruno, we have to
consider that the Internet has changed. Ten years ago, routing protocols
were used to support mainly researchers sending best effort packets. For
those users, loosing ten seconds worth of packets was not a problem.

Today, IP routing protocols are used to support IP and MPLS-based
networks carrying various types of mission critical data including :
- Voice over IP
- Video over IP
- Virtual Private Networks
- various types of leased line emulation

For many of those services, SPs are pushed by their customers to offer
stringent Service Level Agreements. If those SLAs are not met, the
customer is often eligible for a refund. To avoid losing packets,
Service Providers use various types of techniques. In the data plane,
marking, scheduling, buffer acceptance are commonly used to favor
important packets over others. In the control plane, several approaches
are used :
- tune the implementation of the routing protocols to achieve sub-second
convergence. This is possible with ISIS/OSPF, but is more challenging
with BGP
- use MPLS-based fast reroute techniques to protect important LSPs in
case of failures
- develope IP-based fast reroute techniques to provide similar
mechanisms for pure IP networks

All those solutions try to avoid as much as possible packet losses. The
document proposed by Nicolas and Bruno is another useful step in this
direction. Reacting to planned failures is important as measurements
done in ISP networks have shown that a large fraction of the failures
are indeed planned.

Another point to consider when evaluating this document is the
following. Today, most operators perform their maintenance operations
early in the morning, e.g. 4-6 am to reduce the impact of the
maintenance. From a human ressource viewpoint, this implies that special
staff is required during the night shift. This increases the costs of
the ISP. If it was possible to perform maintenance operations during the
day *without impacting traffic and causing any packet loss*, I'm sure
that ISPs would prefer to perform their maintenace during the day while
all the engineers are available to react in case of problems. This would
require the ability  to change any configuration without causing any
packet loss. Nicolas and Bruno's draft are one step in this direction
for eBGP.

Best regards,

Olivier

-- 
CSE Dept. UCL, Belgium - http://www.info.ucl.ac.be/people/OBO/

Date: Mon, 08 Aug 2005 13:19:44 -0700
From: Robert Raszuk <[email-masked]>
Organization: Signature: http://www.employees.org/~raszuk/sig/
To: Paul Jakma <[email-masked]>
Subject: Re: [idr] BGP planned maintenance requirements as an IDR WG doc
Cc: DECRAENE Bruno RD-CORE-ISS <[email-masked]>, [email-masked], FONDEVIOLE Benoit RD-CORE-ISS <[email-masked]>, DUBOIS Nicolas ROSI-DAS-ARI <[email-masked]>
Reply-To: [email-masked]
Sender: [email-masked]

Paul,

Why do you ever need to shut IBGP session ? Those are to loopbacks and 
you have two choices:

* Take out an entire router (ISIS overload bit or OSPF max age LSA is 
your friend here)

* Take out a line card .. loopback should be still reachable via the IGP.

Cheers,
R.

> On Mon, 8 Aug 2005, DECRAENE Bruno RD-CORE-ISS wrote:
> 
>> - If you have RRs, iBGP routers (including your RR) may not have the 
>> backup path. The RR will propagate the withdraw and the destination 
>> will be removed from the RIB.
> 
> 
> So you'd need some kind of full-reflection extension to BGP...
> 
> regards,

Date: Mon, 8 Aug 2005 15:02:09 -0400
From: Jeffrey Haas <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Subject: WG Last Call on IANA Considerations (was Re: [Idr] IDR WG Minutes)
Cc: [email-masked]
Sender: [email-masked]

On Mon, Aug 08, 2005 at 08:06:55AM -0700, Yakov Rekhter wrote:
> SAFI Space Partition
> In reply to Jeff Hass email on list.

Typo on my last name. :-)

> Fenner to send notes on how to alloc SAFI space.
> 
> Proposal: take private use space and turn it into reserved and 
> perhaps 16 or so as private use. Reserved is reserved so we can 
> decide later on FCFS or otherwise managed.
> 
> Are folks using private space? Do we need to skip some?
> 
> Rekhter: How long will it take to use up first come first served?
> 
> Fenner: We should be able to straighten this out quickly and IANA is 
> keeping up. 30 days deadline.
> 
> Danny McPherson: Needs to be uniform across all WGs and Areas. Make 
> it IETF aligned.
> 
> Roque: I do not want to see vendor specific space go away altogether. 

I'll stop here.

If we examine RFC 2434, there's no such thing as "vendor specific space".
Private space means something else.

"Vendor space", I believe, is simply a specific instance of a FCFS
policy .  Arguably, it might even fall under the category of 
"specification required".

If this belief matches what IANA believes is reality, I'll make a 
slightly different proposal for the last call.

Keep 240-255 as "private" or special case 255 as "reserved" with
the usual idea of "keep a 'bit' around for extensions".  This should
provide enough space for experimentation where you don't care
about numbering conflicts (see RFC 2434).

Reserve 224-239.

Extend FCFS all the way up to 223.  Declare victory on SAFI 128
and friends by saying that it was FCFS anyway. :-)

Given what sounds like strong disagreement with "getting rid of vendor
specific space", I'll state for the record that I never objected
to that.  It is my belief that people just misunderstood what "private"
really meant.  FCFS was always the right answer.  IMO, early allocation
should be encouraged for solutions we expect to be widely deployed.

That said, it's just a number.

-- 
Jeff Haas 
NextHop Technologies

To: John Smith <[email-masked]>
Subject: Re: [Idr] IDR WG Minutes 
Date: Mon, 08 Aug 2005 11:14:30 -0700
From: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

John,

> > Paul ??: If in ECMP case, what AS sequence? How to pass multiple 
> > paths to a legacy speaker?
> > 
> > Retana:  Cap advert defines who can learn add_path. Other 
> > applications like EBGP ECMP and propagating multiple paths will have 
> > to be addressed.
> > 
> > Retana: Constrained scope.
> 
> I dont think we should be considering proposals that preclude advertising and
> using BGP ECMP routes. More so when the WG is considering taking this up 
> as an item. 

Please repost this point once we'll start a discussion on the mailing
list about this work (I am going to post an e-mail on this topic shortly).

> > Rekhter: We can have as many ad hoc solutions as we want or a more 
> > general solution. We as a group should decide on a more general 
> > solution. We should look at potential new functionality once we have 
> > more than one path being advertised.
> > Suggestion is that the authors of three proposals should find common 
> 
> Which third proposal?

Here are the three proposals (in no particular order):

draft-bhatia-ecmp-routes-in-bgp-01.txt 
draft-zhang-idr-bgp-entire-routes-reflect-00.txt
draft-walton-bgp-add-paths-03.txt

> > solution to all problems that WG would like to address. A mailing 
> > list will be set up to discuss this problem and solution. On the IDR
> > mailing list please identify problems.
> 
> A good step IMO.
> 
> > 
> > Rekhter: Do we need requirements document?
> > 
> > Ward: No, absolutely not.
> 
> John 

Yakov.

To: [email-masked]
Date: Mon, 08 Aug 2005 11:06:34 -0700
From: Yakov Rekhter <[email-masked]>
Cc: Bill Fenner <[email-masked]>
Subject: [Idr] WG Last Call on IANA Considerations for 2858bis
Sender: [email-masked]

Folks,

This is to start the WG Last Call on the proposal from Bill Fenner
to modify the IANA Consideration section of 2858bis along the
following lines:

  - Keep 1-63 as "IETF Consensus/Early Allocation" and 64-127 as "FCFS"
  - Register 128 as "IETF Consensus"
  - Reclassify 129-239 as "Reserved".
  - Retain 240-255 as "private use".
  - As needed, register values in the Reserved range if previously-deployed
    protocols come into the IETF.
  - Recommend that new developments use FCFS or RFC4020 method to get
    code points
  - In the future, if we run out of FCFS or IETF Consensus numbers,
    start using the "Reserved" space as needed.

The modified IANA Consideration section will look as follows:

   As specified in this document, the MP_REACH_NLRI and MP_UNREACH_NLRI
   attributes contain the Subsequence Address Family Identifier (SAFI)
   field. The SAFI name space is defined in this document. The IANA will
   maintain and register values for the SAFI namespace as follows. 
   
   SAFI values 1 and 2 are assigned in this document.  SAFI values
   4 through 63, 65, and 128 are to be assigned by IANA using either
   the "IETF Consensus" policy defined in RFC2434 or the "Early
   IANA Allocation" policy defined in RFC4020. SAFI values 64 and
   66 through 127 are to be assigned by IANA, using the "First  Come
   First Served" policy defined in RFC2434. SAFI values 240 through
   255 are for "private use", and are not to be assigned by IANA.
   SAFI values 0, 3, and 129 through 239 are reserved.

The deadline for comments is Aug 22, 2005.

Yakov.

Date: Mon, 8 Aug 2005 19:00:48 +0100 (BST)
From: John Smith <[email-masked]>
Subject: RE: [Idr] IDR WG Minutes
To: [email-masked]
Sender: [email-masked]

> Paul ??: If in ECMP case, what AS sequence? How to pass multiple 
> paths to a legacy speaker?
> 
> Retana:  Cap advert defines who can learn add_path. Other 
> applications like EBGP ECMP and propagating multiple paths will have 
> to be addressed.
> 
> Retana: Constrained scope.

I dont think we should be considering proposals that preclude advertising and using BGP
ECMP routes. More so when the WG is considering taking this up as an item. 

> Rekhter: We can have as many ad hoc solutions as we want or a more 
> general solution. We as a group should decide on a more general 
> solution. We should look at potential new functionality once we have 
> more than one path being advertised.
> Suggestion is that the authors of three proposals should find common 

Which third proposal?

> solution to all problems that WG would like to address. A mailing 
> list will be set up to discuss this problem and solution. On the IDR
> mailing list please identify problems.

A good step IMO.

> 
> Rekhter: Do we need requirements document?
> 
> Ward: No, absolutely not.

John 

___________________________________________________________ 
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

From: "john smith" <[email-masked]>
To: [email-masked]
Subject: Re: [idr] BGP planned maintenance requirements as an IDR WG doc
Date: Mon, 08 Aug 2005 17:30:14 +0000
Cc: [email-masked]
Sender: [email-masked]

What is wrong with tracking the state of the FT :( as specific in the GR
It is not like it is patented or something.....

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Date: Mon, 8 Aug 2005 13:06:32 -0400 (EDT)
From: Ted Seely <[email-masked]>
To: john smith <[email-masked]>
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
Cc: [email-masked]
Sender: [email-masked]

On Sun, 7 Aug 2005, john smith wrote:

> Hi,
>
> I think if *we know* that a bomb is going to fall on our town at X'oclock,
> we warn everyone to leave town beforehand.... and not wait till the last
> minute and send out a message?
>
> So generally most operators simply send out an "email" to the peering NOCs.
> Practical..no?
>

yes, and we also gracefully bleed the traffic off affected ckt(s) prior
to said scheduled maintenances.

in the case where it is not scheduled, you usually have to wait for the
router to finish booting anyway, so .....  :)  Perhaps one day we'll solve
that problem as well.

-ted

>
> -JS
>
> _________________________________________________________________
> Express yourself instantly with MSN Messenger! Download today it's FREE!
> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
>
>

Ted Seely
Principal Network Design Engineer
Internet Engineering - SprintLink
(W) 703.689.6425
(M) 703.967.3289
AIM - wanpro00
Yahoo IM - tseely01

"granular process independence, fault containment, and isolation"

Date: Mon, 8 Aug 2005 18:17:14 +0300 (EEST)
From: Pekka Savola <[email-masked]>
To: Curtis Villamizar <[email-masked]>
Subject: Re: [idr] BGP planned maintenance requirements as an IDR WG doc 
Cc: DECRAENE Bruno RD-CORE <[email-masked]>, [email-masked], FONDEVIOLE Benoit RD-CORE <[email-masked]>, DUBOIS Nicolas ROSI/DAS/ARI <[email-masked]>
Sender: [email-masked]

On Sun, 7 Aug 2005, Curtis Villamizar wrote:
> Sorry.  I used to maintain a tier-1 network and I can't see why it
> would be so difficult to change policy to not advertise the EBGP into
> IBGP, then not accept the EBGP, then shut down the EBGP.

There is a wide world beyond tier-1's.  I don't think this is so much 
an issue of clue, but rather the amount of time wasted (and the 
potential for typos and other similar results) when performing manual 
operations.

Where tier-1's might differ from the rest is that maybe they have more 
BGP maintenances that writing scripts etc. to deal with these events 
is worth the effort and their continuing maintenance.

For the rest, all of these actions would need to be done manually. 
Doing so is a pain in the ass.  As an operator of a smaller network, 
I'd certainly be happy to see the implementations move to sane or 
easily configurable default behaviour (which may or may not include 
protocol enhancements).

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

Content-class: urn:content-classes:message
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
Date: Mon, 8 Aug 2005 17:13:25 +0200
From: "DECRAENE Bruno RD-CORE-ISS" <[email-masked]>
To: "john smith" <[email-masked]>, <[email-masked]>
Cc: 
Sender: [email-masked]

Let's put it in another way.

BGP needs to advertise the unreachability of some destinations. If BGP
had a minute before the real failure (in the forwarding plane), could it
advertise the unreachability in a way that no (or minimal) packet to
these destination were lost?

A similar topic is discused in rtg-wg with the doc
draft-francois-ordered-fib-00.txt but for the intra-AS case.

> any vendor has a hook into microsoft outlook calender with BGP? ;-)
> 
> >From: "john smith" <[email-masked]>
> >To: [email-masked], [email-masked]
> >Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG 
> >doc
> >Date: Mon, 08 Aug 2005 14:33:01 +0000
> >
> >Hi,
> >
> >What about "his" customers? His SLAs may be more stringent than your 
> >SLAs...
> >
> >I would agree with Howard in a way, GROW would be a nice 
> place to bring 
> >this up.
> >As far as i know most people rely on exchanging information 
> a few hours 
> >prior to a restart.
> >
> >>From: "DECRAENE Bruno RD-CORE-ISS" 
> <[email-masked]>
> >>To: "john smith" <[email-masked]>,<[email-masked]>
> >>Subject: RE: [idr] BGP planned maintenance requirements as 
> an IDR WG 
> >>doc
> >>Date: Mon, 8 Aug 2005 16:14:10 +0200
> >>
> >> > ....Well but if they are heavy traffic bearing links it would be 
> >> > better to inform your peers a few hours in advance so 
> that he can 
> >> > rewrite his policies.. it is also his $$ after all :-)
> >>
> >>If it's my customer (Internet or VPN) this is my $$ if I 
> broke the SLA.
> >>In a BGP/MPLS VPN situation, if I manage the CE, it's my 
> time/money to 
> >>rewrite it's policy.
> >>
> >>
> >> > >Hi John,
> >> > >
> >> > > > Hi,
> >> > > >
> >> > > > I think if *we know* that a bomb is going to fall on 
> our town 
> >> > > > at X'oclock, we warn everyone to leave town beforehand....
> >> > > > and not wait till the last minute and send out a message?
> >> > >
> >> > >That's exactly our point.
> >> > >We know the forwarding will be shutdown. Why wait the 
> last second 
> >> > >to send a BGP CEASE? Why not inform all your BGP peers a few 
> >> > >seconds/minutes before? In a way that would allow minimal
> >> > packet loss
> >> > >during BGP convergence.
> >> > >
> >> > >
> >> > > > So generally most operators simply send out an 
> "email" to the 
> >> > > > peering NOCs.
> >> > > > Practical..no?
> >> > >
> >> > >Warning the peer is one thing. Shuting down the session with 
> >> > >minimal pack loss is still desirable.
> >> > >
> >> > >In some situation, we don't care about loosing some trafic
> >> > or both NOC
> >> > >we'll write some route map/policy to gracefully reroute the
> >> > packets (or
> >> > >believe so).
> >> > >
> >> > >In some other situation, customers do cares about their 
> SLA, and 
> >> > >modifying the route map each time is too error prone and 
> >> > >time/money consuming.
> >> >
> >> > _________________________________________________________________
> >> > Express yourself instantly with MSN Messenger! Download 
> today it's 
> >> > FREE!
> >> > http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
> >> >
> >> >
> >
> >_________________________________________________________________
> >Don't just search. Find. Check out the new MSN Search! 
> >http://search.msn.click-url.com/go/onm00200636ave/direct/01/
> >
> >
> _________________________________________________________________
> Express yourself instantly with MSN Messenger! Download today 
> it's FREE! 
> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
> 
> 

To: [email-masked]
Date: Mon, 08 Aug 2005 08:06:55 -0700
From: Yakov Rekhter <[email-masked]>
Subject: [Idr] IDR WG Minutes
Sender: [email-masked]

Folks,

Attached are the minutes. Please review for correctness *before*
end of this week.

Yakov.
-------------------------------------------------------------------

IDR WG notes 2005.08.04 -DWard
-------------------------

Doc status
see ppt

Danny McPherson to finish Confed implementation report in one month

Geoff Houston to complete 4-octet AS number space

New MIB editor see draft

-------------------------
Li AS Hop count Attribute

see ppt for info
Essence: Add TTL to each prefix, decrement at AS boundary
Drop route when TTL hits zero
Transitive attribute

Alt: Distribution Lists
List contains ASs that can rx and cannot exclusion

NOTE: NO_EXPORT and AS_HOPCOUNT can be combined

Houston: is NO_EXPORT dropped or continued when combined?

NOTE:  Can scope 'anycast'

Houston: when aspath prepending, is that expressed in the HOP_COUNT?
Li: Decremented by one always

Hares: Two more ASPATHS per route? How does scaling work?
Li: In the worst case, when setting up a list you can have an 
arbitrary  number in incl or excl list?

Hares: Is order semantics true but,

Rekhter: An ASPATH cannot carry all AS in the internet as not enough space

Li: An avg ASPATH has ~4 AS' in it so, we are going to have on avg 
roughly two X

Hares: Why do you say proxy usage is diffficult in Dist List case? 
TTL is lighter but, why choose between two? Might have both.

Li: From an implementors POV, it is easier to do one and not two

Rekhter: The increase in number of AS' per route is not a practical issue

Houston: At the edge, it may work but, topology is dense and we nee

Jason Schiller (UUNET): Scope - useful in subconfeds ... need  a 
separate counter?

Li: Want to see draft first. Technically what is required is a 
separate attribute but, look almost identical

Houston: When comparing the two mechanisms need to look at "what is 
going on." Distribution lists require complete knowledge of topology. 
Problem is that you cannot insure that they do not leak. HOPCOUNT 
does not have 'knowledge' problem but, focuses on accuracy.

Hares: Inclusion requires enumeration but exclusion does not

Houston: HOPCOUNT allows more specifics w/ a boundary. Advocates HOPCOUNT

Roque: No productive compare the two. Want to select upstream 
provider w/ targeted ext comms. HOPCOUNT might prevent this 
technique. Most common TE technique; customers preferring transit AS' 
per prefix. Not applicable for transit exit scenario. Two issues and 
solutions are orthogonal but, neither solution is devalued.

Chris Morrow (UUNET): proxy means "I can add" and/or "I can delete"

Li: Yes and not violate

Chris; Will it get used if provider ignores or removes

Rekhter: Who is entity that benefits from this? Which SP.

Li: Table size reduction is goal. One SP adds does the work but, gets 
no benefits. Altruism or hope of it is a good reason.

Houston: Zhang drafts in GROW show that altruism is bunk instead 
self-interest. Most UPDATEs come from lower tier points. Most 
computation happens at lower level of peering .. therefore, small 
folks get most thrash. If "I" do this, I help my problem ... 
therefore altruism is there for the folks that use it and tag it.

David Ward: Affect Hop count?

Li: Not significantly as it would be longer prefixes.

Enke: Can we inject an AS numer as 'signature' of who adds attribute?

May be added to draft. No comments

-------------------------
Zhang Renhai Entire Route Reflect

Comments held until after Walton's draft
see ppt for info

-------------------------
Walton Add Paths
Alvaro Retana (Cisco) presenter.
see ppt for info

NOTE: RFC 3107 must be updated

-------------------------
Walton Oscillation Stop
Alvaro Retana (Cisco) presenter
info in same ppt as "Add Paths"

Swallow: What is frequency of oscillation?

Retana: dependent on update timer setting (MIN ADVERT INTERVAL)

Combined questions for both draft authors:
Danny (unaffiliated) - We are increasing and decreasing table size. 
Walton's draft is more general and flexible then Zhang's.

Retana: Most of increase of table size is internal to an AS (almost all)

zhang: I don't understand question.

Zhang: Walton's draft is more general. Because you add attribute, do 
you think that efficiency of packing will be affected?

Retana: NLRI will be bigger but, no impact on packing.

Gargi (Cisco): Zhang's draft - must specify that you explicitly WD 
when a nexthop changes or how to announce new NH?  How do you delete 
the first NH?

Zhang: If NH changes, just add it. To solve the problem there will 
taken offline to email.

Paul ??: If in ECMP case, what AS sequence? How to pass multiple 
paths to a legacy speaker?

Retana:  Cap advert defines who can learn add_path. Other 
applications like EBGP ECMP and propagating multiple paths will have 
to be addressed.

Retana: Constrained scope.

Roque: Although you say impact of deployment is localized. We need a 
better understanding of what impact will be. For each route prefix, 
path attrs in Adj RIB Out. Generally announcement, is only  when 
Adj-RIB-Out changes. What is expectation of propagating changes when 
inbound updates would cause outbound content. What are consequences? 
Size of Adj-RIB-Out? What is key of Adj-RIB-Out? etc.

Retana: Spec says send on path. Change is that we would have tracking 
of two or more paths.

Rekhter: We can have as many ad hoc solutions as we want or a more 
general solution. We as a group should decide on a more general 
solution. We should look at potential new functionality once we have 
more than one path being advertised.
Suggestion is that the authors of three proposals should find common 
solution to all problems that WG would like to address. A mailing 
list will be set up to discuss this problem and solution. On the IDR
mailing list please identify problems.

Rekhter: Do we need requirements document?

Ward: No, absolutely not.

-------------------------
Dubois PM Reqmts

see ppt for info

Rekhter: Send note to list on whether or not we should take as a WG doc.

Dubois: Earlier solution was not meeting requirements and there are 
many possible solutions. We need a solution that fits the 
requirements; we are not encouraging one solution over another:

Ted Seely (Sprint): Why not weight traffic away from peer or 
interface? There are other techniques that don't require change to 
protocol.

Ruediger Volk: I lose traffic when I do this technique.

Ruediger: The convergence problem I see is due to the previous issue 
of config change.

Jason Schiller (UUNET): Is there a hard requirement that this does 
not require a config change ... taken to the list.

-------------------------
Hares Dynamic Confed AS

Not requested to be WG item.
see ppt for info

Roque: I would assume that you would want to do restoration in a 
seamless way. What is motivation to make failure restoration a 
visible outside the confederation?

SKH: Goal is to not drop the peering session. Therefore, the purpose 
is policy rerouting wants to 'hang by itself.' If I drop out of the 
AS confed, I would have had to drop the session.

Roque: Why not just tunnel back?

SKH: No IGP connectivity and tunnels ran into problems.
SKH: will send scenarios to list

Chandra Appanna (Cisco): I think you need a few more failsafes. 
Resend is a MUST, and some mechanisms is nec. that moved did not 
suddenly change. Need to resend routes due to policy change potential.

SKH: We have added failsafe. We delayed resend, it would be abnormal 
to send all routes if nothing changed. Will send scenario in email.

Gargi (Cisco): Are there any mechanisms in mind for NO resend if ones 
moves from one confed to another?

-------------------------
Multisession update - Chandra Appanna

See ppt for info

Added flexibility for any capability code to cause/create multiple sessions

No comments

-------------------------
Kapoor SSA - Gargi, Scott Wainner

see ppt for info

-------------------------
Kapoor Tunnel SAFI

combined w/ SSA preso, same ppt

Gargi did technical side and changes to docs:

more TLVs to express encap:

MPLS, IPsec, GRE in IPsec, L2TPv3 in IPsec

added application scenarios: MPLS over IP tunnels

Scott presented motivations

Combined comments:

SKH: Can you explain status of this mechanism w/in each of these 
groups (on referenced drafts)? What is approved, required, etc. We 
need to see something from those chairs that the ref'ed drafts are 
"blessed."

Scott:  Walked through

Gargi: We have chicken and egg to get this done. Encoding first or 
formats first?

Intro work on L3VPN list.

Rekhter: Very reasonable model where must have both WGs review dependent docs.

Bill Fenner:  Must work w/ other WG for encoding.

Rekhter: Two possible models - first: semantics or encoding need to 
be done in L3VPN
    second: L2/L3VPN WGs tell us semantics and IDR produces codepoints

Rahul:  C/E problem wasn't problem in the past but, applicability. 
Applicability has been cleared up. Now that motivations are clear, 
the multiple proposal should be conjoined. Do work wherever ADs state

Roque: Disagree w/ motivations. IGP can provide reachability. I think 
you use BGP as signaling protocol which is not a problem. But, 
presentation states that BGP needs to know this information. Please 
clarify the layering split.

Rekhter: Can this move to L3VPN

SOLUTION: Joint Last Call in IDR and L3VPN.

-------------------------
SAFI Space Partition
In reply to Jeff Hass email on list.

Fenner to send notes on how to alloc SAFI space.

Proposal: take private use space and turn it into reserved and 
perhaps 16 or so as private use. Reserved is reserved so we can 
decide later on FCFS or otherwise managed.

Are folks using private space? Do we need to skip some?

Rekhter: How long will it take to use up first come first served?

Fenner: We should be able to straighten this out quickly and IANA is 
keeping up. 30 days deadline.

Danny McPherson: Needs to be uniform across all WGs and Areas. Make 
it IETF aligned.

Roque: I do not want to see vendor specific space go away altogether. 
There is much more usage than one case alluded to. Today is only 
practical alternative, cannot be locked out. Can it be shown to work 
before we assume 30 days?

Fenner: There are publications on these agreements and promises that 
it will be done in 30 days. FCFS is you get it now .... no draft, no 
wait.

Chandra; Cannot get rid of vendor space.  AF/SAFI has lost meaning and 
is a way to differentiate addrs between two peers. Just need opaque 
space that we can use between two peers.

Gargi: Must have vendor space perhaps reduced is ok. Second, IANA is 
faster but, it seems to required Routing ADs having lunch w/ IANA.

Rekhter: IANA must have strict 30 days max as rule.

Fenner: We are working on this and the stats show that 30 days is being met.

From: "john smith" <[email-masked]>
To: [email-masked]
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
Date: Mon, 08 Aug 2005 14:47:54 +0000
Sender: [email-masked]

any vendor has a hook into microsoft outlook calender with BGP? ;-)

>From: "john smith" <[email-masked]>
>To: [email-masked], [email-masked]
>Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
>Date: Mon, 08 Aug 2005 14:33:01 +0000
>
>Hi,
>
>What about "his" customers? His SLAs may be more stringent than your 
>SLAs...
>
>I would agree with Howard in a way, GROW would be a nice place to bring 
>this up.
>As far as i know most people rely on exchanging information a few hours 
>prior to a restart.
>
>>From: "DECRAENE Bruno RD-CORE-ISS" <[email-masked]>
>>To: "john smith" <[email-masked]>,<[email-masked]>
>>Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
>>Date: Mon, 8 Aug 2005 16:14:10 +0200
>>
>> > ....Well but if they are heavy traffic bearing links it would
>> > be better to inform your peers a few hours in advance so that
>> > he can rewrite his policies.. it is also his $$ after all :-)
>>
>>If it's my customer (Internet or VPN) this is my $$ if I broke the SLA.
>>In a BGP/MPLS VPN situation, if I manage the CE, it's my time/money to
>>rewrite it's policy.
>>
>>
>> > >Hi John,
>> > >
>> > > > Hi,
>> > > >
>> > > > I think if *we know* that a bomb is going to fall on our town at
>> > > > X'oclock, we warn everyone to leave town beforehand....
>> > > > and not wait till the last minute and send out a message?
>> > >
>> > >That's exactly our point.
>> > >We know the forwarding will be shutdown. Why wait the last second to
>> > >send a BGP CEASE? Why not inform all your BGP peers a few
>> > >seconds/minutes before? In a way that would allow minimal
>> > packet loss
>> > >during BGP convergence.
>> > >
>> > >
>> > > > So generally most operators simply send out an "email" to the
>> > > > peering NOCs.
>> > > > Practical..no?
>> > >
>> > >Warning the peer is one thing. Shuting down the session with minimal
>> > >pack loss is still desirable.
>> > >
>> > >In some situation, we don't care about loosing some trafic
>> > or both NOC
>> > >we'll write some route map/policy to gracefully reroute the
>> > packets (or
>> > >believe so).
>> > >
>> > >In some other situation, customers do cares about their SLA, and
>> > >modifying the route map each time is too error prone and time/money
>> > >consuming.
>> >
>> > _________________________________________________________________
>> > Express yourself instantly with MSN Messenger! Download today
>> > it's FREE!
>> > http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
>> >
>> >
>
>_________________________________________________________________
>Don't just search. Find. Check out the new MSN Search! 
>http://search.msn.click-url.com/go/onm00200636ave/direct/01/
>
>

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Date: Mon, 8 Aug 2005 15:45:19 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: DECRAENE Bruno RD-CORE-ISS <[email-masked]>
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
Mail-Copies-To: [email-masked]
Mail-Followup-To: [email-masked]
Cc: [email-masked], FONDEVIOLE Benoit RD-CORE-ISS <[email-masked]>, DUBOIS Nicolas ROSI-DAS-ARI <[email-masked]>
Sender: [email-masked]

On Mon, 8 Aug 2005, DECRAENE Bruno RD-CORE-ISS wrote:

> If you *know* the forwarding plane will be shutdown, will not 
> advertising this /before/ the failure?

I'm not terribly familiar with GR - I dont know. I don't /see/ how GR 
allows signalling intent of forwarding state in advance of the 
shutdown, but I could be wrong. You should ask the GR author.

At a guess, there's very little to be gained (in the context of GR 
solely). Signalling a fact (I /did/ keep my forwarding state up) is 
probably better than an intent (I /intend/ to keep my forwarding 
state up).

However, in the context of both GR and a "notify + wait a while" 
optimisation, it might indeed be an idea to consider this, and 
possibly modify GR. Ie to be able to signal intent to take down 
forwarding (an intention easier to satisfy than keeping forwarding 
up).

/Maybe/ this could be satisfied with additional NOTIFY CEASE 
sub-codes? Eg, ADMIN_RESTART (complete restart) and ADMIN_RESTART_BGP 
(restarting only BGP, intend to leave FIB in place). Seems hacky to 
use subcodes for anything other than informational purposes, but 
that's only way really.

> You could:
> -1- warn your peers about the planned maintenance
> -2- keeps FIB & forwarding while BGP convergence
> -3- shut the BGP session as usual.

Yep.

> We hope that a least a significant part of the requirements could be
> fullfilled without protocol extension.

That seems likely.

So the main issue, it seems, is that interaction with GR needs to be 
considered. Which may require interacting additionally with the 
draft-ietf-idr-cease-subcode authors.

> It could work in some situation but if your peers doesn't know 
> about the back up path (because of a RR on the path) you will lose 
> traffic.

That would seem to be a route-reflector issue, best addressed 
seperately?

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
The generation of random numbers is too important to be left to chance.

Content-class: urn:content-classes:message
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc 
Date: Mon, 8 Aug 2005 16:41:56 +0200
From: "DECRAENE Bruno RD-CORE-ISS" <[email-masked]>
To: <[email-masked]>, "DUBOIS Nicolas ROSI-DAS-ARI" <[email-masked]>
Cc: [email-masked], FONDEVIOLE Benoit RD-CORE-ISS <[email-masked]>
Sender: [email-masked]

Hi Curtis,

Thanks for your feedback. 
Some comments inlined

> >  
> > Curtis,
> >  
> > Thanks for reading the draft, some comments:
> >  
> > If you've got a 2.5 gig line card and want to upgrade it to 
> a 10 or 40 
> > gig line card, I still think you need to shut down the BGP session 
> > that is running on it and in order to replace the card.
> 
> Only if its an EBGP session.  If its IBGP you don't need to 
> take down anything to replace a card unless your network has 
> no internal redundancy.

OK
 
> For the EBGP session we already have BGP Gracefull Restart 
> but that doesn't cover upgrading if you are going to pull the 
> old card.

OK. 
The draft cover the case when the forwarding cannont be preserved, so
Gracefull Restart cannot be used.
 
> The forwarding that is kept in place during gracefull restart 
> won't be in place while neither card is in the slot.  Are you 
> suggesting that the BGP session should stay up and maintain a 
> black hole while the cards are swapped? 

No. We are suggesting to advertise the planned failure before the
forwarding is shut down. In such a way that no or minimal traffic is
lost.

> I hope not and 
> that's not what I read.
> 
> In this particular example, both providers would bring up the 
> 40 Gig and then bring down the 10 Gig.  Of course since a lot 
> of 40 Gig interfaces are really concatonated 10 Gigs (4 x 
> OC192), in this example they'd add 3 10 gigs with no 
> disruption at all.  Either way no bits are lost if for a time 
> there are two peerings before the old one is shut down.
> Of course if you are out of card slots there are some routers 
> that let you expand the backplane without disruption.  Not 
> all routers do that.

For sure.
Not all routers are even capable of keeping forwarding up during a
control plane switch over...
 
> > Of course you can do it gracefully with some route-map tricks, ...
But 
> > on large operationnal routers it can be quite complex, and it would
be 
> > better to have it automatic and directly embedded in the router
software.
> 
> Sorry.  I used to maintain a tier-1 network and I can't see 
> why it would be so difficult to change policy to not 
> advertise the EBGP into IBGP, then not accept the EBGP, then 
> shut down the EBGP.  Yes, I know that today's NOC staff are 
> not what they used to be but many of our NOC staff were 
> college students who didn't know what BGP was until their on 
> the jub training.  It seems that this would be your best solution.

I don't see the point of doing it manually each time when it can be
automated if we agree on a way to do it and have it implemented.
 
> In the old days some bright operations engineer might write a 
> perl program which given a peering line could write the 
> policy to disable the EBGP to IBGP, then disable the EBGP, 
> then take down the peering.
> The operator could then paste that into the router config.  
> It sounds like what you are asking for is a way for the 
> router to shut down the peering in a similar order but do so 
> automaticly.

Yes.
We're asking for a way to do it with minimal packet loss in all typical
situations. I'm not sure this is that obvious. If you belive it is,
could you please send an URL with the procedure?
And to have it down automaticly by the router itself.

> > BTW, graceful restart is really efficient when all (all !) peers are

> > supporting it.If some of the peer are not supporting it, I wouldn't 
> > say it's harmful but ... You never know. I do not know many service 
> > providers who can successfully use it on a large ASBRs 
> currently. In  our case many of our customers and peers do not support
GR even in 
> > helper only mode. So GR is still a "for future use" feature to me.
> 
> The document that you are asking to be considered looks to be 
> just a requirements document.

It is.
It does'nt seems so easy to first agree on the requirement.
 
> What you might be better off advocating is that more routers 
> implement BGP gracefull restart and more or your peers enable 
> it.  In the example you just gave gracefull restart doesn't 
> help.  Given the draft and then the example above, its not 
> clear what problem you are trying to address and what 
> solution you have in mind.  Is it time for me to reread the draft?
> 
> > > If you are taking a router completely out of service you 
> can cost it 
> > > out of the IGP first then take down the EBGP peerings, 
> then shut it 
> > > down.
> >  
> > This is not going to work in all situations.
> 
> Yes but your document adds nothing to improve it.

We raise the issue, which is a first step.

> > Best regards
> > Nicolas Dubois
> > Tel :  0144442817	

Regards,
Bruno

From: "john smith" <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
Date: Mon, 08 Aug 2005 14:33:01 +0000
Cc: 
Sender: [email-masked]

Hi,

What about "his" customers? His SLAs may be more stringent than your SLAs...

I would agree with Howard in a way, GROW would be a nice place to bring this 
up.
As far as i know most people rely on exchanging information a few hours 
prior to a restart.

>From: "DECRAENE Bruno RD-CORE-ISS" <[email-masked]>
>To: "john smith" <[email-masked]>,<[email-masked]>
>Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
>Date: Mon, 8 Aug 2005 16:14:10 +0200
>
> > ....Well but if they are heavy traffic bearing links it would
> > be better to inform your peers a few hours in advance so that
> > he can rewrite his policies.. it is also his $$ after all :-)
>
>If it's my customer (Internet or VPN) this is my $$ if I broke the SLA.
>In a BGP/MPLS VPN situation, if I manage the CE, it's my time/money to
>rewrite it's policy.
>
>
> > >Hi John,
> > >
> > > > Hi,
> > > >
> > > > I think if *we know* that a bomb is going to fall on our town at
> > > > X'oclock, we warn everyone to leave town beforehand....
> > > > and not wait till the last minute and send out a message?
> > >
> > >That's exactly our point.
> > >We know the forwarding will be shutdown. Why wait the last second to
> > >send a BGP CEASE? Why not inform all your BGP peers a few
> > >seconds/minutes before? In a way that would allow minimal
> > packet loss
> > >during BGP convergence.
> > >
> > >
> > > > So generally most operators simply send out an "email" to the
> > > > peering NOCs.
> > > > Practical..no?
> > >
> > >Warning the peer is one thing. Shuting down the session with minimal
> > >pack loss is still desirable.
> > >
> > >In some situation, we don't care about loosing some trafic
> > or both NOC
> > >we'll write some route map/policy to gracefully reroute the
> > packets (or
> > >believe so).
> > >
> > >In some other situation, customers do cares about their SLA, and
> > >modifying the route map each time is too error prone and time/money
> > >consuming.
> >
> > _________________________________________________________________
> > Express yourself instantly with MSN Messenger! Download today
> > it's FREE!
> > http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
> >
> >

_________________________________________________________________
Don't just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/

To: Paul Jakma <[email-masked]>
Subject: Re: [Idr] IANA assigned bgp-params mixup 
Date: Mon, 08 Aug 2005 07:26:14 -0700
From: Yakov Rekhter <[email-masked]>
Cc: Inter-Domain Routing List <[email-masked]>
Sender: [email-masked]

Paul,

> Is it my imagination or does:
> 
>  	http://www.iana.org/assignments/bgp-parameters
> 
> have the KEEPALIVE and NOTIFICATION message types the wrong way 
> around?

No, it is not your imagination - it is due to my mistake, as 
in the IANA consideration section of the spec I made a mistake. I am going
to contact IANA to fix this.

Many thanks for pointing this out.

Yakov.

Content-class: urn:content-classes:message
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
Date: Mon, 8 Aug 2005 16:14:10 +0200
From: "DECRAENE Bruno RD-CORE-ISS" <[email-masked]>
To: "john smith" <[email-masked]>, <[email-masked]>
Cc: 
Sender: [email-masked]

> ....Well but if they are heavy traffic bearing links it would 
> be better to inform your peers a few hours in advance so that 
> he can rewrite his policies.. it is also his $$ after all :-)

If it's my customer (Internet or VPN) this is my $$ if I broke the SLA.
In a BGP/MPLS VPN situation, if I manage the CE, it's my time/money to
rewrite it's policy.

> >Hi John,
> >
> > > Hi,
> > >
> > > I think if *we know* that a bomb is going to fall on our town at 
> > > X'oclock, we warn everyone to leave town beforehand....
> > > and not wait till the last minute and send out a message?
> >
> >That's exactly our point.
> >We know the forwarding will be shutdown. Why wait the last second to 
> >send a BGP CEASE? Why not inform all your BGP peers a few 
> >seconds/minutes before? In a way that would allow minimal 
> packet loss 
> >during BGP convergence.
> >
> >
> > > So generally most operators simply send out an "email" to the 
> > > peering NOCs.
> > > Practical..no?
> >
> >Warning the peer is one thing. Shuting down the session with minimal 
> >pack loss is still desirable.
> >
> >In some situation, we don't care about loosing some trafic 
> or both NOC 
> >we'll write some route map/policy to gracefully reroute the 
> packets (or 
> >believe so).
> >
> >In some other situation, customers do cares about their SLA, and 
> >modifying the route map each time is too error prone and time/money 
> >consuming.
> 
> _________________________________________________________________
> Express yourself instantly with MSN Messenger! Download today 
> it's FREE! 
> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
> 
> 

Content-class: urn:content-classes:message
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
Date: Mon, 8 Aug 2005 16:09:29 +0200
From: "DECRAENE Bruno RD-CORE-ISS" <[email-masked]>
To: "Paul Jakma" <[email-masked]>, "DUBOIS Nicolas ROSI-DAS-ARI" <[email-masked]>
Cc: [email-masked], FONDEVIOLE Benoit RD-CORE-ISS <[email-masked]>
Sender: [email-masked]

> > Basically GR restart is:
> > 	Forwarding plane stays up / control plane says I'll be back.
> 
> Right. Though note that GR specifies a forwarding-state bit, 
> so you can signal to your peer, /after/ the fact (when you 
> bring your session back up), whether or not your forwarding 
> plane stayed up.

If you *know* the forwarding plane will be shutdown, will not
advertising this /before/ the failure?
 
> > Planned maintenance requirement is:
> 
> > 	Forwarding going away, control plane going away / let's do it
> >	gracefully.
> 
> Ok, I guess my question then is what you think can be done 
> for this case, eg /lack/ of graceful-restart capability.

You could:
-1- warn your peers about the planned maintenance
-2- keeps FIB & forwarding while BGP convergence
-3- shut the BGP session as usual.

> Further, as above, how can you even reliably distinguish 
> between the two cases above (presuming GR is enabled)?

This is a maintenance situation and the operator knows that the
forwarding plane needs to be shutdown.

> Given 
> the GR draft, you can't determine anything until the peer 
> comes back. Ie, given GR, there is a window of uncertainty 
> where you can not say whether forwarding stayed up or not, 
> you only know when it comes back and you can examine the F 
> bit in the GR capability advertisement for the appropriate AFI/SAFI.
> 
> Something to consider anyway (the interaction of the two).
> 
> A final thought: Does the second case even require any protocol work?

We hope that a least a significant part of the requirements could be
fullfilled without protocol extension.
 
> It strikes me that the second case can easily be handled 
> entirely within the confines of existing specified BGP, by 
> simply having an implementation take the relevant BGP 
> session(s) down (ie sending a
> CEASE) and just waiting a while to let the relevant remote 
> peers update their routes, before proceeding with actually 
> removing the routes from RIB and FIB and then restarting.

It could work in some situation but if your peers doesn't know about the
back up path (because of a RR on the path) you will lose traffic.
 
> I reckon the most protocol work this needs is just to have 
> implementations advertise a "I reckon I need X milliseconds 
> to clear Y number of routes" or even just "Hey, if you're 
> going down, try give me X seconds advance notice if you can" 
> capability, which could be used to supercede any 
> implementation specific default.
> 
> > Best regards,
> >
> > Nicolas Dubois
> > Tel :  0144442817
> 
> regards,
> -- 
> Finagle's Seventh Law:
>  	The perversity of the universe tends toward a maximum.
> 

From: "john smith" <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
Date: Mon, 08 Aug 2005 13:58:20 +0000
Cc: 
Sender: [email-masked]

....Well but if they are heavy traffic bearing links it would be better to 
inform your peers a few hours in advance so that he can rewrite his 
policies.. it is also his $$ after all :-)

>From: "DECRAENE Bruno RD-CORE-ISS" <[email-masked]>
>To: "john smith" <[email-masked]>,<[email-masked]>
>Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
>Date: Mon, 8 Aug 2005 15:12:35 +0200
>
>Hi John,
>
> > Hi,
> >
> > I think if *we know* that a bomb is going to fall on our town
> > at X'oclock, we warn everyone to leave town beforehand....
> > and not wait till the last minute and send out a message?
>
>That's exactly our point.
>We know the forwarding will be shutdown. Why wait the last second to
>send a BGP CEASE? Why not inform all your BGP peers a few
>seconds/minutes before? In a way that would allow minimal packet loss
>during BGP convergence.
>
>
> > So generally most operators simply send out an "email" to the
> > peering NOCs.
> > Practical..no?
>
>Warning the peer is one thing. Shuting down the session with minimal
>pack loss is still desirable.
>
>In some situation, we don't care about loosing some trafic or both NOC
>we'll write some route map/policy to gracefully reroute the packets (or
>believe so).
>
>In some other situation, customers do cares about their SLA, and
>modifying the route map each time is too error prone and time/money
>consuming.

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Date: Mon, 8 Aug 2005 09:13:31 -0400
To: [email-masked]
From: "Howard C. Berkowitz" <[email-masked]>
Subject: Re: [idr] BGP planned maintenance requirements as an IDR WG doc
Sender: [email-masked]

Assume, for a moment, that there is a legitimate need for knowing 
when planned maintenance is scheduled. If that is the case, however, 
it would seem that it is as important to know when other critical 
resources will be out of service, ranging from an optical multiplexer 
that handles the physical layer for several BGP speakers, to security 
devices that ensure link level or firewall-to-firewall encryption 
between two ISPs.

The first will clearly affect routing, but would it be handled 
adequately with a BGP Maintenance Planned message for each affected 
router, without a message identifying the common resource? As more 
and more root cause analysis goes into network management systems, 
would it be even more useful to know the multiplexer is going down, 
to know the systems dependent on it, and, when the link goes down, 
suppress the consequential router alarms from the NMS? Again, 
assuming knowledge of related entities, the BGP speakers could 
receive a local signal that a resource on which they depend is going 
down, and to begin graceful shutdown N minutes before the scheduled 
maintenance?

In other words, if this is a good idea for BGP, it would seem a good 
idea for other critical components. The question might be split: is 
the requirement useful, and, if so, what should be the transport 
mechanism for the messages? Given the tendency to overload BGP into a 
generalized signaling method, perhaps the focus in IDR should be on 
the transport and the subset of BGP informational messages.

My sense is that the overall problem is more for the Operations than 
Routing area, and that alternate transport mechanisms should be 
examined. It may well be that the messages should be carried in BGP, 
as the de facto one known intercarrier signaling mechanism, but 
perhaps the BGP implementation should be closer to the OSPF Opaque 
LSA.  Certain messages carried in that manner could be locally 
significant in starting graceful shutdown, or a different operational 
procedure that assumes the forwarding path won't be back in the near 
term.

Date: Mon, 8 Aug 2005 14:09:23 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: DECRAENE Bruno RD-CORE-ISS <[email-masked]>
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
Mail-Copies-To: [email-masked]
Mail-Followup-To: [email-masked]
Cc: [email-masked], [email-masked], FONDEVIOLE Benoit RD-CORE-ISS <[email-masked]>, DUBOIS Nicolas ROSI-DAS-ARI <[email-masked]>
Sender: [email-masked]

On Mon, 8 Aug 2005, DECRAENE Bruno RD-CORE-ISS wrote:

> - If you have RRs, iBGP routers (including your RR) may not have 
> the backup path. The RR will propagate the withdraw and the 
> destination will be removed from the RIB.

So you'd need some kind of full-reflection extension to BGP...

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
They're giving bank robbing a bad name.
 		-- John Dillinger, on Bonnie and Clyde

Content-class: urn:content-classes:message
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
Date: Mon, 8 Aug 2005 15:12:35 +0200
From: "DECRAENE Bruno RD-CORE-ISS" <[email-masked]>
To: "john smith" <[email-masked]>, <[email-masked]>
Cc: 
Sender: [email-masked]

Hi John,

> Hi,
> 
> I think if *we know* that a bomb is going to fall on our town 
> at X'oclock, we warn everyone to leave town beforehand.... 
> and not wait till the last minute and send out a message?

That's exactly our point.
We know the forwarding will be shutdown. Why wait the last second to
send a BGP CEASE? Why not inform all your BGP peers a few
seconds/minutes before? In a way that would allow minimal packet loss
during BGP convergence.

> So generally most operators simply send out an "email" to the 
> peering NOCs.
> Practical..no?

Warning the peer is one thing. Shuting down the session with minimal
pack loss is still desirable.

In some situation, we don't care about loosing some trafic or both NOC
we'll write some route map/policy to gracefully reroute the packets (or
believe so).

In some other situation, customers do cares about their SLA, and
modifying the route map each time is too error prone and time/money
consuming.

Content-class: urn:content-classes:message
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
Date: Mon, 8 Aug 2005 14:33:54 +0200
From: "DECRAENE Bruno RD-CORE-ISS" <[email-masked]>
To: <[email-masked]>, "DUBOIS Nicolas ROSI-DAS-ARI" <[email-masked]>
Cc: [email-masked], FONDEVIOLE Benoit RD-CORE-ISS <[email-masked]>, Paul Jakma <[email-masked]>
Sender: [email-masked]

> > A final thought: Does the second case even require any protocol
work?
> > 
> > It strikes me that the second case can easily be handled entirely 
> > within the confines of existing specified BGP, by simply having an 
> > implementation take the relevant BGP session(s) down (ie sending a
> > CEASE) and just waiting a while to let the relevant remote peers 
> > update their routes, before proceeding with actually removing the 
> > routes from RIB and FIB and then restarting.
> > 
> > I reckon the most protocol work this needs is just to have 
> > implementations advertise a "I reckon I need X milliseconds to clear
Y 
> > number of routes" or even just "Hey, if you're going down, try give
me 
> > X seconds advance notice if you can" capability, which could be used

> > to supercede any implementation specific default.
> 
> As this mail is the closest to my line of understanding this 
> problem let me ask a very basic question of course assuming 
> that GR is for "the future" ...
> 
> Would it not be enough to simply withdraw the advertised 
> routes before bringing the session down towards given peer ? 
> If operator enters shutdown on BGP session this should not 
> trigger any immediate BGP/TCP action .. instead one could 
> send MP_UNREACH then at some decent timeout actually bring 
> the sessions down.

It's indeed a possible solution. In fact it's exactly what we proposed
in "draft-dubois-bgp-planned-maintenance-00.txt" in San Diego.
Unfortunately, it's not working for all the iBGP topologies:
- If you have a full iBGP mesh, all your peers already know the backup
path and will select it. So this will work fine.
- If you have RRs, iBGP routers (including your RR) may not have the
backup path. The RR will propagate the withdraw and the destination will
be removed from the RIB. 

> No protocol changes required.

There's lot of possible ways to improve the current eBGP shutdowns.
Could we possibly agree on a solution?
We would all prefer that this solution does require any protocol change.
In that case, a BCP could document the solution.

Then, each ISP could use that solution for each maintenance. Or
preferably, vendors will automate the solution.

> All it would take is a local implementation little twick ;).

That would be fine for me.

Cheers,
Bruno

> R.

Date: Mon, 8 Aug 2005 02:24:12 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Inter-Domain Routing List <[email-masked]>
Mail-Copies-To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [Idr] IANA assigned bgp-params mixup
Sender: [email-masked]

Is it my imagination or does:

 	http://www.iana.org/assignments/bgp-parameters

have the KEEPALIVE and NOTIFICATION message types the wrong way 
around?

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Practically perfect people never permit sentiment to muddle their thinking.
 		-- Mary Poppins

To: "DUBOIS Nicolas ROSI/DAS/ARI" <[email-masked]>
Subject: Re: [idr] BGP planned maintenance requirements as an IDR WG doc 
Date: Sun, 07 Aug 2005 18:12:46 -0400
From: Curtis Villamizar <[email-masked]>
Cc: DECRAENE Bruno RD-CORE <[email-masked]>, [email-masked], FONDEVIOLE Benoit RD-CORE <[email-masked]>
Reply-To: [email-masked]
Sender: [email-masked]

In message <[email-masked]>
"DUBOIS Nicolas ROSI/DAS/ARI" writes:
>  
> Curtis,
>  
> Thanks for reading the draft, some comments:
>  
> If you've got a 2.5 gig line card and want to upgrade it to a 10 or 40 gig
> line card, I still think you need to shut down the BGP session that is
> running on it and in order to replace the card.

Only if its an EBGP session.  If its IBGP you don't need to take down
anything to replace a card unless your network has no internal
redundancy.

For the EBGP session we already have BGP Gracefull Restart but that
doesn't cover upgrading if you are going to pull the old card.

The forwarding that is kept in place during gracefull restart won't be
in place while neither card is in the slot.  Are you suggesting that
the BGP session should stay up and maintain a black hole while the
cards are swapped?  I hope not and that's not what I read.

In this particular example, both providers would bring up the 40 Gig
and then bring down the 10 Gig.  Of course since a lot of 40 Gig
interfaces are really concatonated 10 Gigs (4 x OC192), in this
example they'd add 3 10 gigs with no disruption at all.  Either way no
bits are lost if for a time there are two peerings before the old one
is shut down.

Of course if you are out of card slots there are some routers that let
you expand the backplane without disruption.  Not all routers do that.

> Of course you can do it gracefully with some route-map tricks, ... But on
> large operationnal routers it can be quite complex, and it would be better
> to have it automatic and directly embedded in the router software.

Sorry.  I used to maintain a tier-1 network and I can't see why it
would be so difficult to change policy to not advertise the EBGP into
IBGP, then not accept the EBGP, then shut down the EBGP.  Yes, I know
that today's NOC staff are not what they used to be but many of our
NOC staff were college students who didn't know what BGP was until
their on the jub training.  It seems that this would be your best
solution.

In the old days some bright operations engineer might write a perl
program which given a peering line could write the policy to disable
the EBGP to IBGP, then disable the EBGP, then take down the peering.
The operator could then paste that into the router config.  It sounds
like what you are asking for is a way for the router to shut down the
peering in a similar order but do so automaticly.

> BTW, graceful restart is really efficient when all (all !) peers are
> supporting it.If some of the peer are not supporting it, I wouldn't say it's
> harmful but ... You never know. I do not know many service providers who can
> successfully use it on a large ASBRs currently. In our case many of our
> customers and peers do not support GR even in helper only mode. So GR is
> still a "for future use" feature to me.

The document that you are asking to be considered looks to be just a
requirements document.

What you might be better off advocating is that more routers implement
BGP gracefull restart and more or your peers enable it.  In the
example you just gave gracefull restart doesn't help.  Given the draft
and then the example above, its not clear what problem you are trying
to address and what solution you have in mind.  Is it time for me to
reread the draft?

> > If you are taking a router completely out of service you can cost it
> > out of the IGP first then take down the EBGP peerings, then shut it
> > down. 
>  
> This is not going to work in all situations.

Yes but your document adds nothing to improve it.

> Best regards 
> Nicolas Dubois
> Tel :  0144442817	

Regards,

Curtis

Date: Sun, 7 Aug 2005 21:53:40 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Robert Raszuk <[email-masked]>
Subject: Re: [idr] BGP planned maintenance requirements as an IDR WG doc
Mail-Copies-To: [email-masked]
Mail-Followup-To: [email-masked]
Cc: DECRAENE Bruno RD-CORE <[email-masked]>, [email-masked], FONDEVIOLE Benoit RD-CORE <[email-masked]>, DUBOIS Nicolas ROSI/DAS/ARI <[email-masked]>
Sender: [email-masked]

On Sun, 7 Aug 2005, Robert Raszuk wrote:

[you forgot to attribute text of mine which you quoted]

>> It strikes me that the second case can easily be handled entirely within 
>> the confines of existing specified BGP, by simply having an implementation 
>> take the relevant BGP session(s) down (ie sending a CEASE) and just waiting 
>> a while to let the relevant remote peers update their routes, before 
>> proceeding with actually removing the routes from RIB and FIB and then 
>> restarting.

> Would it not be enough to simply withdraw the advertised routes 
> before bringing the session down towards given peer ?

See above, shutting the session down implies the remote side should 
withdraw (if GR is /not/ involved). No need to send 160k+ withdraws.

What matters, AFAICT, is that you keep your forwarding in place for 
as long as it takes to allow the remote peers concerned to complete 
withdrawal of your routes. No?

> No protocol changes required. All it would take is a local 
> implementation little twick ;).

Indeed.

It could be made better though. The ultimate would be some kind of 
callback mechanism:

(router shutting down)		(remote peer)
Rzzz's     			Rb
----------------------------------------------
Notify/intend-shutdown	---->
 			       <updates its RIB and FIB>
 		        <---   Notify/shutdown-go-ahead

Course, NOTIFY is an error condition, and 1771 states:

 	"The BGP connection is closed immediately after sending it."

Which presents a problem. BGP would need a non-error notification 
method to do the above.

A "If you shutdown, try send me the NOTIFY Xs in advance, please" 
OPEN capability would be easier/quicker to do, and would at least 
remove need for an implementation to simply guess how long /other/ 
implementations might need.

Anyone reckon that'd be something to write-up? :) (would be vaguely 
complementary to the "Estimated Restart Time" field in the Graceful 
Capability).

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
fortune: cannot execute.  Out of cookies.

Date: Sun, 07 Aug 2005 13:01:39 -0700
From: Robert Raszuk <[email-masked]>
Organization: Signature: http://www.employees.org/~raszuk/sig/
To: DUBOIS Nicolas ROSI/DAS/ARI <[email-masked]>
Subject: Re: [idr] BGP planned maintenance requirements as an IDR WG doc
Cc: DECRAENE Bruno RD-CORE <[email-masked]>, [email-masked], FONDEVIOLE Benoit RD-CORE <[email-masked]>, Paul Jakma <[email-masked]>
Reply-To: [email-masked]
Sender: [email-masked]

> A final thought: Does the second case even require any protocol work?
> 
> It strikes me that the second case can easily be handled entirely within 
> the confines of existing specified BGP, by simply having an 
> implementation take the relevant BGP session(s) down (ie sending a 
> CEASE) and just waiting a while to let the relevant remote peers update 
> their routes, before proceeding with actually removing the routes from 
> RIB and FIB and then restarting.
> 
> I reckon the most protocol work this needs is just to have 
> implementations advertise a "I reckon I need X milliseconds to clear Y 
> number of routes" or even just "Hey, if you're going down, try give me X 
> seconds advance notice if you can" capability, which could be used to 
> supercede any implementation specific default.

As this mail is the closest to my line of understanding this problem let 
me ask a very basic question of course assuming that GR is for "the 
future" ...

Would it not be enough to simply withdraw the advertised routes before 
bringing the session down towards given peer ? If operator enters 
shutdown on BGP session this should not trigger any immediate BGP/TCP 
action .. instead one could send MP_UNREACH then at some decent timeout 
actually bring the sessions down.

No protocol changes required. All it would take is a local 
implementation little twick ;).

Cheers,
R.

From: "john smith" <[email-masked]>
To: [email-masked]
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
Date: Sun, 07 Aug 2005 14:22:57 +0000
Sender: [email-masked]

Hi,

I think if *we know* that a bomb is going to fall on our town at X'oclock, 
we warn everyone to leave town beforehand.... and not wait till the last 
minute and send out a message?

So generally most operators simply send out an "email" to the peering NOCs.
Practical..no?

-JS

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Date: Sun, 7 Aug 2005 15:04:19 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: DUBOIS Nicolas ROSI/DAS/ARI <[email-masked]>
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
Mail-Copies-To: [email-masked]
Mail-Followup-To: [email-masked]
Cc: DECRAENE Bruno RD-CORE <[email-masked]>, [email-masked], FONDEVIOLE Benoit RD-CORE <[email-masked]>
Sender: [email-masked]

Hi Nicholas,

On Sun, 7 Aug 2005, DUBOIS Nicolas ROSI/DAS/ARI wrote:

> Basically GR restart is:
> 	Forwarding plane stays up / control plane says I'll be back.

Right. Though note that GR specifies a forwarding-state bit, so you 
can signal to your peer, /after/ the fact (when you bring your 
session back up), whether or not your forwarding plane stayed up.

> Planned maintenance requirement is:

> 	Forwarding going away, control plane going away / let's do it
>	gracefully.

Ok, I guess my question then is what you think can be done for this 
case, eg /lack/ of graceful-restart capability.

Further, as above, how can you even reliably distinguish between the 
two cases above (presuming GR is enabled)? Given the GR draft, you 
can't determine anything until the peer comes back. Ie, given GR, 
there is a window of uncertainty where you can not say whether 
forwarding stayed up or not, you only know when it comes back and you 
can examine the F bit in the GR capability advertisement for the 
appropriate AFI/SAFI.

Something to consider anyway (the interaction of the two).

A final thought: Does the second case even require any protocol work?

It strikes me that the second case can easily be handled entirely 
within the confines of existing specified BGP, by simply having an 
implementation take the relevant BGP session(s) down (ie sending a 
CEASE) and just waiting a while to let the relevant remote peers 
update their routes, before proceeding with actually removing the 
routes from RIB and FIB and then restarting.

I reckon the most protocol work this needs is just to have 
implementations advertise a "I reckon I need X milliseconds to clear 
Y number of routes" or even just "Hey, if you're going down, try give 
me X seconds advance notice if you can" capability, which could be 
used to supercede any implementation specific default.

> Best regards,
> Nicolas Dubois
> Tel :  0144442817

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Finagle's Seventh Law:
 	The perversity of the universe tends toward a maximum.

From: "DUBOIS Nicolas ROSI/DAS/ARI" <[email-masked]>
To: "'John Leslie'" <[email-masked]>, "'Curtis Villamizar'" <[email-masked]>
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
Date: Sun, 7 Aug 2005 14:19:13 +0200
Cc: [email-masked]
Sender: [email-masked]

Hi John,

Thanks for reading the draft,

>> but my problem with it is that it fails to propose adequate algorithms
for graceful shutdown.

I think it is better to first agree that there is a need for a graceful
shutdown and then discuss of the acceptable solutions. Depending on the
scope of this graceful shutdown, there are many acceptable solutions.

I think a requirement should not explain the problem and the solution at the
same time.

>    It would be good to have a mechanism for deprecating 
> routes a bit more gracefully than prepending in hopes that 
> some other route will be preferred; and it would be good to 
> have some mechanism to ensure that the propagation of 
> deprecating routes never causes packets to be dropped for 
> lack of an immediately-available alternate route.
> 

I agree with that and it is the idea we would like to push with the draft.

Best regards,

Nicolas Dubois
Tel :  0144442817	

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la 
> part de John Leslie
> Envoyé : samedi 6 août 2005 00:13
> À : Curtis Villamizar
> Cc : [email-masked]; DUBOIS Nicolas ROSI/DAS/ARI
> Objet : Re: [idr] BGP planned maintenance requirements as an 
> IDR WG doc
> 
> Curtis Villamizar <[email-masked]> wrote:
> > In message <[email-masked]>
> > "DUBOIS Nicolas ROSI/DAS/ARI" writes:
> >>  
> >> Following IETF 63, I'd like to suggest that BGP planned 
> maintenance 
> >> requirements (draft-dubois-bgp-pm-reqs-02.txt) be considered as an 
> >> IDR working group document.
> > 
> > What's the point?  There is BGP gracefull restart and there are 
> > routers with warm standby route servers that can do things like 
> > software upgrades without impacting service.  All line cards these 
> > days are hot pluggable.
> 
>    I cannot support this I-D as a Working Group document 
> either; but my problem with it is that it fails to propose 
> adequate algorithms for graceful shutdown. (There are 
> occasions where power is failing and shutdown will be 
> necessary: if we were to adopt it, we should at least change 
> the title.)
> 
>    It would be good to have a mechanism for deprecating 
> routes a bit more gracefully than prepending in hopes that 
> some other route will be preferred; and it would be good to 
> have some mechanism to ensure that the propagation of 
> deprecating routes never causes packets to be dropped for 
> lack of an immediately-available alternate route.
> 
>    But I do not see that in this draft.
> 
> --
> John Leslie <[email-masked]>
> 

From: "DUBOIS Nicolas ROSI/DAS/ARI" <[email-masked]>
To: "'Paul Jakma'" <[email-masked]>
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
Date: Sun, 7 Aug 2005 14:08:44 +0200
Cc: DECRAENE Bruno RD-CORE <[email-masked]>, [email-masked], FONDEVIOLE Benoit RD-CORE <[email-masked]>
Sender: [email-masked]

Basically GR restart is:
	Forwarding plane stays up / control plane says I'll be back.

Planned maintenance requirement is:
	Forwarding going away, control plane going away / let's do it
gracefully.

Best regards,
	
Nicolas Dubois
Tel :  0144442817	

> -----Message d'origine-----
> De : Paul Jakma [mailto:[email-masked]] 
> Envoyé : samedi 6 août 2005 16:46
> À : DUBOIS Nicolas ROSI/DAS/ARI
> Cc : [email-masked]; DECRAENE Bruno RD-CORE; FONDEVIOLE Benoit RD-CORE
> Objet : Re: [idr] BGP planned maintenance requirements as an 
> IDR WG doc
> 
> On Fri, 5 Aug 2005, DUBOIS Nicolas ROSI/DAS/ARI wrote:
> 
> > Hi Folks,
> >
> > Following IETF 63, I'd like to suggest that BGP planned maintenance 
> > requirements (draft-dubois-bgp-pm-reqs-02.txt) be 
> considered as an IDR 
> > working group document.
> 
> I meant to ask this at the WG meeting, but exactly what do 
> you intend to cover with this which isnt covered by graceful restart?
> 
> regards,
> -- 
> On the other hand, you have different fingers.

From: "DUBOIS Nicolas ROSI/DAS/ARI" <[email-masked]>
To: <[email-masked]>
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc 
Date: Sun, 7 Aug 2005 14:05:45 +0200
Cc: DECRAENE Bruno RD-CORE <[email-masked]>, [email-masked], FONDEVIOLE Benoit RD-CORE <[email-masked]>
Sender: [email-masked]

Curtis,

Thanks for reading the draft, some comments:

If you've got a 2.5 gig line card and want to upgrade it to a 10 or 40 gig
line card, I still think you need to shut down the BGP session that is
running on it and in order to replace the card.
 
Of course you can do it gracefully with some route-map tricks, ... But on
large operationnal routers it can be quite complex, and it would be better
to have it automatic and directly embedded in the router software.

BTW, graceful restart is really efficient when all (all !) peers are
supporting it.If some of the peer are not supporting it, I wouldn't say it's
harmful but ... You never know. I do not know many service providers who can
successfully use it on a large ASBRs currently. In our case many of our
customers and peers do not support GR even in helper only mode. So GR is
still a "for future use" feature to me.

> If you are taking a router completely out of service you can cost it
> out of the IGP first then take down the EBGP peerings, then shut it
> down. 

This is not going to work in all situations.

Best regards 
	
Nicolas Dubois
Tel :  0144442817	

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la 
> part de Curtis Villamizar
> Envoyé : vendredi 5 août 2005 22:00
> À : DUBOIS Nicolas ROSI/DAS/ARI
> Cc : DECRAENE Bruno RD-CORE; [email-masked]; FONDEVIOLE Benoit RD-CORE
> Objet : Re: [idr] BGP planned maintenance requirements as an 
> IDR WG doc 
> 
> 
> In message <[email-masked]>
> "DUBOIS Nicolas ROSI/DAS/ARI" writes:
> >  
> >  
> > Hi Folks,
> >  
> > Following IETF 63, I'd like to suggest that BGP planned maintenance 
> > requirements (draft-dubois-bgp-pm-reqs-02.txt) be 
> considered as an IDR 
> > working group document.
> >  
> > Thanks,
> >  
> > Nicolas
> > +33 1 44 44 28 17
> 
> 
> What's the point?  There is BGP gracefull restart and there are
> routers with warm standby route servers that can do things like
> software upgrades without impacting service.  All line cards these
> days are hot pluggable.
> 
> If you are taking a router completely out of service you can cost it
> out of the IGP first then take down the EBGP peerings, then shut it
> down.  These days better there is less need to do this.  For example,
> on some routers you can do a hardware upgrade to a newer route
> processor by installing it as a backup route processor and forcing a
> swap of control.
> 
> Unless you need to swap out a faulty backplane there are routers today
> that can be upgraded incrementally over a very wide range of capacity,
> including increasing the backplane capacity, all without a reboot.
> 
> Isn't this requirement a few years late?
> 
> Curtis
> 
> ps - send email off list if you want details that are outside the
> scope of the IDR discussion.
> 

Date: Sat, 06 Aug 2005 20:19:31 -0700
From: "Civvies D. Electrocardiographs" <[email-masked]>
To: Idr <[email-masked]>
Subject: Please visit our OEM software supertore!

This is a multi-part message in MIME format.

------------CE91B825A6030AC
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

 http://bkzu.unearnedkh.info/?OxQTQ3i0_npCyCO

Three steps to the software you need for the price you want.

 Please check our reduced price. 

 Premiere 6.5 - $80 
 Dreamweaver MX 2004 - $60 
 MS Office 2003 Professional (1 CD Edition) - $89.95 
 MS Plus! XP - $50 
 Flash MX 2004 - $60 
 Microsoft Office 2000 Premium Edition (2 CD Edition) - $59.95 
 Microsoft Office 2k PE (2 CD Edition) - $59.95 
 FreeHand MX - $60 
 Extensis Portfolio 7.0 - $50 
 Windows 98 - $40 
 Fireworks MX 2004 - $60 
 MS Office 2k PE (2 CD) - $59.95 
 Windows 2000 Professional - $59.95 
 Windows NT 4.0 Server - $40 
 MS Office 2003 Pro (1 CD Edition) - $89.95 

 Go to site
 http://avsvamo.jansenisten.info/?JsfOfuJrqiQxZ1J

------------CE91B825A6030AC
Content-Type: text/html
Content-Transfer-Encoding: 7bit

<html>
<head>
<meta content="text/html; charset=iso-8859-15" = http-equiv=Content-Type>
</head>
<body>

<table align=center>
<tr><td align=center>
<strong align=center><a href="http://evdqq.nonlifenj.info/?o7qtWFoCBt_cEcU">
<font size=4 color=#1213a7>
YAHOO software news
</a></strong>
</td></tr>
<tr><td align=center><font size=3>Check our prices.</font></td></tr>
</table>
<table align=center border=0>
<tr><td align=center colspan=2>Special Offers:</td></tr>
<tr><td>Bundle Special:Microsoft Win XP Pro + Microsoft Office XP Pro</td><td>$89.95</td></tr><tr><td>Bundle Special:Photoshop  + Premiere  + Illustrator </td><td>$129.95</td></tr><tr><td>Bundle Special:Win XP Pro With SP2 Full Version + Office 2003 Pro (1 CD)</td><td>$99.95</td></tr><tr><td>Bundle Special:Dreamwaver MX 2004 + Flash MX 2004</td><td>$109.95</td></tr>
<tr><td>&nbsp;</td></tr>
<tr><td align=center colspan=2>Microsoft|R| Windows|R| </td></tr>
<tr><td>Windows 2k Professional</td><td>$59.95</td></tr><tr><td>Windows 95</td><td>$49.95</td></tr><tr><td>Windows Millenium </td><td>$59.95</td></tr><tr><td>Windows XP Professional</td><td>$69.95</td></tr><tr><td>Windows 2k Advanced Server </td><td>$69.95</td></tr><tr><td>Windows XP Professional With SP2 Full Version</td><td>$79.95</td></tr><tr><td>Windows NT 4.0 Terminal Server</td><td>$49.95</td></tr><tr><td>Windows 98 Second Edition </td><td>$49.95</td></tr><tr><td>Windows NT 4.0 Server </td><td>$49.95</td></tr>
<tr><td>&nbsp;</td></tr>
<tr><td align=center colspan=2>Microsoft|R| Office|R|:</td></tr>
<tr><td>Office 2003 Pro (1 CD Edition)</td><td>$89.95</td></tr><tr><td>Office 2000 PE (2 CD)</td><td>$59.95</td></tr><tr><td>Office XP Pro</td><td>$79.95</td></tr>
<tr><td>&nbsp;</td></tr>
<tr><td align=center colspan=2>Other Microsoft|R| Software:</td></tr>
<tr><td>Microsoft Works 7</td><td>$69.95</tr></td><tr><td>Microsoft Money 2004</td><td>$69.95</tr></td><tr><td>Microsoft Picture It Premium 9</td><td>$59.95</tr></td><tr><td>Microsoft Streets and Trips 2004 North America (2 CD)</td><td>$69.95</tr></td><tr><td>Microsoft Visual Studio .NET Architect Edition (8CD)</td><td>$139.95</tr></td><tr><td>Microsoft Encarta Encyclopedia Delux 2004 (3 CD Edition)</td><td>$89.95</tr></td><tr><td>Microsoft Exchange 2003 Enterprise Server</td><td>$69.95</tr></td><tr><td>Microsoft SQL Server 2k Enterprise Edition</td><td>$69.95</tr></td><tr><td>Microsoft Project 2003 Professional</td><td>$69.95</tr></td><tr><td>Microsoft Plus! XP</td><td>$59.95</tr></td>
<tr><td>&nbsp;</td></tr>
<tr><td align=center colspan=2>Adobe Software for PC:</td></tr>
<tr><td> Photoshop Elements 3.0 Windows </td><td>$59.95</td></tr><tr><td> Premiere 7 </td><td>$69.95</td></tr><tr><td> Photoshop CS with ImageReady CS </td><td>$99.95</td></tr><tr><td> Creative Suite Standard (3 CD) </td><td>$129.95</td></tr><tr><td> Acrobat 6 Professional </td><td>$79.95</td></tr><tr><td> Photoshop 7 </td><td>$69.95</td></tr><tr><td> PageMaker 7 (2 CD) </td><td>$69.95</td></tr><tr><td> Creative Suite Premium (5 CD) </td><td>$149.95</td></tr><tr><td> InDesign CS PageMaker Edition (2 CD) </td><td>$69.95</td></tr><tr><td> Illustrator 10 </td><td>$69.95</td></tr>
<tr><td>&nbsp;</td></tr>
<tr><td align=center colspan=2>Adobe Software for Mac:</td></tr>
<tr><td>Adobe Premiere 6.5 (Apple Macintosh)</td><td>$89.95</td></tr><tr><td>Adobe InDesign CS (Apple Macintosh)</td><td>$69.95</td></tr><tr><td>Adobe Actobat 6 Pro (Apple Macintosh)</td><td>$79.95</td></tr><tr><td>Adobe LiveMotion 2 (Apple Macintosh)</td><td>$69.95</td></tr><tr><td>Adobe Illustrator CS CE (Apple Macintosh)</td><td>$69.95</td></tr><tr><td>Adobe Photoshop CS (Apple Macintosh)</td><td>$99.95</td></tr><tr><td>Adobe After Effects 6 (Apple Macintosh)</td><td>$69.95</td></tr>
<tr><td>&nbsp;</td></tr>
<tr><td align=center colspan=2>Macromedia Software for PC:</td></tr>
<tr><td>Macromedia Fireworks MX 2004</td><td>$69.95</tr></td><tr><td>Macromedia Dreamwaver MX 2004</td><td>$69.95</tr></td><tr><td>Macromedia Freehand MX 11</td><td>$69.95</tr></td><tr><td>Macromedia Flash MX 2004</td><td>$69.95</tr></td>
<tr><td>&nbsp;</td></tr>
<tr><td align=center colspan=2>Macromedia Software for Mac:</td></tr>
<tr><td>Macromedia Director MX 2004 (Mac)</td><td>$69.95</td></tr><tr><td>Macromedia Flash MX 2004 (Mac)</td><td>$69.95</td></tr><tr><td>Macromedia Studio MX 2004 with Director MX 2004 (Mac)</td><td>$139.95</td></tr><tr><td>Macromedia Dreamweaver MX 2004 (Mac)</td><td>$69.95</td></tr><tr><td>Macromedia Fireworks MX 2004 (Mac)</td><td>$69.95</td></tr><tr><td>Macromedia FreeHand MX (Mac)</td><td>$69.95</td></tr>
<tr><td>&nbsp;</td></tr>
<tr><td align=center colspan=2>Corel Software:</td></tr>
<tr><td>Corel Draw Graphics Suite 11</td><td>$59.95</td></tr><tr><td>Corel Draw Graphics Suite 11 (Mac)</td><td>$59.95</td></tr><tr><td>Corel Photo Painter 8.0</td><td>$59.95</td></tr><tr><td>Corel WordPerfect Office </td><td>$69.95</td></tr><tr><td>Corel Photo Painter 8.0 (Mac)</td><td>$59.95</td></tr>
<tr><td>&nbsp;</td></tr>

</table>
<table align=center>
<tr><td align=center>
<a href="http://evdqq.nonlifenj.info/?o7qtWFoCBt_cEcU"><h3><font size=3 color=#212346>Get to site</font></h3></a>

</td></tr>
</table>
</body>
</html>

------------CE91B825A6030AC--

Date: Sun, 7 Aug 2005 03:05:25 +0100 (BST)
From: John Smith <[email-masked]>
To: [email-masked]
Subject: [Idr] Minutes
Sender: [email-masked]

Hello,

Can somebody please post the minutes of the meeting?

Thanks,
JOhn

___________________________________________________________ 
How much free photo storage do you get? Store your holiday 
snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com

Date: Sat, 6 Aug 2005 15:46:11 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: DUBOIS Nicolas ROSI/DAS/ARI <[email-masked]>
Subject: Re: [idr] BGP planned maintenance requirements as an IDR WG doc
Mail-Copies-To: [email-masked]
Mail-Followup-To: [email-masked]
Cc: DECRAENE Bruno RD-CORE <[email-masked]>, [email-masked], FONDEVIOLE Benoit RD-CORE <[email-masked]>
Sender: [email-masked]

On Fri, 5 Aug 2005, DUBOIS Nicolas ROSI/DAS/ARI wrote:

> Hi Folks,
>
> Following IETF 63, I'd like to suggest that BGP planned maintenance 
> requirements (draft-dubois-bgp-pm-reqs-02.txt) be considered as an 
> IDR working group document.

I meant to ask this at the WG meeting, but exactly what do you intend 
to cover with this which isnt covered by graceful restart?

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
On the other hand, you have different fingers.

Date: Fri, 5 Aug 2005 18:13:16 -0400
From: John Leslie <[email-masked]>
To: Curtis Villamizar <[email-masked]>
Subject: Re: [idr] BGP planned maintenance requirements as an IDR WG doc
Cc: [email-masked], DUBOIS Nicolas ROSI/DAS/ARI <[email-masked]>
Sender: [email-masked]

Curtis Villamizar <[email-masked]> wrote:
> In message <[email-masked]>
> "DUBOIS Nicolas ROSI/DAS/ARI" writes:
>>  
>> Following IETF 63, I'd like to suggest that BGP planned maintenance
>> requirements (draft-dubois-bgp-pm-reqs-02.txt) be considered as an IDR
>> working group document.
> 
> What's the point?  There is BGP gracefull restart and there are
> routers with warm standby route servers that can do things like
> software upgrades without impacting service.  All line cards these
> days are hot pluggable.

   I cannot support this I-D as a Working Group document either; but my
problem with it is that it fails to propose adequate algorithms for
graceful shutdown. (There are occasions where power is failing and
shutdown will be necessary: if we were to adopt it, we should at least
change the title.)

   It would be good to have a mechanism for deprecating routes a bit
more gracefully than prepending in hopes that some other route will be
preferred; and it would be good to have some mechanism to ensure that
the propagation of deprecating routes never causes packets to be
dropped for lack of an immediately-available alternate route.

   But I do not see that in this draft.

--
John Leslie <[email-masked]>

To: "DUBOIS Nicolas ROSI/DAS/ARI" <[email-masked]>
Subject: Re: [idr] BGP planned maintenance requirements as an IDR WG doc 
Date: Fri, 05 Aug 2005 16:00:09 -0400
From: Curtis Villamizar <[email-masked]>
Cc: DECRAENE Bruno RD-CORE <[email-masked]>, [email-masked], FONDEVIOLE Benoit RD-CORE <[email-masked]>
Reply-To: [email-masked]
Sender: [email-masked]

In message <[email-masked]>
"DUBOIS Nicolas ROSI/DAS/ARI" writes:
>  
>  
> Hi Folks,
>  
> Following IETF 63, I'd like to suggest that BGP planned maintenance
> requirements (draft-dubois-bgp-pm-reqs-02.txt) be considered as an IDR
> working group document.
>  
> Thanks,
>  
> Nicolas 
> +33 1 44 44 28 17

What's the point?  There is BGP gracefull restart and there are
routers with warm standby route servers that can do things like
software upgrades without impacting service.  All line cards these
days are hot pluggable.

If you are taking a router completely out of service you can cost it
out of the IGP first then take down the EBGP peerings, then shut it
down.  These days better there is less need to do this.  For example,
on some routers you can do a hardware upgrade to a newer route
processor by installing it as a backup route processor and forcing a
swap of control.

Unless you need to swap out a faulty backplane there are routers today
that can be upgraded incrementally over a very wide range of capacity,
including increasing the backplane capacity, all without a reboot.

Isn't this requirement a few years late?

Curtis

ps - send email off list if you want details that are outside the
scope of the IDR discussion.

From: "DUBOIS Nicolas ROSI/DAS/ARI" <[email-masked]>
To: <[email-masked]>
Subject: [idr] BGP planned maintenance requirements as an IDR WG doc
Date: Fri, 5 Aug 2005 19:14:40 +0200
Cc: DECRAENE Bruno RD-CORE <[email-masked]>, FONDEVIOLE Benoit RD-CORE <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

--===============1949024237==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0046_01C599F1.ED856E80"

This is a multi-part message in MIME format.

------=_NextPart_000_0046_01C599F1.ED856E80
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Hi Folks,
 
Following IETF 63, I'd like to suggest that BGP planned maintenance
requirements (draft-dubois-bgp-pm-reqs-02.txt) be considered as an IDR
working group document. 
 
Thanks,
 
Nicolas 
+33 1 44 44 28 17

------=_NextPart_000_0046_01C599F1.ED856E80
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1505" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D369510417-05082005>Hi=20
Folks,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D369510417-05082005></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D369510417-05082005>Following IETF 63,=20
I'd like to suggest that BGP planned maintenance requirements=20
(draft-dubois-bgp-pm-reqs-02.txt) be considered as an IDR working group=20
document. </SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D369510417-05082005></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D369510417-05082005>Thanks,</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial size=3D2>Nicolas =
</FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial size=3D2>+33 1 44 44 28=20
17</FONT></DIV></BODY></HTML>

------=_NextPart_000_0046_01C599F1.ED856E80--

--===============1949024237==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--===============1949024237==--

Date: Thu, 4 Aug 2005 10:55:34 -0400
From: Jeffrey Haas <[email-masked]>
To: Bill Fenner <[email-masked]>
Subject: Re: [Idr] SAFI and other codepoint issues
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Bill,

On Thu, Aug 04, 2005 at 03:36:35PM +0200, Bill Fenner wrote:
>   However, as you know, circumstances dictated that 2547 be allowed to
> continue to use the "private use" number that it was deployed with.
> Obviously, a strict adherence to policy would have simply gotten in
> the way of having a working protocol.  I'm sure that there will be
> other examples of this coming soon.

Definitely.  One of the proposals is up to SAFI 132.  There may
be others beyond this, but I haven't found any with some quick googling.

>   The IETF has been working with the IANA since October 2004 to ensure
> that the IANA can meet the IETF's needs.  We agreed at that time that,
> as an interim goal, IANA should be able to allocate a number from a
> FCFS space within 30 days.

I suspect this will address 2/3 of the problem.

> Moving forward, I'd like to recommend the following:
> 
> - Reclassify 129-239 as "Reserved".
> - Retain 240-255 as "private use".
> - As needed, register values in the Reserved range if previously-deployed
>   protocols come into the IETF.
> - Recommend that new developments use FCFS or RFC4020 method to get
>   code points
> - In the future, if we run out of FCFS or IETF Consensus numbers,
>   start using the "Reserved" space as needed.

This seems very reasonable.

The other half of this effort is the awkward portion.  Working group
chairs need to be aware that things that are best done as FCFS or RFC 4020
should be done that way.  Drafts should be rejected as WG documents 
without getting an appropriate delegation.

-- 
Jeff Haas 
NextHop Technologies

To: [email-masked]
Subject: Re: [Idr] SAFI and other codepoint issues
Date: Thu, 4 Aug 2005 15:36:35 +0200
From: Bill Fenner <[email-masked]>
Versions: dmail (linux) 2.6d/makemail 2.10
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Jeff,

  Here's my proposal for this particular situation.  As you say, the
current ranges are:
1-63: "IETF Consensus"
64-127: "FCFS"
128-255: "private use"

  However, as you know, circumstances dictated that 2547 be allowed to
continue to use the "private use" number that it was deployed with.
Obviously, a strict adherence to policy would have simply gotten in
the way of having a working protocol.  I'm sure that there will be
other examples of this coming soon.

  The IETF has been working with the IANA since October 2004 to ensure
that the IANA can meet the IETF's needs.  We agreed at that time that,
as an interim goal, IANA should be able to allocate a number from a
FCFS space within 30 days.  They have implemented tracking systems and
hired staff and from what we can tell they are now meeting this goal.
Given this change, it may be more acceptable to use FCFS (or, perhaps,
the RFC 4020 "early allocation" mechanism) for newer work.

Moving forward, I'd like to recommend the following:

- Reclassify 129-239 as "Reserved".
- Retain 240-255 as "private use".
- As needed, register values in the Reserved range if previously-deployed
  protocols come into the IETF.
- Recommend that new developments use FCFS or RFC4020 method to get
  code points
- In the future, if we run out of FCFS or IETF Consensus numbers,
  start using the "Reserved" space as needed.

With respect to this kind of experience:

>: At least in my experience requesting a number from
>: IANA is equivalent to attempting a conversation w/ /dev/null.

I have no doubt that it *was* true, but the new process and planned
assignment progress monitoring system should make it a thing of the past.

  Bill

P.S. In the WG meeting, people asked for a pointer to this agreement
on the IANA site.  There is no such announcement at the moment, but
they have agreed to put one there and I will forward the information
when I get it.

Date: Wed, 03 Aug 2005 21:43:08 +0800
From: Zhang Renhai <[email-masked]>
Subject: Re: Re: [Idr] Re:Commentsondraft-zhang-idr-bgp-entire-routes-reflect-00.txt
To: Manav Bhatia <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sender: [email-masked]

Hi, Manav

  Sorry for replying you so late.

  Actually, I think if the attribute of any route is not changed when
forwarding, then loop will not occur.

Thanks,
Zhang 

======= 2005-07-30 08:03:00£º=======

>Hi Zhang,
>
>Besides proposing a way to advertise multiple paths,
>draft-bhatia-ecmp-routes-in-bgp-01.txt also discusses how an implementation
>should construct its AS_PATH wherein the path length is preserved and
>sufficient information is provided to avoid loops, if its using equal cost
>BGP paths for its forwarding.
>
>Thanks,
>Manav
>
>From: "Zhang Renhai" <[email-masked]>
>To: "Alvaro Retana" <[email-masked]>; "Tulip Rasputin"
><[email-masked]>
>Cc: <[email-masked]>; <[email-masked]>
>Sent: Friday, July 29, 2005 11:45 AM
>Subject: Re: [Idr]
>Re:Commentsondraft-zhang-idr-bgp-entire-routes-reflect-00.txt
>
>
>> Hi, Alvaro
>>
>>  I think this is an interesting topic because there are now three drafts
>addressing it
>> I recently looked through other two drafts,  one is yours and other is
>> draft-bhatia-ecmp-routes-in-bgp-01.txt,  and I think the goal is basically
>same but the
>> mechanism to achieve it is very different. If you will, I'd like to
>discuss with you next
>> week at Paris if the meeting time is not enough to talk.
>>
>> Cheers,
>> Zhang
>>
>> From: "Alvaro Retana" <[email-masked]>
>> To: "Tulip Rasputin" <[email-masked]>
>> Cc: <[email-masked]>; <[email-masked]>
>> Sent: Thursday, July 28, 2005 5:16 AM
>> Subject: Re: [Idr] Re:
>Commentsondraft-zhang-idr-bgp-entire-routes-reflect-00.txt
>>
>>
>> > On Tue, 19 Jul 2005, Tulip Rasputin wrote:
>> >
>> > Tulip:
>> >
>> > -> !> Would you be so kind to comment what proposed in your draft has
>not
>> > -> !> already been addressed in our ADD_PATHs proposal RR !>
>functionality
>> > -> wise ?
>> > ->
>> > -> I see absolutely nothing wrong in this!
>> > ->
>> > -> There isnt any rule in the IETF that forbids multiple submissions to
>> > -> achieve the same objective. Its left on the community to decide which
>> > -> proposal they are most comfortable with. If it happens to be the
>draft
>> > -> thats been submitted later, then so be it!
>> > ->
>> > -> IETF is an open standards body, in case you forgot that, and nothing,
>> > -> is patented here. If you dont want others to address the same issues
>> > -> that you've been trying to solve, then IETF isnt really the right
>place
>> > -> for you to start with!
>> > ->
>> > -> YOu should be patenting your ideas, but then, nobody else is going to
>> > -> implement them.
>> >
>> > I think Robert was only asking Zhang to compare...nothing else.
>> >
>> > In any case, I think we can all agree about the openness of the IETF,
>> > multiple solutions, community, etc..
>> >
>> > Just to clarify, we have no IPR claims over any part of the ADD_PATH
>work.
>> > Also, We have posted an update to the draft and plan to talk about it
>next
>> > week.
>> >
>> > Thanks!
>> >
>> > Alvaro.
>> >
>> > -> !> Ref: draft-walton-bgp-add-paths-03.txt
>> >

= = = = = = = = = = = = = = = = = = = =

¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Zhang Renhai
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡[email-masked]
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2005-08-03

To: Jeffrey Haas <[email-masked]>
Subject: Re: [Idr] SAFI and other codepoint issues 
Date: Tue, 02 Aug 2005 15:03:37 -0700
From: Yakov Rekhter <[email-masked]>
Cc: Alex Zinin <[email-masked]>, [email-masked], Bill Fenner <[email-masked]>
Sender: [email-masked]

Jeff,

> I am unable to attend this IETF and am unable to bring this issue 
> up in front of the sitting working group. I'd like to suggest
> that the working group spend a few cycles on what I perceive to be
> an issue with code point assignments.
> 
> RFC 2858's IANA considerations requested the following:
> 
> :    As specified in this document, the MPL_REACH_NLRI and MP_UNREACH_NLRI
> :    attributes contain the Subsequence Address Family Identifier (SAFI)
> :    field. The SAFI name space is defined in Section 9. The IANA will
> :    maintain and register values for the SAFI namespace as follows.  SAFI
> :    value 0 is reserved. SAFI values 1, 2, and 3 are assigned in this
> :    document.  SAFI values 4 through 63 are to be assigned by IANA using
> :    the "IETF Consensus" policy defined in RFC 2434. SAFI values 64
> :    through 127 are to be assigned by IANA, using the "First Come First
> :    Served" policy defined in RFC 2434. SAFI values 128 through 255 are
> :    for "private use", and values in this range are not to be assigned by
> :    IANA.
> 
> (I never noticed the typo, MPL_REACH_NLRI :-)
> 
> By definition of RFC 2434, private use is:
> 
> :       Private Use - For private or local use only, with the type and
> :            purpose defined by the local site. No attempt is made to
> :            prevent multiple sites from using the same value in different
> :            (and incompatible) ways. There is no need for IANA to review
> :            such assignments and assignments are not generally useful for
> :            interoperability.
> 
> I am under the general impression that "private use" should NOT be used
> for any protocol mechanism standardized by the IETF.  However, a number
> of mechanisms, deployed or in the process of being deployed, are making
> use of these supposed "private use" codepoints.  For example, RFC 2547
> utilizes SAFI 128.
> 
> IANA seems to be tracking this usage:
> http://www.iana.org/assignments/safi-namespace
> 
> An author of one of these recent mechanisms put it to me during
> a review:
> 
> : IANA managed space is not a realistic option imho... the process to
> : get a number assigned takes too long given that it is usually tied to
> : WG/IESG approval. At least in my experience requesting a number from
> : IANA is equivalent to attempting a conversation w/ /dev/null.
> 
> It seems to me that FCFS is the appropriate mechanism for this.  I have
> no experience in getting a FCFS assignment from IANA so I can't vouch
> for whether this experience is typical or not.
> 
> For the working group, I'd like to ask: Is there a better way to 
> avoid collisions other than behind-the-scenes collusion between vendors?
> 
> For the area directors: Are there really issues with IANA?  Why are
> we approving protocol mechanisms with code point assignments in
> supposedly private space?  Why is IANA tracking them?
> 
> This issue, in the grand scheme of things, is minor.  Work gets done and
> code gets written.  However, it argues we have a procedural issue.

Thanks for bringing this up. May I suggest that folks should look
at the discussion on the pwe3 wg mailing list subject "[PWE3] PWE3 
IANA policy - rough consesnus", as it is relevant to the topic brought
up here.

Yakov.

Date: Mon, 1 Aug 2005 17:02:22 -0400
From: Jeffrey Haas <[email-masked]>
To: [email-masked], Alex Zinin <[email-masked]>, Bill Fenner <[email-masked]>
Cc: Jeffrey Haas <[email-masked]>
Subject: [Idr] SAFI and other codepoint issues
Sender: [email-masked]

I am unable to attend this IETF and am unable to bring this issue 
up in front of the sitting working group. I'd like to suggest
that the working group spend a few cycles on what I perceive to be
an issue with code point assignments.

RFC 2858's IANA considerations requested the following:

:    As specified in this document, the MPL_REACH_NLRI and MP_UNREACH_NLRI
:    attributes contain the Subsequence Address Family Identifier (SAFI)
:    field. The SAFI name space is defined in Section 9. The IANA will
:    maintain and register values for the SAFI namespace as follows.  SAFI
:    value 0 is reserved. SAFI values 1, 2, and 3 are assigned in this
:    document.  SAFI values 4 through 63 are to be assigned by IANA using
:    the "IETF Consensus" policy defined in RFC 2434. SAFI values 64
:    through 127 are to be assigned by IANA, using the "First Come First
:    Served" policy defined in RFC 2434. SAFI values 128 through 255 are
:    for "private use", and values in this range are not to be assigned by
:    IANA.

(I never noticed the typo, MPL_REACH_NLRI :-)

By definition of RFC 2434, private use is:

:       Private Use - For private or local use only, with the type and
:            purpose defined by the local site. No attempt is made to
:            prevent multiple sites from using the same value in different
:            (and incompatible) ways. There is no need for IANA to review
:            such assignments and assignments are not generally useful for
:            interoperability.

I am under the general impression that "private use" should NOT be used
for any protocol mechanism standardized by the IETF.  However, a number
of mechanisms, deployed or in the process of being deployed, are making
use of these supposed "private use" codepoints.  For example, RFC 2547
utilizes SAFI 128.

IANA seems to be tracking this usage:
http://www.iana.org/assignments/safi-namespace

An author of one of these recent mechanisms put it to me during
a review:

: IANA managed space is not a realistic option imho... the process to
: get a number assigned takes too long given that it is usually tied to
: WG/IESG approval. At least in my experience requesting a number from
: IANA is equivalent to attempting a conversation w/ /dev/null.

It seems to me that FCFS is the appropriate mechanism for this.  I have
no experience in getting a FCFS assignment from IANA so I can't vouch
for whether this experience is typical or not.

For the working group, I'd like to ask: Is there a better way to 
avoid collisions other than behind-the-scenes collusion between vendors?

For the area directors: Are there really issues with IANA?  Why are
we approving protocol mechanisms with code point assignments in
supposedly private space?  Why is IANA tracking them?

This issue, in the grand scheme of things, is minor.  Work gets done and
code gets written.  However, it argues we have a procedural issue.

-- 
Jeff Haas 
NextHop Technologies

To: "DUBOIS Nicolas ROSI/DAS/ARI" <[email-masked]>
Subject: Re: [Idr] IDR WG agenda 
Date: Mon, 01 Aug 2005 10:29:39 -0700
From: Yakov Rekhter <[email-masked]>
Cc: [email-masked], "'Yakov Rekhter'" <[email-masked]>, FONDEVIOLE Benoit RD-CORE <[email-masked]>, DECRAENE Bruno RD-CORE <[email-masked]>, [email-masked]
Sender: [email-masked]

Nicolas,

> Hi Sue, Yakov,
> 
> Would it be possible to have a 10 min slot at the next IETF GROw meeting in
> order to present an updated version (to be posted soon) of the following
> draft: 
>   
> http://www.ietf.org/internet-drafts/draft-dubois-bgp-pm-reqs-01.txt 
>   
> We also requested a slot in the GROw working group. We do not know if it is
> better to present the draft in grow, in IDR or in both ?

I still did not receive the slides. Please send them to me asap.

Yakov.