[GROW]Re: [Technical Errata Reported] RFC4632 (7979)

[Rebecca VanRheenen]

FYI - this report has been deleted as junk.

Thank you.

RFC Editor/rv


> On Jun 10, 2024, at 10:25 AM, RFC Errata System  
> wrote:
> 
> The following errata report has been submitted for RFC4632,
> "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and 
> Aggregation Plan".
> 
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7979
> 
> --
> Type: Technical
> Reported by: Super Gargamaster 
> 
> Section: GLOBAL
> 
> Original Text
> -
> Graphically, this topology looks something like this:
> 
>   10.24.0.0 -- 10.24.7.0__ __10.32.0.0 - 10.32.15.0
>   C1: 10.24.0.0/21\   /  C7: 10.32.0.0/20
>\ /
> ++  ++
>   10.24.16.0 - 10.24.31.0_  ||  ||
>   C2: 10.24.16.0/20   \ ||  _10.24.12.0 - 10.24.15.0__  ||
>\|| / C4: 10.24.12.0/20\ ||
> ||/\||
>   10.24.8.0 - 10.24.11.0___/| PA |\ | PB |
>   C3: 10.24.8.0/22  || \__10.24.32.0 - 10.24.33.0___||
> ||C5: 10.24.32.0/23 ||
> ||  ||
>   10.24.34.0 - 10.24.35.0__/||  ||
>   C6: 10.24.34.0/23 ||  ||
> ++  ++
>   ||  ||
>   routing advertisements: ||  ||
>   ||  ||
>   10.24.12.0/22 (C4)  ||  10.24.12.0/22 (C4)  ||
>   10.32.0.0/20 (C7)   ||  10.24.32.0/23 (C5)  ||
>   10.24.0.0/13 (PA)   ||  10.32.0.0/13 (PB)   ||
>   ||  ||
>   VV  VV
> 
> Corrected Text
> --
> Q MIERDA se poneen a hacer dibujitops la re concha suya dinbujitos loco 
> dibujitos parecen nenes manga d giles /ponete la JPG embed protocol y q tanto 
> , ademas malisimo todo en GitHub me explican todo con cucharita de plata en 
> la boca sin estres ni nada, INUTILES x dios hgan algo 304 paginas hciendo la 
> dibujito y despues para explicar tenes q estrar hablando 49 minutos seguidos 
> en la clase d consulta porque ustedes nunca quieren alclarar nada es + me 
> parece q les gusta enmierdar y oscurecer todo asi despues nadie puede hacer 
> nada (HAGAN ALGO) y les tiene q andar lamiendo las botas a ustedes, EH QUE 
> PASA AAHI SALTO LA FICHA O QUE¡¡¡?
> 
> 
> 
> 
> 
> sources: https://www.youtube.com/watch?v=k6UOOvH_-RQ
> 
> Notes
> -
> puto
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". (If it is spam, it 
> will be removed shortly by the RFC Production Center.) Please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> will log in to change the status and edit the report, if necessary.
> 
> --
> RFC4632 (draft-ietf-grow-rfc1519bis-04)
> --
> Title   : Classless Inter-domain Routing (CIDR): The Internet 
> Address Assignment and Aggregation Plan
> Publication Date: August 2006
> Author(s)   : V. Fuller, T. Li
> Category: BEST CURRENT PRACTICE
> Source  : Global Routing Operations
> Stream  : IETF
> Verifying Party : IESG
> 

___
GROW mailing list -- grow@ietf.org
To unsubscribe send an email to grow-le...@ietf.org

[GROW][Technical Errata Reported] RFC4632 (7979)

[RFC Errata System]

The following errata report has been submitted for RFC4632,
"Classless Inter-domain Routing (CIDR): The Internet Address Assignment and 
Aggregation Plan".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7979

--
Type: Technical
Reported by: Super Gargamaster 

Section: GLOBAL

Original Text
-
Graphically, this topology looks something like this:

   10.24.0.0 -- 10.24.7.0__ __10.32.0.0 - 10.32.15.0
   C1: 10.24.0.0/21\   /  C7: 10.32.0.0/20
\ /
 ++  ++
   10.24.16.0 - 10.24.31.0_  ||  ||
   C2: 10.24.16.0/20   \ ||  _10.24.12.0 - 10.24.15.0__  ||
\|| / C4: 10.24.12.0/20\ ||
 ||/\||
   10.24.8.0 - 10.24.11.0___/| PA |\ | PB |
   C3: 10.24.8.0/22  || \__10.24.32.0 - 10.24.33.0___||
 ||C5: 10.24.32.0/23 ||
 ||  ||
   10.24.34.0 - 10.24.35.0__/||  ||
   C6: 10.24.34.0/23 ||  ||
 ++  ++
   ||  ||
   routing advertisements: ||  ||
   ||  ||
   10.24.12.0/22 (C4)  ||  10.24.12.0/22 (C4)  ||
   10.32.0.0/20 (C7)   ||  10.24.32.0/23 (C5)  ||
   10.24.0.0/13 (PA)   ||  10.32.0.0/13 (PB)   ||
   ||  ||
   VV  VV

Corrected Text
--
Q MIERDA se poneen a hacer dibujitops la re concha suya dinbujitos loco 
dibujitos parecen nenes manga d giles /ponete la JPG embed protocol y q tanto , 
ademas malisimo todo en GitHub me explican todo con cucharita de plata en la 
boca sin estres ni nada, INUTILES x dios hgan algo 304 paginas hciendo la 
dibujito y despues para explicar tenes q estrar hablando 49 minutos seguidos en 
la clase d consulta porque ustedes nunca quieren alclarar nada es + me parece q 
les gusta enmierdar y oscurecer todo asi despues nadie puede hacer nada (HAGAN 
ALGO) y les tiene q andar lamiendo las botas a ustedes, EH QUE PASA AAHI SALTO 
LA FICHA O QUE¡¡¡?





sources: https://www.youtube.com/watch?v=k6UOOvH_-RQ

Notes
-
puto

Instructions:
-
This erratum is currently posted as "Reported". (If it is spam, it 
will be removed shortly by the RFC Production Center.) Please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
will log in to change the status and edit the report, if necessary.

--
RFC4632 (draft-ietf-grow-rfc1519bis-04)
--
Title   : Classless Inter-domain Routing (CIDR): The Internet 
Address Assignment and Aggregation Plan
Publication Date: August 2006
Author(s)   : V. Fuller, T. Li
Category: BEST CURRENT PRACTICE
Source  : Global Routing Operations
Stream  : IETF
Verifying Party : IESG

___
GROW mailing list -- grow@ietf.org
To unsubscribe send an email to grow-le...@ietf.org

[GROW]Re: I-D Action: draft-ietf-grow-ixp-ext-comms-00.txt

[Gert Doering]

Hi,

On Sat, Jun 08, 2024 at 12:04:38AM +0200, Robert Raszuk wrote:
> Maybe it is out of scope. Or perhaps scope is just too narrow.
> 
> Anyhow ...
> 
> Imagine I an IXP client advertising a prefix to RS which I want to be
> distributed only to some client's ASNs.
> 
> So how do I signal such policy using Large Communities keeping in mind that
> such prefix is an IPv6 prefix ?
> 
> Using extended communities this is easily achievable using  IPv6 Address
> Specific Extended Community (value 25): Hint: RFC5701.

Where exactly are large communities tied to AFIs?

So, answering your question - you'd use the same large community values
as for an IPv4 prefix that you only want to be distributed to the same
client ASNs...

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Ingo Lalla,
   Karin Schuler, Sebastian Cler
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

___
GROW mailing list -- grow@ietf.org
To unsubscribe send an email to grow-le...@ietf.org

[GROW]Re: well known large communities

[Sriram, Kotikalapudi (Fed)]

Jeff,

>At best, a registry could be set aside for entries from a specifically 
>allocated AS number and implementors can get special semantics added to their 
>code for the specs over time. Not so much "well known" (and generally 
>supported) as it becomes registered.

>When it finally gets around to happening, I find it likely that either AS 
>65535 or 4294967295 get used. 

Staying away from carving out ASN space and motivated by your suggestion above, 
I see two options:

A.  A single ASN value (say 4294967295) is assigned as Global Admin value to 
signify WKLC (or "registered LC" as you seem to prefer).  Then some bits (one 
or two octets) from the data parts of the LC can be specified as a Type field 
to classify different applications (route leak detection, etc.).  The rest of 
the octets in the data parts are available for application use.

B.  Each application that requests a registered Global Admin value, gets a 
unique ASN value.  Then each application can specify and use the data parts of 
the LC as it likes.

In Option B, more bits (in fact the full 8 octets of the data parts) are 
available for the application use.

Sriram
=  


-Original Message-
From: Jeffrey Haas  
Sent: Friday, June 7, 2024 6:58 PM
To: Nick Hilliard 
Cc: grow@ietf.org
Subject: [GROW]Re: well known large communities

[Not a specific gripe at you, Nick.]

> On Jun 7, 2024, at 6:45 PM, Nick Hilliard  wrote:
> 
> [moving this to a new thread as it's unrelated to 
> draft-ietf-grow-ixp-ext-comms]
> 
> Robert Raszuk wrote on 07/06/2024 22:29:
>> True. But we there is clear opportunity to define those scoped for IXP use 
>> case. 
>> 
>> This is BCP so IMO good place to encourage using common encoding for most 
>> common needs. 
> 
> I'm not convinced this is a good plan. The semantics of the existing WKCs 
> have turned out to be unexpectedly complex in production environments, and 
> the semantics for candidate route server WKCs that have been discussed by RS 
> operators are a good deal more so. There have been proposals in the past 
> about this, but none have ended up with rigorous definitions or sample code.

Far more importantly, "well known" needed to have the semantics baked into the 
spec at the beginning.

The torches and pitchforks operator crowd that rammed through large communities 
in the current form weren't interested in slowing down and discussing how 
that'd work.

Thus, there is no such thing and the term should simply stop being used in this 
fashion.  

At best, a registry could be set aside for entries from a specifically 
allocated AS number and implementors can get special semantics added to their 
code for the specs over time. Not so much "well known" (and generally 
supported) as it becomes registered.

When it finally gets around to happening, I find it likely that either AS 65535 
or 4294967295 get used.  

-- Jeff (I assert no IPR over this.)
___
GROW mailing list -- grow@ietf.org
To unsubscribe send an email to grow-le...@ietf.org

[GROW]Re: well known large communities

[Stavros Konstantaras]

To be honest, I do see space for both drafts:  While the new draft discourages 
the use of EXT Comms and motivates the adoption for the Large ones, the expired 
draft sets the pavement for a more unified adoption. And perhaps is better to 
keep them separated as the old draft might be revisited (and possibly altered) 
many times in the future.

I can talk to the GROW-WG chairs to see what is required from IETF perspective 
to bring it back to life and proceed with adoption. It’s been quite some time, 
I can’t recall why a call for adoption didn’t happen back then, perhaps 
Melchior was de-motivated.


Kind Regards
Stavros
From: Robert Raszuk 
Date: Monday, 10 June 2024 at 15:55
To: Stavros Konstantaras 
Cc: grow@ietf.org , Jeffrey Haas 
Subject: Re: [GROW]Re: well known large communities

Hi,

I think this is a pretty useful draft.

I see that you did not even request an adoption call so hard to say that it did 
not go through. I only see a single email Tue, Mar 12, 2019, 12:34 AM from 
Melchior on it.

In fact if it would be adopted and perhaps by now published there would be no 
need for draft-ietf-grow-ixp-ext-comms :)

Cheers,
R.




On Mon, Jun 10, 2024 at 3:48 PM Stavros Konstantaras 
mailto:stavros.konstanta...@ams-ix.net>> wrote:
Hi Robert,

I do agree with the other colleagues that setting a list of WKLC for IXP 
purposes should stay outside of this draft.

However back on September 2019 we did try to set up a draft in GROW group 
(https://datatracker.ietf.org/doc/html/draft-adkp-grow-ixpcommunities-00) where 
we try to define some Large Communities for IXP purposes with the aim to unify 
operations. The draft unfortunately didn’t go through but if the community 
believes it is relevant, I am happy to resurrect it and go further with that.


Kind Regards
Stavros

From: Robert Raszuk mailto:rob...@raszuk.net>>
Date: Saturday, 8 June 2024 at 01:05
To: Jeffrey Haas mailto:jh...@pfrc.org>>
Cc: grow@ietf.org mailto:grow@ietf.org>>
Subject: [GROW]Re: well known large communities
Nick,

> [moving this to a new thread as it's unrelated to 
> draft-ietf-grow-ixp-ext-comms]

Well IMO it is very much related as that draft recommends a move from ExtComms 
to LargeComms.

For anyone taking it seriously a new encoding should be provided as a hint.

Jeff,

Actually what seems to be sort of lost in translation from what I intended to 
say was not so much well known large communities .. but well know IXP large 
communities.

I think we all agree that IXPs (especially IXP RS policies) are creating their 
own universe and IMO it is worth to a bit unify that space.

Many thx,
R.

PS. But if GROW WG thinks otherwise I rest my case. It was just light 
suggestion - no more.



On Sat, Jun 8, 2024 at 12:58 AM Jeffrey Haas 
mailto:jh...@pfrc.org>> wrote:
[Not a specific gripe at you, Nick.]

> On Jun 7, 2024, at 6:45 PM, Nick Hilliard 
> mailto:n...@foobar.org>> wrote:
>
> [moving this to a new thread as it's unrelated to 
> draft-ietf-grow-ixp-ext-comms]
>
> Robert Raszuk wrote on 07/06/2024 22:29:
>> True. But we there is clear opportunity to define those scoped for IXP use 
>> case.
>>
>> This is BCP so IMO good place to encourage using common encoding for most 
>> common needs.
>
> I'm not convinced this is a good plan. The semantics of the existing WKCs 
> have turned out to be unexpectedly complex in production environments, and 
> the semantics for candidate route server WKCs that have been discussed by RS 
> operators are a good deal more so. There have been proposals in the past 
> about this, but none have ended up with rigorous definitions or sample code.

Far more importantly, "well known" needed to have the semantics baked into the 
spec at the beginning.

The torches and pitchforks operator crowd that rammed through large communities 
in the current form weren't interested in slowing down and discussing how 
that'd work.

Thus, there is no such thing and the term should simply stop being used in this 
fashion.

At best, a registry could be set aside for entries from a specifically 
allocated AS number and implementors can get special semantics added to their 
code for the specs over time. Not so much "well known" (and generally 
supported) as it becomes registered.

When it finally gets around to happening, I find it likely that either AS 65535 
or 4294967295 get used.

-- Jeff (I assert no IPR over this.)
___
GROW mailing list -- grow@ietf.org
To unsubscribe send an email to grow-le...@ietf.org

[GROW]Re: well known large communities

[Robert Raszuk]

Hi,

I think this is a pretty useful draft.

I see that you did not even request an adoption call so hard to say that it
did not go through. I only see a single email Tue, Mar 12, 2019, 12:34 AM
from Melchior on it.

In fact if it would be adopted and perhaps by now published there would be
no need for draft-ietf-grow-ixp-ext-comms :)

Cheers,
R.




On Mon, Jun 10, 2024 at 3:48 PM Stavros Konstantaras <
stavros.konstanta...@ams-ix.net> wrote:

> Hi Robert,
>
>
>
> I do agree with the other colleagues that setting a list of WKLC for IXP
> purposes should stay outside of this draft.
>
>
>
> However back on September 2019 we did try to set up a draft in GROW group (
> https://datatracker.ietf.org/doc/html/draft-adkp-grow-ixpcommunities-00)
> where we try to define some Large Communities for IXP purposes with the aim
> to unify operations. The draft unfortunately didn’t go through but if the
> community believes it is relevant, I am happy to resurrect it and go
> further with that.
>
>
>
>
>
> Kind Regards
>
> Stavros
>
>
>
> *From: *Robert Raszuk 
> *Date: *Saturday, 8 June 2024 at 01:05
> *To: *Jeffrey Haas 
> *Cc: *grow@ietf.org 
> *Subject: *[GROW]Re: well known large communities
>
> Nick,
>
>
>
> > [moving this to a new thread as it's unrelated to
> draft-ietf-grow-ixp-ext-comms]
>
>
>
> Well IMO it is very much related as that draft recommends a move from
> ExtComms to LargeComms.
>
>
>
> For anyone taking it seriously a new encoding should be provided as a
> hint.
>
>
>
> Jeff,
>
>
>
> Actually what seems to be sort of lost in translation from what I intended
> to say was not so much well known large communities .. but well know IXP
> large communities.
>
>
>
> I think we all agree that IXPs (especially IXP RS policies) are creating
> their own universe and IMO it is worth to a bit unify that space.
>
>
>
> Many thx,
> R.
>
>
>
> PS. But if GROW WG thinks otherwise I rest my case. It was just light
> suggestion - no more.
>
>
>
>
>
>
>
> On Sat, Jun 8, 2024 at 12:58 AM Jeffrey Haas  wrote:
>
> [Not a specific gripe at you, Nick.]
>
> > On Jun 7, 2024, at 6:45 PM, Nick Hilliard  wrote:
> >
> > [moving this to a new thread as it's unrelated to
> draft-ietf-grow-ixp-ext-comms]
> >
> > Robert Raszuk wrote on 07/06/2024 22:29:
> >> True. But we there is clear opportunity to define those scoped for IXP
> use case.
> >>
> >> This is BCP so IMO good place to encourage using common encoding for
> most common needs.
> >
> > I'm not convinced this is a good plan. The semantics of the existing
> WKCs have turned out to be unexpectedly complex in production environments,
> and the semantics for candidate route server WKCs that have been discussed
> by RS operators are a good deal more so. There have been proposals in the
> past about this, but none have ended up with rigorous definitions or sample
> code.
>
> Far more importantly, "well known" needed to have the semantics baked into
> the spec at the beginning.
>
> The torches and pitchforks operator crowd that rammed through large
> communities in the current form weren't interested in slowing down and
> discussing how that'd work.
>
> Thus, there is no such thing and the term should simply stop being used in
> this fashion.
>
> At best, a registry could be set aside for entries from a specifically
> allocated AS number and implementors can get special semantics added to
> their code for the specs over time. Not so much "well known" (and generally
> supported) as it becomes registered.
>
> When it finally gets around to happening, I find it likely that either AS
> 65535 or 4294967295 get used.
>
> -- Jeff (I assert no IPR over this.)
>
>
___
GROW mailing list -- grow@ietf.org
To unsubscribe send an email to grow-le...@ietf.org

[GROW]Re: well known large communities

[Stavros Konstantaras]

Hi Robert,

I do agree with the other colleagues that setting a list of WKLC for IXP 
purposes should stay outside of this draft.

However back on September 2019 we did try to set up a draft in GROW group 
(https://datatracker.ietf.org/doc/html/draft-adkp-grow-ixpcommunities-00) where 
we try to define some Large Communities for IXP purposes with the aim to unify 
operations. The draft unfortunately didn’t go through but if the community 
believes it is relevant, I am happy to resurrect it and go further with that.


Kind Regards
Stavros

From: Robert Raszuk 
Date: Saturday, 8 June 2024 at 01:05
To: Jeffrey Haas 
Cc: grow@ietf.org 
Subject: [GROW]Re: well known large communities
Nick,

> [moving this to a new thread as it's unrelated to 
> draft-ietf-grow-ixp-ext-comms]

Well IMO it is very much related as that draft recommends a move from ExtComms 
to LargeComms.

For anyone taking it seriously a new encoding should be provided as a hint.

Jeff,

Actually what seems to be sort of lost in translation from what I intended to 
say was not so much well known large communities .. but well know IXP large 
communities.

I think we all agree that IXPs (especially IXP RS policies) are creating their 
own universe and IMO it is worth to a bit unify that space.

Many thx,
R.

PS. But if GROW WG thinks otherwise I rest my case. It was just light 
suggestion - no more.



On Sat, Jun 8, 2024 at 12:58 AM Jeffrey Haas 
mailto:jh...@pfrc.org>> wrote:
[Not a specific gripe at you, Nick.]

> On Jun 7, 2024, at 6:45 PM, Nick Hilliard 
> mailto:n...@foobar.org>> wrote:
>
> [moving this to a new thread as it's unrelated to 
> draft-ietf-grow-ixp-ext-comms]
>
> Robert Raszuk wrote on 07/06/2024 22:29:
>> True. But we there is clear opportunity to define those scoped for IXP use 
>> case.
>>
>> This is BCP so IMO good place to encourage using common encoding for most 
>> common needs.
>
> I'm not convinced this is a good plan. The semantics of the existing WKCs 
> have turned out to be unexpectedly complex in production environments, and 
> the semantics for candidate route server WKCs that have been discussed by RS 
> operators are a good deal more so. There have been proposals in the past 
> about this, but none have ended up with rigorous definitions or sample code.

Far more importantly, "well known" needed to have the semantics baked into the 
spec at the beginning.

The torches and pitchforks operator crowd that rammed through large communities 
in the current form weren't interested in slowing down and discussing how 
that'd work.

Thus, there is no such thing and the term should simply stop being used in this 
fashion.

At best, a registry could be set aside for entries from a specifically 
allocated AS number and implementors can get special semantics added to their 
code for the specs over time. Not so much "well known" (and generally 
supported) as it becomes registered.

When it finally gets around to happening, I find it likely that either AS 65535 
or 4294967295 get used.

-- Jeff (I assert no IPR over this.)
___
GROW mailing list -- grow@ietf.org
To unsubscribe send an email to grow-le...@ietf.org

[GROW]Re: well known large communities

[Tobias Fiebig]

Moin,

On Sun, 2024-06-09 at 13:51 +0200, Robert Raszuk wrote:
> Indeed carving out some chunks of ASN space is a hack. 

While we are at the topic of hacks: Why not write an informational
document defining a structure for 'description:' to encode LC ->
meaning in registry data? Or adding a new field?

Or, define a field that points at an API endpoint/well-defined location
that delivers the data in some structured format.

Guess that would be more of an RIR-DB-WG thing, though.


With best regards,
Tobias

-- 
Dr.-Ing. Tobias Fiebig
T +31 616 80 98 99
M tob...@fiebig.nl

___
GROW mailing list -- grow@ietf.org
To unsubscribe send an email to grow-le...@ietf.org