Re: [GROW] I-D Action: draft-ietf-grow-nrtm-v4-03.txt
Hello all, This version has a number of minor improvements/clarifications that we encountered while implementing: - Explicitly specified Update Notification File signature format - Specified that RPSL primary keys are case insensitive - Clarification in the key rotation process - A fixed timestamp in an example Update Notification File - Several text improvements While still having rough edges, there are now implementations in the RIPE database (mirror server only) and IRRD (mirror client only, not released yet) that are interoperable. Key rotation is still to be implemented/tested. As always, we welcome comments. Sasha On 26 Nov 2023, at 22:20, internet-dra...@ietf.org wrote: Internet-Draft draft-ietf-grow-nrtm-v4-03.txt is now available. It is a work item of the Global Routing Operations (GROW) WG of the IETF. Title: Near Real Time Mirroring (NRTM) version 4 Authors: Sasha Romijn Job Snijders Edward Shryane Stavros Konstantaras Name:draft-ietf-grow-nrtm-v4-03.txt Pages: 21 Dates: 2023-11-26 Abstract: This document specifies a one-way synchronization protocol for Internet Routing Registry (IRR) records. The protocol allows instances of IRR database servers to mirror IRR records, specified in the Routing Policy Specification Language (RPSL), between each other. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-grow-nrtm-v4/ There is also an HTMLized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-grow-nrtm-v4-03 A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-grow-nrtm-v4-03 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts ___ 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] I-D Action: draft-ietf-grow-nrtm-v4-03.txt
Internet-Draft draft-ietf-grow-nrtm-v4-03.txt is now available. It is a work item of the Global Routing Operations (GROW) WG of the IETF. Title: Near Real Time Mirroring (NRTM) version 4 Authors: Sasha Romijn Job Snijders Edward Shryane Stavros Konstantaras Name:draft-ietf-grow-nrtm-v4-03.txt Pages: 21 Dates: 2023-11-26 Abstract: This document specifies a one-way synchronization protocol for Internet Routing Registry (IRR) records. The protocol allows instances of IRR database servers to mirror IRR records, specified in the Routing Policy Specification Language (RPSL), between each other. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-grow-nrtm-v4/ There is also an HTMLized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-grow-nrtm-v4-03 A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-grow-nrtm-v4-03 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts ___ 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)
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&E) community, it is common
> to local preference routes from other R&E 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)
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&E) community, it is common to local preference routes from other R&E 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)
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)
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)
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)
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)
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
[GROW] I-D Action: draft-ietf-grow-anycast-community-03.txt
Internet-Draft draft-ietf-grow-anycast-community-03.txt is now available. It is a work item of the Global Routing Operations (GROW) WG of the IETF. Title: A well-known BGP community to denote prefixes used for Anycast Authors: Maximilian Wilhelm Fredy Kuenzler Name:draft-ietf-grow-anycast-community-03.txt Pages: 6 Dates: 2023-11-26 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 IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-grow-anycast-community/ There is also an HTMLized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-grow-anycast-community-03 A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-grow-anycast-community-03 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
