Re: [GROW] Working Group Adoption Call: draft-wilhelm-grow-anycast-community (Ends 22/Nov/2022)

[Robert Raszuk]

Interesting observation indeed.

I guess it depends on macro view if we are talking global or intradomain
("limited domains").

Cheers,
R.

On Sun, Nov 26, 2023 at 6:05 PM David Farmer  wrote:

> I don’t think you need multi path to utilize this anycast community,
> neither do you need to override hot potato routing. In fact in my mind,
> when this community is set you want to ensure hot potato routing, even if
> your normal policy was not to use hot potato routing.
>
> For example, in the research and education (R) community, it is common
> to local preference routes from other R networks above the commodity
> Internet. However, routes marked with this anycast community would likely
> be an exception to this policy helping to ensure hot potato routing for
> anycast prefixes, even when the normal policy is not to use hot potato
> routing.
>
> Thanks.
>
>
>
> On Sun, Nov 26, 2023 at 09:02 Robert Raszuk  wrote:
>
>> Hi,
>>
>> So I reread this discussion and have one more question .. .
>>
>> Abstract says:
>>
>>
>>
>>
>> *To allow operators to take well informed decisions on which prefixesare
>> carrying anycast traffic this document proposes a well-known BGPcommunity
>> to denote this property.*
>>
>> Cool - but how is this decision going to be instantiated in the router ?
>>
>> Effectively to make use of this community (provided all good marking and
>> good will of transits) you need to have some hooks in your local BGP
>> implementations to allow for multipath selection when at least one received
>> prefix is marked with such community.
>>
>> Of course if someone already enables ebgp or ibgp multipath for all
>> prefixes there is nothing to do here, but if you are generally just
>> selecting a single best path and doing hot potato routing I am missing how
>> any operator will  (or can) actually use this community effectively.
>>
>> Cheers,
>> Robert
>>
>>
>> On Sun, Nov 26, 2023 at 2:50 PM Job Snijders > 40fastly@dmarc.ietf.org> wrote:
>>
>>> Dear Maximilian,
>>>
>>> On Sun, Nov 26, 2023 at 02:45:58PM +0100, Maximilian Wilhelm wrote:
>>> > Anno domini 2023 Maximilian Wilhelm scripsit:
>>> >
>>> > [...]
>>> > > Some time has past and I don't see any new comments, neither here nor
>>> > > to us authors.
>>> > >
>>> > > Hence I'd like to ask the chairs to start the WG Last Call.
>>> >
>>> > I believe this didn't happen so far, or did I miss it? :)
>>> >
>>> > So I'd like to ask to start the WG Last Call, or, if there is no
>>> > interest in getting this into an RFC, to call that out. :)
>>>
>>> Thanks for the poke
>>>
>>> Looking back I see two messages with comments that probably need
>>> addressing:
>>>
>>> https://mailarchive.ietf.org/arch/msg/grow/5iJ-QpjcPXOwIGhuOQMKn_FYQQc/
>>> https://mailarchive.ietf.org/arch/msg/grow/cdlMR2A0-gHqDwIf-UNkBvqVixw/
>>>
>>> Kind regards,
>>>
>>> Job
>>>
>>> ___
>>> 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] Working Group Adoption Call: draft-wilhelm-grow-anycast-community (Ends 22/Nov/2022)

[David Farmer]

I don’t think you need multi path to utilize this anycast community,
neither do you need to override hot potato routing. In fact in my mind,
when this community is set you want to ensure hot potato routing, even if
your normal policy was not to use hot potato routing.

For example, in the research and education (R) community, it is common to
local preference routes from other R networks above the commodity
Internet. However, routes marked with this anycast community would likely
be an exception to this policy helping to ensure hot potato routing for
anycast prefixes, even when the normal policy is not to use hot potato
routing.

Thanks.



On Sun, Nov 26, 2023 at 09:02 Robert Raszuk  wrote:

> Hi,
>
> So I reread this discussion and have one more question .. .
>
> Abstract says:
>
>
>
>
> *To allow operators to take well informed decisions on which prefixesare
> carrying anycast traffic this document proposes a well-known BGPcommunity
> to denote this property.*
>
> Cool - but how is this decision going to be instantiated in the router ?
>
> Effectively to make use of this community (provided all good marking and
> good will of transits) you need to have some hooks in your local BGP
> implementations to allow for multipath selection when at least one received
> prefix is marked with such community.
>
> Of course if someone already enables ebgp or ibgp multipath for all
> prefixes there is nothing to do here, but if you are generally just
> selecting a single best path and doing hot potato routing I am missing how
> any operator will  (or can) actually use this community effectively.
>
> Cheers,
> Robert
>
>
> On Sun, Nov 26, 2023 at 2:50 PM Job Snijders  40fastly@dmarc.ietf.org> wrote:
>
>> Dear Maximilian,
>>
>> On Sun, Nov 26, 2023 at 02:45:58PM +0100, Maximilian Wilhelm wrote:
>> > Anno domini 2023 Maximilian Wilhelm scripsit:
>> >
>> > [...]
>> > > Some time has past and I don't see any new comments, neither here nor
>> > > to us authors.
>> > >
>> > > Hence I'd like to ask the chairs to start the WG Last Call.
>> >
>> > I believe this didn't happen so far, or did I miss it? :)
>> >
>> > So I'd like to ask to start the WG Last Call, or, if there is no
>> > interest in getting this into an RFC, to call that out. :)
>>
>> Thanks for the poke
>>
>> Looking back I see two messages with comments that probably need
>> addressing:
>>
>> https://mailarchive.ietf.org/arch/msg/grow/5iJ-QpjcPXOwIGhuOQMKn_FYQQc/
>> https://mailarchive.ietf.org/arch/msg/grow/cdlMR2A0-gHqDwIf-UNkBvqVixw/
>>
>> Kind regards,
>>
>> Job
>>
>> ___
>> 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] Working Group Adoption Call: draft-wilhelm-grow-anycast-community (Ends 22/Nov/2022)

[Robert Raszuk]

Gert,

I get that. And I am not asking to add specific prescription for automagic.

However if I am reading this RFC as a vendor or as an operator I would find
useful to have a section recommending a way in which I can use it a bit
more directly then match in the policy.

In fact to the best of my knowledge today bgp implementations do not have a
clear way to enable multipath selectively (say only on some prefixes marked
as anycast) in a given routing context. That was my point here.

Cheers,
R.



On Sun, Nov 26, 2023 at 4:43 PM Gert Doering  wrote:

> Hi,
>
> On Sun, Nov 26, 2023 at 04:02:31PM +0100, Robert Raszuk wrote:
> > Effectively to make use of this community (provided all good marking and
> > good will of transits) you need to have some hooks in your local BGP
> > implementations to allow for multipath selection when at least one
> received
> > prefix is marked with such community.
>
> The intention is not to instanciate magic handling of such in the receiving
> routers - it's to permit an informed choice by the receiving operator
> (like, "do not force your usual local-policy settings here, as it will have
> negative effect").
>
> Which effects this community has - or not - is up to the receiving network.
>
> Gert Doering
> -- NetMaster
> --
> have you enabled IPv6 on something today...?
>
> SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael
> Emmer
> 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
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Working Group Adoption Call: draft-wilhelm-grow-anycast-community (Ends 22/Nov/2022)

[Gert Doering]

Hi,

On Sun, Nov 26, 2023 at 04:02:31PM +0100, Robert Raszuk wrote:
> Effectively to make use of this community (provided all good marking and
> good will of transits) you need to have some hooks in your local BGP
> implementations to allow for multipath selection when at least one received
> prefix is marked with such community.

The intention is not to instanciate magic handling of such in the receiving
routers - it's to permit an informed choice by the receiving operator
(like, "do not force your usual local-policy settings here, as it will have
negative effect").

Which effects this community has - or not - is up to the receiving network.

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

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
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
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Working Group Adoption Call: draft-wilhelm-grow-anycast-community (Ends 22/Nov/2022)

[Robert Raszuk]

Hi,

So I reread this discussion and have one more question .. .

Abstract says:




*To allow operators to take well informed decisions on which prefixesare
carrying anycast traffic this document proposes a well-known BGPcommunity
to denote this property.*

Cool - but how is this decision going to be instantiated in the router ?

Effectively to make use of this community (provided all good marking and
good will of transits) you need to have some hooks in your local BGP
implementations to allow for multipath selection when at least one received
prefix is marked with such community.

Of course if someone already enables ebgp or ibgp multipath for all
prefixes there is nothing to do here, but if you are generally just
selecting a single best path and doing hot potato routing I am missing how
any operator will  (or can) actually use this community effectively.

Cheers,
Robert


On Sun, Nov 26, 2023 at 2:50 PM Job Snijders  wrote:

> Dear Maximilian,
>
> On Sun, Nov 26, 2023 at 02:45:58PM +0100, Maximilian Wilhelm wrote:
> > Anno domini 2023 Maximilian Wilhelm scripsit:
> >
> > [...]
> > > Some time has past and I don't see any new comments, neither here nor
> > > to us authors.
> > >
> > > Hence I'd like to ask the chairs to start the WG Last Call.
> >
> > I believe this didn't happen so far, or did I miss it? :)
> >
> > So I'd like to ask to start the WG Last Call, or, if there is no
> > interest in getting this into an RFC, to call that out. :)
>
> Thanks for the poke
>
> Looking back I see two messages with comments that probably need
> addressing:
>
> https://mailarchive.ietf.org/arch/msg/grow/5iJ-QpjcPXOwIGhuOQMKn_FYQQc/
> https://mailarchive.ietf.org/arch/msg/grow/cdlMR2A0-gHqDwIf-UNkBvqVixw/
>
> Kind regards,
>
> Job
>
> ___
> 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] Working Group Adoption Call: draft-wilhelm-grow-anycast-community (Ends 22/Nov/2022)

[Job Snijders]

Dear Maximilian,

On Sun, Nov 26, 2023 at 02:45:58PM +0100, Maximilian Wilhelm wrote:
> Anno domini 2023 Maximilian Wilhelm scripsit:
> 
> [...]
> > Some time has past and I don't see any new comments, neither here nor
> > to us authors.
> >
> > Hence I'd like to ask the chairs to start the WG Last Call.
> 
> I believe this didn't happen so far, or did I miss it? :)
> 
> So I'd like to ask to start the WG Last Call, or, if there is no
> interest in getting this into an RFC, to call that out. :)

Thanks for the poke

Looking back I see two messages with comments that probably need
addressing:

https://mailarchive.ietf.org/arch/msg/grow/5iJ-QpjcPXOwIGhuOQMKn_FYQQc/
https://mailarchive.ietf.org/arch/msg/grow/cdlMR2A0-gHqDwIf-UNkBvqVixw/

Kind regards,

Job

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

Re: [GROW] Working Group Adoption Call: draft-wilhelm-grow-anycast-community (Ends 22/Nov/2022)

[Maximilian Wilhelm]

Hi folks,

Anno domini 2023 Maximilian Wilhelm scripsit:

[...]
> Some time has past and I don't see any new comments, neither here nor
> to us authors.
>
> Hence I'd like to ask the chairs to start the WG Last Call.

I believe this didn't happen so far, or did I miss it? :)

So I'd like to ask to start the WG Last Call, or, if there is no
interest in getting this into an RFC, to call that out. :)

Cheers and kind regards,
Max

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

Re: [GROW] Working Group Adoption Call: draft-wilhelm-grow-anycast-community (Ends 22/Nov/2022)

[Kevin Wallace]

Hi Max and folks,

On Jun 21, 2023, at 12:53 PM, Maximilian Wilhelm  wrote:
> Some time has past and I don't see any new comments, neither here nor
> to us authors.

Job shared this on IRC and asked me to send feedback here.

It seems that networks have little incentive to tag routes accurately, and 
actually have perverse incentive to tag them inaccurately if they desire 
hot-potato behavior from peers that would otherwise withhold it.  If this were 
adopted, I know I'd be tempted to tag my unicast prefixes with it.

That doesn't destroy the utility of the signal, but it changes its meaning to 
no longer be about anycast vs unicast.  Should this be called "hot potato 
preference" or something along those lines instead of "anycast"?

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

Re: [GROW] Working Group Adoption Call: draft-wilhelm-grow-anycast-community (Ends 22/Nov/2022)

[Alarig Le Lay]

Hello,

I have some concerns about the RFC:
1. I’m not sure that it will be used to influence routing of anycast
   prefixes, but rather of prefixes that one wants to be treated as
   hot-potato
2. I don’t specially trust operators to take better routing decisions if
   the community is present; it could very easily be worst (eg. going
   via a congestioned link only because the AS path is shorter)

The point about IXP RSes is valid tho, and having a community to avoid
remote peers could be a nice idea. But it has nothing to do with anycast
by its own.

Regards,
-- 
Alarig

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

Re: [GROW] Working Group Adoption Call: draft-wilhelm-grow-anycast-community (Ends 22/Nov/2022)

[Maximilian Wilhelm]

Hi folks,

Anno domini 2023 Maximilian Wilhelm scripsit:

> Anno domini 2023 Job Snijders scripsit:
> > The next step in this process is "Working Group Last Call", a period of
> > time in which members of this working group can comment on the
> > internet-draft's comments (before its send onwards to wider review).
> > 
> > Before we do that, I have some remarks:
> > 
> > Section 3.2 "Accepting and honoring the ANYCAST community" ... it might
> > not be clear to a novice reader what exactly 'accepting and honoring'
> > means.
> > 
> > Also in section 3.2: "if it is received by a network that is not using it"
> > what does "using it" mean exactly?
> 
> I agree, that can be worded better.  I've updated the draft to address
> both comments.
> 
> Diff: 
> https://author-tools.ietf.org/iddiff?url1=draft-ietf-grow-anycast-community-00=draft-ietf-grow-anycast-community-02=--html

Some time has past and I don't see any new comments, neither here nor
to us authors.

Hence I'd like to ask the chairs to start the WG Last Call.

Thanks and kind regards,
Max

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

Re: [GROW] Working Group Adoption Call: draft-wilhelm-grow-anycast-community (Ends 22/Nov/2022)

[Maximilian Wilhelm]

Hi,

Anno domini 2023 Job Snijders scripsit:

> On Sat, May 27, 2023 at 08:43:59PM +0200, Maximilian Wilhelm wrote:
> > It looks like the expiration date of this draft is coming up.
> > 
> > I've seen quite some support for this here so it was adopted as a WG
> > document. Since then there wasn't much chatter about it and the
> > comments which came up have been addressed. Which leads me to the
> > questions: What needs to happen so this can become an RFC? :)
> 
> The next step in this process is "Working Group Last Call", a period of
> time in which members of this working group can comment on the
> internet-draft's comments (before its send onwards to wider review).
> 
> Before we do that, I have some remarks:
> 
> Section 3.2 "Accepting and honoring the ANYCAST community" ... it might
> not be clear to a novice reader what exactly 'accepting and honoring'
> means.
> 
> Also in section 3.2: "if it is received by a network that is not using it"
> what does "using it" mean exactly?

I agree, that can be worded better.  I've updated the draft to address
both comments.

Diff: 
https://author-tools.ietf.org/iddiff?url1=draft-ietf-grow-anycast-community-00=draft-ietf-grow-anycast-community-02=--html

Thanks and kind regards,
Max

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

Re: [GROW] Working Group Adoption Call: draft-wilhelm-grow-anycast-community (Ends 22/Nov/2022)

[Job Snijders]

On Sat, May 27, 2023 at 08:43:59PM +0200, Maximilian Wilhelm wrote:
> Anno domini 2022 Job Snijders scripsit:
> 
> > Thank you for your feedback! There was good support to adopt this
> > internet-draft and continue work on it as a working group document.
> > 
> > Authors, please name the internet-draft 
> > "draft-ietf-grow-anycast-community-00"
> > and submit it to https://datatracker.ietf.org/submit/
> 
> It looks like the expiration date of this draft is coming up.
> 
> I've seen quite some support for this here so it was adopted as a WG
> document. Since then there wasn't much chatter about it and the
> comments which came up have been addressed. Which leads me to the
> questions: What needs to happen so this can become an RFC? :)

The next step in this process is "Working Group Last Call", a period of
time in which members of this working group can comment on the
internet-draft's comments (before its send onwards to wider review).

Before we do that, I have some remarks:

Section 3.2 "Accepting and honoring the ANYCAST community" ... it might
not be clear to a novice reader what exactly 'accepting and honoring'
means.

Also in section 3.2: "if it is received by a network that is not using it"
what does "using it" mean exactly?

Kind regards,

Job

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

Re: [GROW] Working Group Adoption Call: draft-wilhelm-grow-anycast-community (Ends 22/Nov/2022)

[Maximilian Wilhelm]

Dear all,

Anno domini 2022 Job Snijders scripsit:

> Thank you for your feedback! There was good support to adopt this
> internet-draft and continue work on it as a working group document.
> 
> Authors, please name the internet-draft "draft-ietf-grow-anycast-community-00"
> and submit it to https://datatracker.ietf.org/submit/

It looks like the expiration date of this draft is coming up.

I've seen quite some support for this here so it was adopted as a WG
document. Since then there wasn't much chatter about it and the
comments which came up have been addressed. Which leads me to the
questions: What needs to happen so this can become an RFC? :)

Cheers,
Max

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

Re: [GROW] Working Group Adoption Call: draft-wilhelm-grow-anycast-community (Ends 22/Nov/2022)

[Maximilian Wilhelm]

Dear Job,

On 11/26/22 23:25, Job Snijders wrote:

Dear Maximilian,

On Sat, Nov 26, 2022 at 11:17:06PM +0100, Maximilian Wilhelm wrote:

thanks for the support!

I re-uploaded the draft with the updated name.

Chairs, I heard there is an option to ask for an early allocation for
a community? I have to admit that I'm not deeply familar with the
process here,


RFC 7120 section 2 outlines the conditions for IANA Early Allocation
https://www.rfc-editor.org/rfc/rfc7120.html

I'm not entirely sure the semantics, processing, and other rules for
ANYCAST are entirely clear yet (condition B), which in turn impacts
condition C. I'm open to hear the case though! What would be the
motivation to allocate a value prior to RFC publication?


Fair point. I'm in no particular rush, I guess my goal here would only 
be to commit the sin you mentioned :)



I have however a favorite value in mind which I would love to see for
this in the hope this ID one day becomes an RFC :)


Oh dear... the deadly sin of number vanity :)
What's your favorite number value?


I'd love to see 65535: used for this which maps to 0x0457 if I'm 
not mistaken, which should fall into the "First come first serve" range 
of 
https://www.iana.org/assignments/bgp-well-known-communities/bgp-well-known-communities.xhtml


Kind regards,
Max

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

Re: [GROW] Working Group Adoption Call: draft-wilhelm-grow-anycast-community (Ends 22/Nov/2022)

[Job Snijders]

Dear Maximilian,

On Sat, Nov 26, 2022 at 11:17:06PM +0100, Maximilian Wilhelm wrote:
> thanks for the support!
> 
> I re-uploaded the draft with the updated name.
> 
> Chairs, I heard there is an option to ask for an early allocation for
> a community? I have to admit that I'm not deeply familar with the
> process here, 

RFC 7120 section 2 outlines the conditions for IANA Early Allocation
https://www.rfc-editor.org/rfc/rfc7120.html

I'm not entirely sure the semantics, processing, and other rules for
ANYCAST are entirely clear yet (condition B), which in turn impacts
condition C. I'm open to hear the case though! What would be the
motivation to allocate a value prior to RFC publication?

> I have however a favorite value in mind which I would love to see for
> this in the hope this ID one day becomes an RFC :)

Oh dear... the deadly sin of number vanity :)
What's your favorite number value?

Kind regards,

Job

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

Re: [GROW] Working Group Adoption Call: draft-wilhelm-grow-anycast-community (Ends 22/Nov/2022)

[Maximilian Wilhelm]

Dear all,

thanks for the support!

I re-uploaded the draft with the updated name.

Chairs, I heard there is an option to ask for an early allocation for a 
community? I have to admit that I'm not deeply familar with the process 
here, I have however a favorite value in mind which I would love to see 
for this in the hope this ID one day becomes an RFC :)


Kind regards,
Max

On 11/26/22 21:59, Job Snijders wrote:

Dear all,

Thank you for your feedback! There was good support to adopt this
internet-draft and continue work on it as a working group document.

Authors, please name the internet-draft "draft-ietf-grow-anycast-community-00"
and submit it to https://datatracker.ietf.org/submit/

Kind regards,

Job

GROW co-chair

On Sat, Nov 05, 2022 at 03:48:16PM +0100, Job Snijders wrote:

Dear GROW,

The authors of draft-wilhelm-grow-anycast-community asked whether this
working group could consider adoption of the internet-draft.

This message is a request to the group for feedback on whether this
internet-draft should be adopted.

Title: A well-known BGP community to denote prefixes used for Anycast
Abstract:
In theory routing decisions on the Internet and by extension within
ISP networks should always use hot-potato routing to reach any given
destination.  In reality operators sometimes choose to not use the
hot-potato paths to forward traffic due to a variety of reasons,
mostly motivated by traffic engineering considerations.  For prefixes
carrying anycast traffic in virtually all situations it is advisable
to stick to the hot-potato principle.  As operators mostly don't know
which prefixes are carrying unicast or anycast traffic, they can't
differentiate between them in their routing policies.

To allow operators to take well informed decisions on which prefixes
are carrying anycast traffic this document proposes a well-known BGP
community to denote this property.

The Internet-Draft can be found here: 
https://datatracker.ietf.org/doc/draft-wilhelm-grow-anycast-community/

Please share with the mailing list if you are think this work should be
adopted by GROW, willing to review and/or otherwise contribute to this
draft!

WG Adoption call ends November 22th, 2022.

Kind regards,

Job / Chris


___
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] Working Group Adoption Call: draft-wilhelm-grow-anycast-community (Ends 22/Nov/2022)

[Job Snijders]

Dear all,

Thank you for your feedback! There was good support to adopt this
internet-draft and continue work on it as a working group document.

Authors, please name the internet-draft "draft-ietf-grow-anycast-community-00"
and submit it to https://datatracker.ietf.org/submit/

Kind regards,

Job

GROW co-chair

On Sat, Nov 05, 2022 at 03:48:16PM +0100, Job Snijders wrote:
> Dear GROW,
> 
> The authors of draft-wilhelm-grow-anycast-community asked whether this
> working group could consider adoption of the internet-draft.
> 
> This message is a request to the group for feedback on whether this
> internet-draft should be adopted.
> 
> Title: A well-known BGP community to denote prefixes used for Anycast
> Abstract: 
>In theory routing decisions on the Internet and by extension within
>ISP networks should always use hot-potato routing to reach any given
>destination.  In reality operators sometimes choose to not use the
>hot-potato paths to forward traffic due to a variety of reasons,
>mostly motivated by traffic engineering considerations.  For prefixes
>carrying anycast traffic in virtually all situations it is advisable
>to stick to the hot-potato principle.  As operators mostly don't know
>which prefixes are carrying unicast or anycast traffic, they can't
>differentiate between them in their routing policies.
> 
>To allow operators to take well informed decisions on which prefixes
>are carrying anycast traffic this document proposes a well-known BGP
>community to denote this property.
> 
> The Internet-Draft can be found here: 
> https://datatracker.ietf.org/doc/draft-wilhelm-grow-anycast-community/
> 
> Please share with the mailing list if you are think this work should be
> adopted by GROW, willing to review and/or otherwise contribute to this
> draft!
> 
> WG Adoption call ends November 22th, 2022.
> 
> Kind regards,
> 
> Job / Chris

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

Re: [GROW] Working Group Adoption Call: draft-wilhelm-grow-anycast-community (Ends 22/Nov/2022)

[Brian Dickson]

On Sat, Nov 5, 2022 at 7:48 AM Job Snijders 
wrote:

> Dear GROW,
>
> The authors of draft-wilhelm-grow-anycast-community asked whether this
> working group could consider adoption of the internet-draft.
>
> This message is a request to the group for feedback on whether this
> internet-draft should be adopted.
>
> Title: A well-known BGP community to denote prefixes used for Anycast
> Abstract:
>In theory routing decisions on the Internet and by extension within
>ISP networks should always use hot-potato routing to reach any given
>destination.  In reality operators sometimes choose to not use the
>hot-potato paths to forward traffic due to a variety of reasons,
>mostly motivated by traffic engineering considerations.  For prefixes
>carrying anycast traffic in virtually all situations it is advisable
>to stick to the hot-potato principle.  As operators mostly don't know
>which prefixes are carrying unicast or anycast traffic, they can't
>differentiate between them in their routing policies.
>
>To allow operators to take well informed decisions on which prefixes
>are carrying anycast traffic this document proposes a well-known BGP
>community to denote this property.
>
> The Internet-Draft can be found here:
> https://datatracker.ietf.org/doc/draft-wilhelm-grow-anycast-community/
>
> Please share with the mailing list if you are think this work should be
> adopted by GROW, willing to review and/or otherwise contribute to this
> draft!
>
>
I have read the draft.
I support adoption by GROW.
I am willing to review and/or contribute.
We (GoDaddy DNS) will in all likelihood implement tagging announcements
once the community value has been assigned.

Brian Dickson


> WG Adoption call ends November 22th, 2022.
>
> Kind regards,
>
> Job / Chris
>
> ___
> 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] Working Group Adoption Call: draft-wilhelm-grow-anycast-community (Ends 22/Nov/2022)

[heasley]

I support adoption.

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

Re: [GROW] Working Group Adoption Call: draft-wilhelm-grow-anycast-community (Ends 22/Nov/2022)

[Randy Bush]

read.  like.  support adoption.

randy

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

Re: [GROW] Working Group Adoption Call: draft-wilhelm-grow-anycast-community (Ends 22/Nov/2022)

[David Farmer]

+1 to all the points below.

On Sat, Nov 5, 2022 at 10:29 Robert Raszuk  wrote:

> Support.
>
> I was hesitant however below Gert's point made it obvious for me that this
> should be
> adopted and published:
>
>
>
>
> *I find this a useful feature, being able to look at a prefix and seeif
> the originating AS intended this to be anycast or not, and a
> standardcommunity makes this easier than having to look up per-AS
> documentation.*
>
> Essentially no harm, only (potential) benefit.
>
> Thx,
> R.
>
>
>
> On Sat, Nov 5, 2022 at 3:52 PM Gert Doering  wrote:
>
>> Hi,
>>
>> On Sat, Nov 05, 2022 at 03:48:16PM +0100, Job Snijders wrote:
>> > The authors of draft-wilhelm-grow-anycast-community asked whether this
>> > working group could consider adoption of the internet-draft.
>>
>> Support adoption.
>>
>> I find this a useful feature, being able to look at a prefix and see
>> if the originating AS intended this to be anycast or not, and a standard
>> community makes this easier than having to look up per-AS documentation.
>>
>> (Our routing policy is simple enough that I might not actually have our
>> routers *act* on it, but it's still useful when looking at BGP
>> announcements
>> when troubleshooting)
>>
>> Gert Doering
>> -- NetMaster
>> --
>> have you enabled IPv6 on something today...?
>>
>> SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael
>> Emmer
>> Joseph-Dollinger-Bogen 14
>> 
>>   Aufsichtsratsvors.: 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
>> https://www.ietf.org/mailman/listinfo/grow
>>
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
>
-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Working Group Adoption Call: draft-wilhelm-grow-anycast-community (Ends 22/Nov/2022)

[Robert Raszuk]

Support.

I was hesitant however below Gert's point made it obvious for me that this
should be
adopted and published:




*I find this a useful feature, being able to look at a prefix and seeif the
originating AS intended this to be anycast or not, and a standardcommunity
makes this easier than having to look up per-AS documentation.*

Essentially no harm, only (potential) benefit.

Thx,
R.



On Sat, Nov 5, 2022 at 3:52 PM Gert Doering  wrote:

> Hi,
>
> On Sat, Nov 05, 2022 at 03:48:16PM +0100, Job Snijders wrote:
> > The authors of draft-wilhelm-grow-anycast-community asked whether this
> > working group could consider adoption of the internet-draft.
>
> Support adoption.
>
> I find this a useful feature, being able to look at a prefix and see
> if the originating AS intended this to be anycast or not, and a standard
> community makes this easier than having to look up per-AS documentation.
>
> (Our routing policy is simple enough that I might not actually have our
> routers *act* on it, but it's still useful when looking at BGP
> announcements
> when troubleshooting)
>
> Gert Doering
> -- NetMaster
> --
> have you enabled IPv6 on something today...?
>
> SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael
> Emmer
> 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
> https://www.ietf.org/mailman/listinfo/grow
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Working Group Adoption Call: draft-wilhelm-grow-anycast-community (Ends 22/Nov/2022)

[Gert Doering]

Hi,

On Sat, Nov 05, 2022 at 03:48:16PM +0100, Job Snijders wrote:
> The authors of draft-wilhelm-grow-anycast-community asked whether this
> working group could consider adoption of the internet-draft.

Support adoption.

I find this a useful feature, being able to look at a prefix and see
if the originating AS intended this to be anycast or not, and a standard
community makes this easier than having to look up per-AS documentation.

(Our routing policy is simple enough that I might not actually have our
routers *act* on it, but it's still useful when looking at BGP announcements
when troubleshooting)

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

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
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
https://www.ietf.org/mailman/listinfo/grow

[GROW] Working Group Adoption Call: draft-wilhelm-grow-anycast-community (Ends 22/Nov/2022)

[Job Snijders]

Dear GROW,

The authors of draft-wilhelm-grow-anycast-community asked whether this
working group could consider adoption of the internet-draft.

This message is a request to the group for feedback on whether this
internet-draft should be adopted.

Title: A well-known BGP community to denote prefixes used for Anycast
Abstract: 
   In theory routing decisions on the Internet and by extension within
   ISP networks should always use hot-potato routing to reach any given
   destination.  In reality operators sometimes choose to not use the
   hot-potato paths to forward traffic due to a variety of reasons,
   mostly motivated by traffic engineering considerations.  For prefixes
   carrying anycast traffic in virtually all situations it is advisable
   to stick to the hot-potato principle.  As operators mostly don't know
   which prefixes are carrying unicast or anycast traffic, they can't
   differentiate between them in their routing policies.

   To allow operators to take well informed decisions on which prefixes
   are carrying anycast traffic this document proposes a well-known BGP
   community to denote this property.

The Internet-Draft can be found here: 
https://datatracker.ietf.org/doc/draft-wilhelm-grow-anycast-community/

Please share with the mailing list if you are think this work should be
adopted by GROW, willing to review and/or otherwise contribute to this
draft!

WG Adoption call ends November 22th, 2022.

Kind regards,

Job / Chris

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