date:20200204

Re: [GROW] Question about BGP Large Communities

2020-02-04 Thread Jakob Heitz (jheitz)

Private ASNs are 4,200,000,000 upwards.
I am requesting a block just below that > 4,000,000,000.

Regards,
Jakob.

From: Brian Dickson 
Sent: Tuesday, February 4, 2020 5:43 PM
To: Sriram, Kotikalapudi (Fed) 
Cc: John Heasly ; Jakob Heitz (jheitz) ; 
i...@ietf.org; grow@ietf.org
Subject: Re: Question about BGP Large Communities

On Tue, Feb 4, 2020 at 5:28 PM Sriram, Kotikalapudi (Fed) 
mailto:kotikalapudi.sri...@nist.gov>> wrote:
> > Does anyone want to co-author and suggest changes?
I would also be glad to participate in that effort.

I have looked at the proposals in the two drafts (Jacob and John H).
There are a few observations I would like to share.

As Alvaro pointed out, RFC 8092 says:
   This document defines the BGP Large Communities attribute as an
   optional transitive path attribute of variable length.

That means *all* BGP Large Communities are transitive. Do you agree?
RFC 8195 seems to be written in that spirit as well.

They are, by default, transitive, unless local policy is to either strip them 
or filter updates based on the values (or some portion out of the values, like 
bits 6-7).

The first 32 bits together are a Global Administrator (GA) ID.
So, it seems it would not be possible to use any part of it as data.
Otherwise, collisions (ambiguity) could happen when
other LCs use 4-octet ASNs in the Global Administrator field. Agree?

Only real ASNs have any reasonable expectation of collision protection and 
uniqueness, i.e. ASN values <4,000,000,000

I see Jacob's draft proposes using some portion of the first 32 bits as data.
The draft that John Heasly shared sets the first 32-bits to ASN value 0
to designate WK-LC;  so no part of the first 32-bits is data.

Another idea to consider:
Why not request IANA to assign a range of 256 or 1024 or some number (?)
of 4-byte ASN values to be allocated and used as GA ID for transitive WK-LCs?
A function (e.g., route-leak protection) that requires transitive WK-LC
will be allocated one these ASN values.
Then we don't waste any part of the first 32-bits to designate "type" of LC.

Jakob's proposal is quite reasonable.
The 32-bit ASN RFC (don't recall it offhand) reserves all values >4,000,000,000 
as private values.
Reserving only those that start (binary) 10 is a very small slice off that 
range, near the top but not the very top.
Having an extra 16 bits to play with, for every WKC, plus 2 bits per the T 
field, is plenty and very useful.
Only having two 32-bit values is overly limiting, IMHO.

Brian

That cleanly leaves 64 bits for local data (as RFC 8092 specifies)
which can accommodate two 4-byte ASNs if needed.

Sriram

> -Original Message-
> From: John Heasly mailto:h...@shrubbery.net>>
> Sent: Tuesday, February 4, 2020 5:55 PM
> To: Jakob Heitz (jheitz) mailto:jhe...@cisco.com>>
> Cc: Sriram, Kotikalapudi (Fed) 
> mailto:kotikalapudi.sri...@nist.gov>>; Job 
> Snijders
> mailto:j...@ntt.net>>; Nick Hilliard 
> mailto:n...@foobar.org>>; John Heasly
> mailto:h...@shrubbery.net>>; 
> i...@ietf.org; grow@ietf.org; 
> idr-cha...@ietf.org;
> grow-cha...@ietf.org; 
> a.e.azi...@gmail.com; Brian Dickson
> mailto:brian.peter.dick...@gmail.com>>
> Subject: Re: Question about BGP Large Communities
>
> Tue, Feb 04, 2020 at 08:45:40PM +, Jakob Heitz (jheitz):
> > A set of well known large communities could be useful.
> > I have a draft that I never submitted attached to this email.
> > Does anyone want to co-author and suggest changes?
>
> Hey Jacob,
> I'd work on that with you.  Job, Morrow and I also started a draft for
> Large WKCs, but we have not submitted anything - nor made any recent
> progress.
>
> IIRC, the direction we were intending to use 0 (zero) as the ASN, then
> define local data part 1 as WKC itself, and local data part 2 to be a
> value associated.
>
> I've attached that I have written so far.  Job and Morrow may or may not
> endorse this approach at this point.
>
> -heas
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Question about BGP Large Communities

2020-02-04 Thread Brian Dickson

Disagree, we want something deployed (large) and deployable (requiring only
IANA action, no vendor activity) immediately.
IMHO, any special handling or new code points or upgrades are non-starters.
This particularly applies to wide and extended
Brian

On Tue, Feb 4, 2020 at 5:41 PM Dongjie (Jimmy)  wrote:

> Agree that for this case it may be more convenient to just use extended
> community with a new type, this could avoid any possible collision with
> existing deployments, and save the effort of assigning a set of ASNs. Wide
> community may be too powerful for this:)
>
>
>
> Best regards,
>
> Jie
>
>
>
> *From:* Robert Raszuk [mailto:rob...@raszuk.net]
> *Sent:* Wednesday, February 5, 2020 6:38 AM
> *To:* Jakob Heitz (jheitz) 
> *Cc:* Sriram, Kotikalapudi (Fed) ; Job
> Snijders ; Nick Hilliard ; John Heasly <
> h...@shrubbery.net>; i...@ietf.org; grow-cha...@ietf.org;
> idr-cha...@ietf.org; grow@ietf.org
> *Subject:* Re: [GROW] Question about BGP Large Communities
>
>
>
>
>
> > How would you divide the numbers?
>
>
>
> I would not divide them at all in LCs. I would either define new type in
> extended communities or use wide communities.
>
>
>
> But I am a bit biased here ;-)
>
>
>
> Best,
>
> R,
>
>
>
> On Tue, Feb 4, 2020 at 11:34 PM Jakob Heitz (jheitz) 
> wrote:
>
> The numbers are a trade off. How would you divide the numbers?
>
> Thanks,
>
> Jakob.
>
>
>
> On Feb 4, 2020, at 2:19 PM, Robert Raszuk  wrote:
>
> 
>
> And you think 255 such known large communities will be sufficient ?
>
>
>
> Thx,
>
> R.
>
>
>
> On Tue, Feb 4, 2020 at 9:45 PM Jakob Heitz (jheitz) 
> wrote:
>
> A set of well known large communities could be useful.
>
> I have a draft that I never submitted attached to this email.
>
> Does anyone want to co-author and suggest changes?
>
>
>
> Regards,
>
> Jakob.
>
>
>
> *From:* Sriram, Kotikalapudi (Fed) 
> *Sent:* Tuesday, February 4, 2020 10:22 AM
> *To:* Jakob Heitz (jheitz) ; Job Snijders ;
> Nick Hilliard ; John Heasly 
> *Cc:* i...@ietf.org; grow@ietf.org; idr-cha...@ietf.org;
> grow-cha...@ietf.org; a.e.azi...@gmail.com; Brian Dickson <
> brian.peter.dick...@gmail.com>
> *Subject:* Question about BGP Large Communities
>
>
>
> In the route leaks solution draft,
>
>
> https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigation-02
>
> we (the authors) have proposed using BGP Large Community.
>
> We specify this to be a "well-known transitive Large Community".
>
>
>
> Question:
>
> Can the draft simply make an IANA request for
>
> a Global Administrator ASN value for Route Leaks Protection (RLP) type
>
> and request that it be published in IANA registry
>
> as a "well-known Transitive Large Community"?
>
>
>
> There is no IANA registry for Large Communities yet;
>
> we have requested IDR and GROW Chairs to facilitate that.
>
>
>
> 
>
> Details/background:
>
>
>
> We've read the following RFCs related to Large Communities:
>
> https://tools.ietf.org/html/rfc8092
>
> https://tools.ietf.org/html/rfc8195
>
>
>
> RFC 8195 has this table:
>
>
>  +---+-+
>
>  |   RFC8092| RFC
> 8195|
>
>
> +---+--+
>
>  | Global Administrator|  ASN |
>
>  |  Local Data Part 1   |Function
> |
>
>  |  Local Data Part 2   |   Parameter|
>
>
> ++-+
>
> which is instructive. In the examples that RFC 8195 offers,
>
> it appears it is *assumed* that the Large Communities are transitive.
>
>
>
> For comparison, in Extended Communities (RFC 7153), there are
>
> explicit Type values assigned for Transitive, Non-transitive, etc.
>
>
> https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml
>
> However, there is no such explicit Type specification
>
> for Large Communities (in RFC 8092 or elsewhere).
>
>
>
> Thank you.
>
> Sriram
>
>
>
>
>
>
>
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
>
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Question about BGP Large Communities

2020-02-04 Thread Jakob Heitz (jheitz)

I'm asking for 67 million AS numbers, after which there will still be over 4 
billion AS numbers,
not including the nearly 95 million private AS numbers.
That's not much more than your 1024.

Regards,
Jakob.

-Original Message-
From: Sriram, Kotikalapudi (Fed)  
Sent: Tuesday, February 4, 2020 5:29 PM
To: John Heasly ; Jakob Heitz (jheitz) 
Cc: i...@ietf.org; grow@ietf.org
Subject: RE: Question about BGP Large Communities

> > Does anyone want to co-author and suggest changes?
I would also be glad to participate in that effort.

I have looked at the proposals in the two drafts (Jacob and John H).  
There are a few observations I would like to share.

As Alvaro pointed out, RFC 8092 says:
   This document defines the BGP Large Communities attribute as an
   optional transitive path attribute of variable length.

That means *all* BGP Large Communities are transitive. Do you agree?
RFC 8195 seems to be written in that spirit as well. 

The first 32 bits together are a Global Administrator (GA) ID.
So, it seems it would not be possible to use any part of it as data.
Otherwise, collisions (ambiguity) could happen when 
other LCs use 4-octet ASNs in the Global Administrator field. Agree?
I see Jacob's draft proposes using some portion of the first 32 bits as data.
The draft that John Heasly shared sets the first 32-bits to ASN value 0
to designate WK-LC;  so no part of the first 32-bits is data.

Another idea to consider: 
Why not request IANA to assign a range of 256 or 1024 or some number (?) 
of 4-byte ASN values to be allocated and used as GA ID for transitive WK-LCs?
A function (e.g., route-leak protection) that requires transitive WK-LC 
will be allocated one these ASN values.
Then we don't waste any part of the first 32-bits to designate "type" of LC.
That cleanly leaves 64 bits for local data (as RFC 8092 specifies)
which can accommodate two 4-byte ASNs if needed.

Sriram

> -Original Message-
> From: John Heasly 
> Sent: Tuesday, February 4, 2020 5:55 PM
> To: Jakob Heitz (jheitz) 
> Cc: Sriram, Kotikalapudi (Fed) ; Job Snijders
> ; Nick Hilliard ; John Heasly
> ; i...@ietf.org; grow@ietf.org; idr-cha...@ietf.org;
> grow-cha...@ietf.org; a.e.azi...@gmail.com; Brian Dickson
> 
> Subject: Re: Question about BGP Large Communities
> 
> Tue, Feb 04, 2020 at 08:45:40PM +, Jakob Heitz (jheitz):
> > A set of well known large communities could be useful.
> > I have a draft that I never submitted attached to this email.
> > Does anyone want to co-author and suggest changes?
> 
> Hey Jacob,
> I'd work on that with you.  Job, Morrow and I also started a draft for
> Large WKCs, but we have not submitted anything - nor made any recent
> progress.
> 
> IIRC, the direction we were intending to use 0 (zero) as the ASN, then
> define local data part 1 as WKC itself, and local data part 2 to be a
> value associated.
> 
> I've attached that I have written so far.  Job and Morrow may or may not
> endorse this approach at this point.
> 
> -heas

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Question about BGP Large Communities

2020-02-04 Thread Brian Dickson

On Tue, Feb 4, 2020 at 5:28 PM Sriram, Kotikalapudi (Fed) <
kotikalapudi.sri...@nist.gov> wrote:

> > > Does anyone want to co-author and suggest changes?
> I would also be glad to participate in that effort.
>
> I have looked at the proposals in the two drafts (Jacob and John H).
> There are a few observations I would like to share.
>
> As Alvaro pointed out, RFC 8092 says:
>This document defines the BGP Large Communities attribute as an
>optional transitive path attribute of variable length.
>
> That means *all* BGP Large Communities are transitive. Do you agree?
> RFC 8195 seems to be written in that spirit as well.
>

They are, by default, transitive, unless local policy is to either strip
them or filter updates based on the values (or some portion out of the
values, like bits 6-7).


>
> The first 32 bits together are a Global Administrator (GA) ID.
> So, it seems it would not be possible to use any part of it as data.
> Otherwise, collisions (ambiguity) could happen when
> other LCs use 4-octet ASNs in the Global Administrator field. Agree?
>

Only real ASNs have any reasonable expectation of collision protection and
uniqueness, i.e. ASN values <4,000,000,000


> I see Jacob's draft proposes using some portion of the first 32 bits as
> data.
> The draft that John Heasly shared sets the first 32-bits to ASN value 0
> to designate WK-LC;  so no part of the first 32-bits is data.
>
> Another idea to consider:
> Why not request IANA to assign a range of 256 or 1024 or some number (?)
> of 4-byte ASN values to be allocated and used as GA ID for transitive
> WK-LCs?
> A function (e.g., route-leak protection) that requires transitive WK-LC
> will be allocated one these ASN values.
> Then we don't waste any part of the first 32-bits to designate "type" of
> LC.
>

Jakob's proposal is quite reasonable.
The 32-bit ASN RFC (don't recall it offhand) reserves all values
>4,000,000,000 as private values.
Reserving only those that start (binary) 10 is a very small slice off
that range, near the top but not the very top.
Having an extra 16 bits to play with, for every WKC, plus 2 bits per the T
field, is plenty and very useful.
Only having two 32-bit values is overly limiting, IMHO.

Brian



> That cleanly leaves 64 bits for local data (as RFC 8092 specifies)
> which can accommodate two 4-byte ASNs if needed.
>
> Sriram
>
> > -Original Message-
> > From: John Heasly 
> > Sent: Tuesday, February 4, 2020 5:55 PM
> > To: Jakob Heitz (jheitz) 
> > Cc: Sriram, Kotikalapudi (Fed) ; Job
> Snijders
> > ; Nick Hilliard ; John Heasly
> > ; i...@ietf.org; grow@ietf.org; idr-cha...@ietf.org;
> > grow-cha...@ietf.org; a.e.azi...@gmail.com; Brian Dickson
> > 
> > Subject: Re: Question about BGP Large Communities
> >
> > Tue, Feb 04, 2020 at 08:45:40PM +, Jakob Heitz (jheitz):
> > > A set of well known large communities could be useful.
> > > I have a draft that I never submitted attached to this email.
> > > Does anyone want to co-author and suggest changes?
> >
> > Hey Jacob,
> > I'd work on that with you.  Job, Morrow and I also started a draft for
> > Large WKCs, but we have not submitted anything - nor made any recent
> > progress.
> >
> > IIRC, the direction we were intending to use 0 (zero) as the ASN, then
> > define local data part 1 as WKC itself, and local data part 2 to be a
> > value associated.
> >
> > I've attached that I have written so far.  Job and Morrow may or may not
> > endorse this approach at this point.
> >
> > -heas
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Question about BGP Large Communities

2020-02-04 Thread Dongjie (Jimmy)

Agree that for this case it may be more convenient to just use extended 
community with a new type, this could avoid any possible collision with 
existing deployments, and save the effort of assigning a set of ASNs. Wide 
community may be too powerful for this:)

Best regards,
Jie

From: Robert Raszuk [mailto:rob...@raszuk.net]
Sent: Wednesday, February 5, 2020 6:38 AM
To: Jakob Heitz (jheitz) 
Cc: Sriram, Kotikalapudi (Fed) ; Job Snijders 
; Nick Hilliard ; John Heasly 
; i...@ietf.org; grow-cha...@ietf.org; idr-cha...@ietf.org; 
grow@ietf.org
Subject: Re: [GROW] Question about BGP Large Communities


> How would you divide the numbers?

I would not divide them at all in LCs. I would either define new type in 
extended communities or use wide communities.

But I am a bit biased here ;-)

Best,
R,

On Tue, Feb 4, 2020 at 11:34 PM Jakob Heitz (jheitz) 
mailto:jhe...@cisco.com>> wrote:
The numbers are a trade off. How would you divide the numbers?
Thanks,
Jakob.


On Feb 4, 2020, at 2:19 PM, Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:

And you think 255 such known large communities will be sufficient ?

Thx,
R.

On Tue, Feb 4, 2020 at 9:45 PM Jakob Heitz (jheitz) 
mailto:jhe...@cisco.com>> wrote:
A set of well known large communities could be useful.
I have a draft that I never submitted attached to this email.
Does anyone want to co-author and suggest changes?

Regards,
Jakob.

From: Sriram, Kotikalapudi (Fed) 
mailto:kotikalapudi.sri...@nist.gov>>
Sent: Tuesday, February 4, 2020 10:22 AM
To: Jakob Heitz (jheitz) mailto:jhe...@cisco.com>>; Job 
Snijders mailto:j...@ntt.net>>; Nick Hilliard 
mailto:n...@foobar.org>>; John Heasly 
mailto:h...@shrubbery.net>>
Cc: i...@ietf.org; grow@ietf.org; 
idr-cha...@ietf.org; 
grow-cha...@ietf.org; 
a.e.azi...@gmail.com; Brian Dickson 
mailto:brian.peter.dick...@gmail.com>>
Subject: Question about BGP Large Communities


In the route leaks solution draft,

https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigation-02

we (the authors) have proposed using BGP Large Community.

We specify this to be a "well-known transitive Large Community".



Question:

Can the draft simply make an IANA request for

a Global Administrator ASN value for Route Leaks Protection (RLP) type

and request that it be published in IANA registry

as a "well-known Transitive Large Community"?



There is no IANA registry for Large Communities yet;

we have requested IDR and GROW Chairs to facilitate that.





Details/background:



We've read the following RFCs related to Large Communities:

https://tools.ietf.org/html/rfc8092

https://tools.ietf.org/html/rfc8195



RFC 8195 has this table:

 +---+-+

 |   RFC8092| RFC 8195|

 +---+--+

 | Global Administrator|  ASN |

 |  Local Data Part 1   |Function  |

 |  Local Data Part 2   |   Parameter|

 ++-+

which is instructive. In the examples that RFC 8195 offers,

it appears it is *assumed* that the Large Communities are transitive.



For comparison, in Extended Communities (RFC 7153), there are

explicit Type values assigned for Transitive, Non-transitive, etc.

https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml

However, there is no such explicit Type specification

for Large Communities (in RFC 8092 or elsewhere).



Thank you.

Sriram






___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Question about BGP Large Communities

2020-02-04 Thread Sriram, Kotikalapudi (Fed)

> > Does anyone want to co-author and suggest changes?
I would also be glad to participate in that effort.

I have looked at the proposals in the two drafts (Jacob and John H).  
There are a few observations I would like to share.

As Alvaro pointed out, RFC 8092 says:
   This document defines the BGP Large Communities attribute as an
   optional transitive path attribute of variable length.

That means *all* BGP Large Communities are transitive. Do you agree?
RFC 8195 seems to be written in that spirit as well. 

The first 32 bits together are a Global Administrator (GA) ID.
So, it seems it would not be possible to use any part of it as data.
Otherwise, collisions (ambiguity) could happen when 
other LCs use 4-octet ASNs in the Global Administrator field. Agree?
I see Jacob's draft proposes using some portion of the first 32 bits as data.
The draft that John Heasly shared sets the first 32-bits to ASN value 0
to designate WK-LC;  so no part of the first 32-bits is data.

Another idea to consider: 
Why not request IANA to assign a range of 256 or 1024 or some number (?) 
of 4-byte ASN values to be allocated and used as GA ID for transitive WK-LCs?
A function (e.g., route-leak protection) that requires transitive WK-LC 
will be allocated one these ASN values.
Then we don't waste any part of the first 32-bits to designate "type" of LC.
That cleanly leaves 64 bits for local data (as RFC 8092 specifies)
which can accommodate two 4-byte ASNs if needed.

Sriram

> -Original Message-
> From: John Heasly 
> Sent: Tuesday, February 4, 2020 5:55 PM
> To: Jakob Heitz (jheitz) 
> Cc: Sriram, Kotikalapudi (Fed) ; Job Snijders
> ; Nick Hilliard ; John Heasly
> ; i...@ietf.org; grow@ietf.org; idr-cha...@ietf.org;
> grow-cha...@ietf.org; a.e.azi...@gmail.com; Brian Dickson
> 
> Subject: Re: Question about BGP Large Communities
> 
> Tue, Feb 04, 2020 at 08:45:40PM +, Jakob Heitz (jheitz):
> > A set of well known large communities could be useful.
> > I have a draft that I never submitted attached to this email.
> > Does anyone want to co-author and suggest changes?
> 
> Hey Jacob,
> I'd work on that with you.  Job, Morrow and I also started a draft for
> Large WKCs, but we have not submitted anything - nor made any recent
> progress.
> 
> IIRC, the direction we were intending to use 0 (zero) as the ASN, then
> define local data part 1 as WKC itself, and local data part 2 to be a
> value associated.
> 
> I've attached that I have written so far.  Job and Morrow may or may not
> endorse this approach at this point.
> 
> -heas

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Question about BGP Large Communities

2020-02-04 Thread Brian Dickson

Hi, Jakob,
I'm interested/willing to co-author and/or review as needed.
(FYI: it looks like your bit field is mis-aligned, there should be 6 bits
above the 2-bit T value, then 8 bits of WKC.)

I agree that 256 (0-255) is more than enough WKC values, given that like 3
or 4 have been used in old community space.

Brian

On Tue, Feb 4, 2020 at 12:45 PM Jakob Heitz (jheitz) 
wrote:

> A set of well known large communities could be useful.
>
> I have a draft that I never submitted attached to this email.
>
> Does anyone want to co-author and suggest changes?
>
>
>
> Regards,
>
> Jakob.
>
>
>
> *From:* Sriram, Kotikalapudi (Fed) 
> *Sent:* Tuesday, February 4, 2020 10:22 AM
> *To:* Jakob Heitz (jheitz) ; Job Snijders ;
> Nick Hilliard ; John Heasly 
> *Cc:* i...@ietf.org; grow@ietf.org; idr-cha...@ietf.org;
> grow-cha...@ietf.org; a.e.azi...@gmail.com; Brian Dickson <
> brian.peter.dick...@gmail.com>
> *Subject:* Question about BGP Large Communities
>
>
>
> In the route leaks solution draft,
>
>
> https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigation-02
>
> we (the authors) have proposed using BGP Large Community.
>
> We specify this to be a "well-known transitive Large Community".
>
>
>
> Question:
>
> Can the draft simply make an IANA request for
>
> a Global Administrator ASN value for Route Leaks Protection (RLP) type
>
> and request that it be published in IANA registry
>
> as a "well-known Transitive Large Community"?
>
>
>
> There is no IANA registry for Large Communities yet;
>
> we have requested IDR and GROW Chairs to facilitate that.
>
>
>
> 
>
> Details/background:
>
>
>
> We've read the following RFCs related to Large Communities:
>
> https://tools.ietf.org/html/rfc8092
>
> https://tools.ietf.org/html/rfc8195
>
>
>
> RFC 8195 has this table:
>
>
>  +---+-+
>
>  |   RFC8092| RFC
> 8195|
>
>
> +---+--+
>
>  | Global Administrator|  ASN |
>
>  |  Local Data Part 1   |Function
> |
>
>  |  Local Data Part 2   |   Parameter|
>
>
> ++-+
>
> which is instructive. In the examples that RFC 8195 offers,
>
> it appears it is *assumed* that the Large Communities are transitive.
>
>
>
> For comparison, in Extended Communities (RFC 7153), there are
>
> explicit Type values assigned for Transitive, Non-transitive, etc.
>
>
> https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml
>
> However, there is no such explicit Type specification
>
> for Large Communities (in RFC 8092 or elsewhere).
>
>
>
> Thank you.
>
> Sriram
>
>
>
>
>
>
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Question about BGP Large Communities

2020-02-04 Thread John Heasly

Tue, Feb 04, 2020 at 08:45:40PM +, Jakob Heitz (jheitz):
> A set of well known large communities could be useful.
> I have a draft that I never submitted attached to this email.
> Does anyone want to co-author and suggest changes?

Hey Jacob,
I'd work on that with you.  Job, Morrow and I also started a draft for
Large WKCs, but we have not submitted anything - nor made any recent
progress.

IIRC, the direction we were intending to use 0 (zero) as the ASN, then
define local data part 1 as WKC itself, and local data part 2 to be a
value associated.

I've attached that I have written so far.  Job and Morrow may or may not
endorse this approach at this point.

-heas




Global Routing OperationsJ. Snijders
Internet-DraftNTT Communications
Intended status: Standards TrackJune 4, 2019
Expires: December 6, 2019


BGP Well-known Large Communities
  draft-snjiders-bgp-wk-lc-00

Abstract

   This document describes well-known BGP Large Communities [RFC8092]
   akin to those of BGP Communities [RFC1997].

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 6, 2019.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents



SnijdersExpires December 6, 2019[Page 1]

Internet-Draft  BGP Well-known Large Communities   June 2019


   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Taxonomy of Well-known BGP Large Communities  . . . . . . . .   2
 2.1.  Well-known Global Administrator . . . . . . . . . . . . .   2
 2.2.  Local Data Part 1 . . . . . . . . . . . . . . . . . . . .   3
 2.3.  Local Data Part 2 . . . . . . . . . . . . . . . . . . . .   3
   3.  Well-known BGP Large Communities  . . . . . . . . . . . . . .   3
 3.1.  Examples  . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Applicable Uses . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
 7.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
 7.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   This document describes Well-known BGP Large Communities [RFC8092].
   Well-known BGP Communities [RFC1997] have proven utility and Well-
   known BGP Large Communities have supplemental benefit because their
   greater capacity allows for an accompanying argument, such as a four-
   octet BGP ASN [RFC6793].

   Furthermore, an IANA registry is created for these new Well-known
   Communities.

2.  Taxonomy of Well-known BGP Large Communities

   BGP Large Communities [RFC8092] are entities of three four-octet
   values known as the Global Administrator, and Local Data Part 1 and
   2.  The use of each is defined below.

2.1.  Well-known Global Administrator

   The Global Administrator (GA), or namespace identifier, is the BGP
   Autonomous System Number (ASN) that defined the significance of the
   subsequent Local Data Parts.  Because ASN 0 is otherwise prosc

Re: [GROW] Question about BGP Large Communities

2020-02-04 Thread Robert Raszuk

> How would you divide the numbers?

I would not divide them at all in LCs. I would either define new type in
extended communities or use wide communities.

But I am a bit biased here ;-)

Best,
R,

On Tue, Feb 4, 2020 at 11:34 PM Jakob Heitz (jheitz) 
wrote:

> The numbers are a trade off. How would you divide the numbers?
>
> Thanks,
> Jakob.
>
> On Feb 4, 2020, at 2:19 PM, Robert Raszuk  wrote:
>
> 
> And you think 255 such known large communities will be sufficient ?
>
> Thx,
> R.
>
> On Tue, Feb 4, 2020 at 9:45 PM Jakob Heitz (jheitz) 
> wrote:
>
>> A set of well known large communities could be useful.
>>
>> I have a draft that I never submitted attached to this email.
>>
>> Does anyone want to co-author and suggest changes?
>>
>>
>>
>> Regards,
>>
>> Jakob.
>>
>>
>>
>> *From:* Sriram, Kotikalapudi (Fed) 
>> *Sent:* Tuesday, February 4, 2020 10:22 AM
>> *To:* Jakob Heitz (jheitz) ; Job Snijders ;
>> Nick Hilliard ; John Heasly 
>> *Cc:* i...@ietf.org; grow@ietf.org; idr-cha...@ietf.org;
>> grow-cha...@ietf.org; a.e.azi...@gmail.com; Brian Dickson <
>> brian.peter.dick...@gmail.com>
>> *Subject:* Question about BGP Large Communities
>>
>>
>>
>> In the route leaks solution draft,
>>
>>
>> https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigation-02
>>
>> we (the authors) have proposed using BGP Large Community.
>>
>> We specify this to be a "well-known transitive Large Community".
>>
>>
>>
>> Question:
>>
>> Can the draft simply make an IANA request for
>>
>> a Global Administrator ASN value for Route Leaks Protection (RLP) type
>>
>> and request that it be published in IANA registry
>>
>> as a "well-known Transitive Large Community"?
>>
>>
>>
>> There is no IANA registry for Large Communities yet;
>>
>> we have requested IDR and GROW Chairs to facilitate that.
>>
>>
>>
>> 
>>
>> Details/background:
>>
>>
>>
>> We've read the following RFCs related to Large Communities:
>>
>> https://tools.ietf.org/html/rfc8092
>>
>> https://tools.ietf.org/html/rfc8195
>>
>>
>>
>> RFC 8195 has this table:
>>
>>
>>  +---+-+
>>
>>  |   RFC8092| RFC
>> 8195|
>>
>>
>> +---+--+
>>
>>  | Global Administrator|  ASN
>> |
>>
>>  |  Local Data Part 1   |
>> Function  |
>>
>>  |  Local Data Part 2   |   Parameter|
>>
>>
>> ++-+
>>
>> which is instructive. In the examples that RFC 8195 offers,
>>
>> it appears it is *assumed* that the Large Communities are transitive.
>>
>>
>>
>> For comparison, in Extended Communities (RFC 7153), there are
>>
>> explicit Type values assigned for Transitive, Non-transitive, etc.
>>
>>
>> https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml
>>
>> However, there is no such explicit Type specification
>>
>> for Large Communities (in RFC 8092 or elsewhere).
>>
>>
>>
>> Thank you.
>>
>> Sriram
>>
>>
>>
>>
>>
>>
>> ___
>> GROW mailing list
>> GROW@ietf.org
>> https://www.ietf.org/mailman/listinfo/grow
>>
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Question about BGP Large Communities

2020-02-04 Thread Jakob Heitz (jheitz)

The numbers are a trade off. How would you divide the numbers?

Thanks,
Jakob.

On Feb 4, 2020, at 2:19 PM, Robert Raszuk  wrote:


And you think 255 such known large communities will be sufficient ?

Thx,
R.

On Tue, Feb 4, 2020 at 9:45 PM Jakob Heitz (jheitz) 
mailto:jhe...@cisco.com>> wrote:
A set of well known large communities could be useful.
I have a draft that I never submitted attached to this email.
Does anyone want to co-author and suggest changes?

Regards,
Jakob.

From: Sriram, Kotikalapudi (Fed) 
mailto:kotikalapudi.sri...@nist.gov>>
Sent: Tuesday, February 4, 2020 10:22 AM
To: Jakob Heitz (jheitz) mailto:jhe...@cisco.com>>; Job 
Snijders mailto:j...@ntt.net>>; Nick Hilliard 
mailto:n...@foobar.org>>; John Heasly 
mailto:h...@shrubbery.net>>
Cc: i...@ietf.org; grow@ietf.org; 
idr-cha...@ietf.org; 
grow-cha...@ietf.org; 
a.e.azi...@gmail.com; Brian Dickson 
mailto:brian.peter.dick...@gmail.com>>
Subject: Question about BGP Large Communities


In the route leaks solution draft,

https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigation-02

we (the authors) have proposed using BGP Large Community.

We specify this to be a "well-known transitive Large Community".



Question:

Can the draft simply make an IANA request for

a Global Administrator ASN value for Route Leaks Protection (RLP) type

and request that it be published in IANA registry

as a "well-known Transitive Large Community"?



There is no IANA registry for Large Communities yet;

we have requested IDR and GROW Chairs to facilitate that.





Details/background:



We've read the following RFCs related to Large Communities:

https://tools.ietf.org/html/rfc8092

https://tools.ietf.org/html/rfc8195



RFC 8195 has this table:

 +---+-+

 |   RFC8092| RFC 8195|

 +---+--+

 | Global Administrator|  ASN |

 |  Local Data Part 1   |Function  |

 |  Local Data Part 2   |   Parameter|

 ++-+

which is instructive. In the examples that RFC 8195 offers,

it appears it is *assumed* that the Large Communities are transitive.



For comparison, in Extended Communities (RFC 7153), there are

explicit Type values assigned for Transitive, Non-transitive, etc.

https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml

However, there is no such explicit Type specification

for Large Communities (in RFC 8092 or elsewhere).



Thank you.

Sriram







___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Question about BGP Large Communities

2020-02-04 Thread Robert Raszuk

And you think 255 such known large communities will be sufficient ?

Thx,
R.

On Tue, Feb 4, 2020 at 9:45 PM Jakob Heitz (jheitz) 
wrote:

> A set of well known large communities could be useful.
>
> I have a draft that I never submitted attached to this email.
>
> Does anyone want to co-author and suggest changes?
>
>
>
> Regards,
>
> Jakob.
>
>
>
> *From:* Sriram, Kotikalapudi (Fed) 
> *Sent:* Tuesday, February 4, 2020 10:22 AM
> *To:* Jakob Heitz (jheitz) ; Job Snijders ;
> Nick Hilliard ; John Heasly 
> *Cc:* i...@ietf.org; grow@ietf.org; idr-cha...@ietf.org;
> grow-cha...@ietf.org; a.e.azi...@gmail.com; Brian Dickson <
> brian.peter.dick...@gmail.com>
> *Subject:* Question about BGP Large Communities
>
>
>
> In the route leaks solution draft,
>
>
> https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigation-02
>
> we (the authors) have proposed using BGP Large Community.
>
> We specify this to be a "well-known transitive Large Community".
>
>
>
> Question:
>
> Can the draft simply make an IANA request for
>
> a Global Administrator ASN value for Route Leaks Protection (RLP) type
>
> and request that it be published in IANA registry
>
> as a "well-known Transitive Large Community"?
>
>
>
> There is no IANA registry for Large Communities yet;
>
> we have requested IDR and GROW Chairs to facilitate that.
>
>
>
> 
>
> Details/background:
>
>
>
> We've read the following RFCs related to Large Communities:
>
> https://tools.ietf.org/html/rfc8092
>
> https://tools.ietf.org/html/rfc8195
>
>
>
> RFC 8195 has this table:
>
>
>  +---+-+
>
>  |   RFC8092| RFC
> 8195|
>
>
> +---+--+
>
>  | Global Administrator|  ASN |
>
>  |  Local Data Part 1   |Function
> |
>
>  |  Local Data Part 2   |   Parameter|
>
>
> ++-+
>
> which is instructive. In the examples that RFC 8195 offers,
>
> it appears it is *assumed* that the Large Communities are transitive.
>
>
>
> For comparison, in Extended Communities (RFC 7153), there are
>
> explicit Type values assigned for Transitive, Non-transitive, etc.
>
>
> https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml
>
> However, there is no such explicit Type specification
>
> for Large Communities (in RFC 8092 or elsewhere).
>
>
>
> Thank you.
>
> Sriram
>
>
>
>
>
>
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Question about BGP Large Communities

2020-02-04 Thread Jakob Heitz (jheitz)

A set of well known large communities could be useful.
I have a draft that I never submitted attached to this email.
Does anyone want to co-author and suggest changes?

Regards,
Jakob.

From: Sriram, Kotikalapudi (Fed) 
Sent: Tuesday, February 4, 2020 10:22 AM
To: Jakob Heitz (jheitz) ; Job Snijders ; Nick 
Hilliard ; John Heasly 
Cc: i...@ietf.org; grow@ietf.org; idr-cha...@ietf.org; grow-cha...@ietf.org; 
a.e.azi...@gmail.com; Brian Dickson 
Subject: Question about BGP Large Communities

In the route leaks solution draft,

https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigation-02

we (the authors) have proposed using BGP Large Community.

We specify this to be a "well-known transitive Large Community".

Question:

Can the draft simply make an IANA request for

a Global Administrator ASN value for Route Leaks Protection (RLP) type

and request that it be published in IANA registry

as a "well-known Transitive Large Community"?

There is no IANA registry for Large Communities yet;

we have requested IDR and GROW Chairs to facilitate that.

Details/background:

We've read the following RFCs related to Large Communities:

https://tools.ietf.org/html/rfc8092

https://tools.ietf.org/html/rfc8195

RFC 8195 has this table:

 +---+-+

 |   RFC8092| RFC 8195|

 +---+--+

 | Global Administrator|  ASN |

 |  Local Data Part 1   |Function  |

 |  Local Data Part 2   |   Parameter|

 ++-+

which is instructive. In the examples that RFC 8195 offers,

it appears it is *assumed* that the Large Communities are transitive.

For comparison, in Extended Communities (RFC 7153), there are

explicit Type values assigned for Transitive, Non-transitive, etc.

https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml

However, there is no such explicit Type specification

for Large Communities (in RFC 8092 or elsewhere).

Thank you.

Sriram

IDR J. Heitz
Internet-Draft Cisco
Intended status: Standards TrackFebruary 4, 2020
Expires: August 7, 2020

 BGP Well Known Large Community
draft-heitz-idr-wklc-00

Abstract

   A range of BGP Autonomous System Numbers is reserved to create a set
   of BGP Well Known Large Communities.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 7, 2020.

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must

HeitzExpires August 7, 2020 [Page 1]

Internet-Draft Well Known Large Community  February 2020

   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Encoding  . . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Transitivity  . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   3
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   3
   6.  Normative Referenc

Re: [GROW] [Idr] Question about BGP Large Communities

2020-02-04 Thread Robert Raszuk

Hi Sriram,

Just to add to what Alvaro said what you are looking for seems to be a new
type for the information required.

Large Communities are really unstructured from the perspective of types
like Extended Communities are.

But please observe that proposed Wide Communities do have support for
types:

https://tools.ietf.org/html/draft-ietf-idr-wide-bgp-communities-05

so perhaps you may want to take a look into this type of carrier as well.
Of course this assumes that more and more vendors will bring support of
Wide Communities to their BGP code at some point :).

Rgs,
Robert.




On Tue, Feb 4, 2020 at 8:09 PM Alvaro Retana  wrote:

> On February 4, 2020 at 1:22:11 PM, Sriram, Kotikalapudi (Fed) wrote:
>
> [Speaking as a WG participant.]
>
>
> Sriram:
>
> Hi!
>
>
> ...
> > Question:
> >
> > Can the draft simply make an IANA request for
> > a Global Administrator ASN value for Route Leaks Protection (RLP) type
> > and request that it be published in IANA registry
> > as a "well-known Transitive Large Community"?
>
> No.
>
> There is no IANA registry for Global Administrator because it is
> simply a "four-octet namespace identifier...SHOULD be an ASN"
> [rfc8092], but it doesn't have to be.
>
> Skimming through draft-ietf-grow-route-leak-detection-mitigation, I
> would say (personal opinion) that you have two options:
>
> (1) Describe the Local Data Parts so that they are well-known when
> used by any ASN (Global Administrator).  This has the disadvantage
> that the values may collide with existing policies (?).
>
> (2) Request IANA to assign an ASN for this application.  Take a look
> at rfc7249/§2.1, which talks about the allocation of special-purpose
> AS Numbers.  The advantage is obviously that collisions can be
> avoided, but it seems to me that it may be too much (an ASN) for just
> this application.
>
> So...if an ASN is requested, it would be independent of Large Communities..
>
>
> ...
> > it appears it is *assumed* that the Large Communities are transitive.
>
> rfc8092 "defines the BGP Large Communities attribute as an optional
> transitive path attribute".
>
> Regards,
>
> Alvaro.
>
> ___
> Idr mailing list
> i...@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Question about BGP Large Communities

2020-02-04 Thread Alvaro Retana

On February 4, 2020 at 1:22:11 PM, Sriram, Kotikalapudi (Fed) wrote:

[Speaking as a WG participant.]

Sriram:

Hi!

...
> Question:
>
> Can the draft simply make an IANA request for
> a Global Administrator ASN value for Route Leaks Protection (RLP) type
> and request that it be published in IANA registry
> as a "well-known Transitive Large Community"?

No.

There is no IANA registry for Global Administrator because it is
simply a "four-octet namespace identifier...SHOULD be an ASN"
[rfc8092], but it doesn't have to be.

Skimming through draft-ietf-grow-route-leak-detection-mitigation, I
would say (personal opinion) that you have two options:

(1) Describe the Local Data Parts so that they are well-known when
used by any ASN (Global Administrator).  This has the disadvantage
that the values may collide with existing policies (?).

(2) Request IANA to assign an ASN for this application.  Take a look
at rfc7249/§2.1, which talks about the allocation of special-purpose
AS Numbers.  The advantage is obviously that collisions can be
avoided, but it seems to me that it may be too much (an ASN) for just
this application.

So...if an ASN is requested, it would be independent of Large Communities.

...
> it appears it is *assumed* that the Large Communities are transitive.

rfc8092 "defines the BGP Large Communities attribute as an optional
transitive path attribute".

Regards,

Alvaro.

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] Question about BGP Large Communities

2020-02-04 Thread Sriram, Kotikalapudi (Fed)

In the route leaks solution draft,

https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigation-02

we (the authors) have proposed using BGP Large Community.

We specify this to be a "well-known transitive Large Community".



Question:

Can the draft simply make an IANA request for

a Global Administrator ASN value for Route Leaks Protection (RLP) type

and request that it be published in IANA registry

as a "well-known Transitive Large Community"?



There is no IANA registry for Large Communities yet;

we have requested IDR and GROW Chairs to facilitate that.





Details/background:



We've read the following RFCs related to Large Communities:

https://tools.ietf.org/html/rfc8092

https://tools.ietf.org/html/rfc8195



RFC 8195 has this table:

 +---+-+

 |   RFC8092| RFC 8195|

 +---+--+

 | Global Administrator|  ASN |

 |  Local Data Part 1   |Function  |

 |  Local Data Part 2   |   Parameter|

 ++-+

which is instructive. In the examples that RFC 8195 offers,

it appears it is *assumed* that the Large Communities are transitive.



For comparison, in Extended Communities (RFC 7153), there are

explicit Type values assigned for Transitive, Non-transitive, etc.

https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml

However, there is no such explicit Type specification

for Large Communities (in RFC 8092 or elsewhere).



Thank you.

Sriram






___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Question about BGP Large Communities

Re: [GROW] Question about BGP Large Communities

Re: [GROW] Question about BGP Large Communities

Re: [GROW] Question about BGP Large Communities

Re: [GROW] Question about BGP Large Communities

Re: [GROW] Question about BGP Large Communities

Re: [GROW] Question about BGP Large Communities

Re: [GROW] Question about BGP Large Communities

Re: [GROW] Question about BGP Large Communities

Re: [GROW] Question about BGP Large Communities

Re: [GROW] Question about BGP Large Communities

Re: [GROW] Question about BGP Large Communities

Re: [GROW] [Idr] Question about BGP Large Communities

Re: [GROW] Question about BGP Large Communities

[GROW] Question about BGP Large Communities

15 matches

Site Navigation

Mail list logo

Footer information