Inter-Domain Routing (idr)

Mach Chen | 9 Oct 13:31

Re: draft-ietf-idr-as-pathlimit-02 status, path forward

Yes
----- Original Message ----- 
From: "Yakov Rekhter" <yakov <at> juniper.net>
To: <idr <at> ietf.org>
Cc: <skh <at> nexthop.com>; <yakov <at> juniper.net>
Sent: Wednesday, September 27, 2006 2:12 AM
Subject: [Idr] draft-ietf-idr-as-pathlimit-02 status, path forward

> Folks,
> 
> This e-mail is to find if there is a consensus within the IDR WG for a
> request for an early allocation of a new BGP attribute code point
> as specified in draft-ietf-idr-as-pathlimit-02.
> 
> Please send your comments on this request. The deadline for comments
> is Oct 10, 2006.
> 
> Yakov.
> 
> P.S. Please remember that silence does not count (either way).
> 
> _______________________________________________
> Idr mailing list
> Idr <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/idr
>

_______________________________________________
Idr mailing list
Idr <at> ietf.org

(Continue reading)

headers

Kavitha G - TLS ,Chennai | 9 Oct 14:09

4-Byte ASN - subtype for extended community

For BGP 4-octet AS, what is the sub-type value to be used in extended communities?

In the draft 4-octet AS specific Extended community, the subtype are given for Route Target and Route Origin.

When there is no support for BGP-MPLS-VPN, how this 4-octet AS specific can be sent in the extended community attribute. [i.e., For general 4-octet AS number in extended comm, which is used similar to community attribute]

Is there a subtype mentioned for this kind of extended community usage or is it planned for future drafts

Thanks,

Kavitha

DISCLAIMER:
The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect.

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr

headers

Yakov Rekhter | 9 Oct 15:48

Re: 4-Byte ASN - subtype for extended community

Kavitha,

> For BGP 4-octet AS, what is the sub-type value to be used in extended
> communities?
>
> In the draft 4-octet AS specific Extended community, the subtype are
> given for Route Target and Route Origin.
> 
> When there is no support for BGP-MPLS-VPN, how this 4-octet AS specific 
> can be sent in the extended community attribute. [i.e., For general 
> 4-octet AS number in extended comm, which is used similar to community 
> attribute]

The IANA would need to create a registry (as specified in the
IANA Consideration section of draft-rekhter-as4octet-ext-community),
and then one would need to request an assignment from that registry.

Yakov.

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr

headers

The IESG | 9 Oct 20:43

Last Call: 'Canonical representation of 4-byte AS numbers' to Informational RFC (draft-michaelson-4byte-as-representation)

The IESG has received a request from an individual submitter to consider
the following document:

- 'Canonical representation of 4-byte AS numbers '
   <draft-michaelson-4byte-as-representation-01.txt> as an Informational
RFC

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
iesg <at> ietf.org or ietf <at> ietf.org mailing lists by 2006-11-06.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-michaelson-4byte-as-representation-01.txt

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr

headers

John Leslie | 9 Oct 22:11

Re: Last Call: 'Canonical representation of 4-byte AS numbers' to Informational RFC (draft-michaelson-4byte-as-representation)

The IESG <iesg-secretary <at> ietf.org> wrote:
> 
> The IESG has received a request from an individual submitter to consider
> the following document:
> 
> - 'Canonical representation of 4-byte AS numbers '
>    <draft-michaelson-4byte-as-representation-01.txt> as an Informational
> RFC

   While I entirely agree with the author that using ":" to separate the
high-order 16 bits from the low-order 16 bits would be a bad idea, I'm
not confident that using "." would be problem-free.

   The draft already mentions possible confusion with floating-point
numbers; I also see possible confusion in searching.

   Before trying to designate a "standard" representation, IMHO, we should
make sure there's a problem to be solved, and consider how likely our
"solution" is to prevail.

   And there's a particularly obvious alternative: simply continuing the
decimal notation used now. We've already adapted to five-digit decimal
numbers without a whimper: is there really any reason to believe six
digits will prove unworkable?

--
John Leslie <john <at> jlc.net>

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr

headers

Joe Abley | 10 Oct 06:09

Re: Re: Last Call: 'Canonical representation of 4-byte AS numbers' to Informational RFC (draft-michaelson-4byte-as-representation)

On 9-Oct-2006, at 15:11, John Leslie wrote:

>    And there's a particularly obvious alternative: simply  
> continuing the
> decimal notation used now. We've already adapted to five-digit decimal
> numbers without a whimper: is there really any reason to believe six
> digits will prove unworkable?

But then how do you distinguish between a 2-byte only AS number and a  
4-byte AS number which happens to be less than 0.65535?

Joe

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr

headers

Scott Leibrand | 10 Oct 15:05

Re: Re: Last Call: 'Canonical representation of 4-byte AS numbers' to Informational RFC (draft-michaelson-4byte-as-representation)

On 10/09/06 at 11:09pm -0500, Joe Abley <jabley <at> ca.afilias.info> wrote:

> On 9-Oct-2006, at 15:11, John Leslie wrote:
>
> >    And there's a particularly obvious alternative: simply continuing
> > the decimal notation used now. We've already adapted to five-digit
> > decimal numbers without a whimper: is there really any reason to
> > believe six digits will prove unworkable?
>
> But then how do you distinguish between a 2-byte only AS number and a
> 4-byte AS number which happens to be less than 0.65535?

There is no meaningful distinction, is there?  The only distinctions I can
see are for understanding how they'll work for backwards compatibility,
and "less than 65535" seems adequate for that.

I'm agnostic to which notation we should use, but I don't think it matters
all that much, as long as we avoid confusing ourselves.

-Scott

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr

headers

Bill Fenner | 10 Oct 15:36

Re: Re: Last Call: 'Canonical representation of 4-byte AS numbers' to Informational RFC (draft-michaelson-4byte-as-representation)


>[If you just use larger decimal values,]
>... how do you distinguish between a 2-byte only AS number and a  
>4-byte AS number which happens to be less than 0.65535?

When is this difference significant?  0.7018 == 7018, an AS number
is an AS number.  There are some AS numbers that can *only* be
represented in 4 bytes, but there isn't a different space for the
4-byte values.

I'm in the "having a common notation is better than not" camp - there is
no perfect notation, but if everyone ends up using the same notation,
it'll improve consistency and reduce confusion.  (I'd be willing to be
convinced "no notation is OK", i.e., people don't have a problem with
using longer and longer decimal strings - we probably don't expect to
get to 4294967295 but some would argue that's too long for people to
easily remember)

  Bill

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr

headers

Bruno Rijsman | 10 Oct 15:50

RE: Re: Last Call: 'Canonical representation of 4-byte ASnumbers' to Informational RFC(draft-michaelson-4byte-as-representation)

I second this, in other words: I am also in favor of simply displaying
4-octet AS numbers as (potentially large) decimal integer numbers.

There is already one widely used implementation that does just that.

The main reason for my preference is that there is no semantic
difference between 333 and 0.333: they both refer to the same autonomous
system. Consider an AS-path with traverses various islands of 2-octet
and 4-octet BGP speakers; it would probably be confusing if the AS
number flipped back and forth from 333 to 0.333.

-- Bruno

> -----Original Message-----
> From: Bill Fenner [mailto:fenner <at> research.att.com]
> Sent: Tuesday, October 10, 2006 9:37 AM
> To: Joe Abley
> Cc: idr <at> ietf.org; John Leslie; iesg <at> ietf.org
> Subject: Re: [Idr] Re: Last Call: 'Canonical representation of 4-byte
> ASnumbers' to Informational
> RFC(draft-michaelson-4byte-as-representation)
> 
> 
> 
> >[If you just use larger decimal values,]
> >... how do you distinguish between a 2-byte only AS number and a  
> >4-byte AS number which happens to be less than 0.65535?
> 
> When is this difference significant?  0.7018 == 7018, an AS number
> is an AS number.  There are some AS numbers that can *only* be
> represented in 4 bytes, but there isn't a different space for the
> 4-byte values.
> 
> I'm in the "having a common notation is better than not" camp 
> - there is
> no perfect notation, but if everyone ends up using the same notation,
> it'll improve consistency and reduce confusion.  (I'd be willing to be
> convinced "no notation is OK", i.e., people don't have a problem with
> using longer and longer decimal strings - we probably don't expect to
> get to 4294967295 but some would argue that's too long for people to
> easily remember)
> 
>   Bill
> 
> _______________________________________________
> Idr mailing list
> Idr <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/idr
> 

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr

headers

Joe Abley | 10 Oct 16:16

Re: Re: Last Call: 'Canonical representation of 4-byte AS numbers' to Informational RFC (draft-michaelson-4byte-as-representation)

On 10-Oct-2006, at 08:05, Scott Leibrand wrote:

> On 10/09/06 at 11:09pm -0500, Joe Abley <jabley <at> ca.afilias.info>  
> wrote:
>
>> But then how do you distinguish between a 2-byte only AS number and a
>> 4-byte AS number which happens to be less than 0.65535?
>
> There is no meaningful distinction, is there?

In terms of resource allocation, it seems to me that you only have to  
deal with 32-bit numbers, and no distinction is necessary.

In terms of presentation to an operator, e.g. as part of a "show"  
command, it also seems like whatever is simplest and easier on the  
eye wins.

(I would note that on cisco routers it's perfectly possible to view  
community string attributes as simple 32-bit numbers, but everybody  
seems to prefer the representation of two 16-bit values separated by  
a colon.)

In terms of encoding values into a wire format to include in a BGP  
attribute, though, might it not be important for the router to know  
which was intended? Perhaps not; I'm not a router vendor, and I'm not  
presupposing an answer.

Joe

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr

2	February 2012
53	January 2012
65	December 2011
177	November 2011
43	October 2011
9	September 2011
42	August 2011
33	July 2011
172	June 2011
43	May 2011
236	April 2011
166	March 2011
24	February 2011
33	January 2011
11	December 2010
156	November 2010
97	October 2010
115	September 2010
11	August 2010
124	July 2010
5	June 2010
14	May 2010
18	April 2010
43	March 2010
70	February 2010
7	January 2010
2	December 2009
32	November 2009
25	October 2009
2	September 2009
19	August 2009
144	July 2009
20	June 2009
33	May 2009
63	April 2009
185	March 2009
34	February 2009
26	January 2009
75	December 2008
112	November 2008
41	October 2008
60	September 2008
90	August 2008
69	July 2008
31	June 2008
45	May 2008
40	April 2008
47	March 2008
31	February 2008
15	January 2008
10	December 2007
4	November 2007
6	October 2007
16	September 2007
39	August 2007
34	July 2007
62	June 2007
3	May 2007
2	April 2007
32	March 2007
25	February 2007
8	January 2007
33	December 2006
21	November 2006
26	October 2006
107	September 2006
194	August 2006
12	July 2006
21	June 2006
13	May 2006
2	April 2006
21	March 2006
22	February 2006
83	January 2006
29	December 2005
54	November 2005
62	October 2005
15	September 2005
188	August 2005
29	July 2005
16	June 2005
1	May 2005
11	April 2005
18	March 2005
34	February 2005
22	January 2005
23	December 2004
30	November 2004
25	October 2004
46	September 2004
18	August 2004
54	July 2004
57	June 2004
210	May 2004
115	April 2004
111	March 2004
60	February 2004
12	January 2004
22	December 2003
39	November 2003
57	October 2003
47	September 2003
38	August 2003
66	July 2003
19	June 2003
43	May 2003
48	April 2003
98	March 2003
66	February 2003
91	January 2003
81	December 2002
137	November 2002
303	October 2002
735	September 2002
141	August 2002
227	July 2002
66	June 2002
112	May 2002
68	April 2002

Mon	Tue	Wed	Thu	Fri	Sat	Sun

						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30	31