[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

[Robert Raszuk]

Indeed carving out some chunks of ASN space is a hack.

But why not simply request a new attribute value and do not reserve
anything ? This time do it properly and encode the structure in it.

Thx,
Robert

On Sat, Jun 8, 2024 at 6:41 PM Jeffrey Haas  wrote:

>
>
> > On Jun 8, 2024, at 11:54 AM, Sriram, Kotikalapudi (Fed) <
> kotikalapudi.sri...@nist.gov> wrote:
> >
> > Some of us may remember this (including Sue and Jeff).  Jakob Heitz, I,
> and others have proposed/presented (in the IDR WG) the idea of a range of
> IANA-registered 4-octet ASN values for the Global Admin field to classify
> BGP Well Known Large Communities (WKLC).
> > See: https://datatracker.ietf.org/doc/draft-heitz-idr-wklc/  [1]
> >
> > The above draft was motivated in part by the following GROW WG draft's
> request plus possible other use cases for WKLC:
> >
> https://datatracker.ietf.org/doc/draft-ietf-grow-route-leak-detection-mitigation/
> [2]
> >
> > Our idea was critiqued for requesting 64M 4-octet ASN values to be set
> aside by IANA for WKLC. That is only 64 million out of the 4 Billion (a
> fraction 0.015) 4-octet ASNs. This can be reduced easily to 256K out of the
> 4 Billion (a fraction 0.6) if that is acceptable. There would be 9
> octets available in the WKLC for the data part. The 256K number can be
> further reduced to 1K if desired (with 8 octets available in the WKLC for
> the data part).
> >
> > Details can be found in the above cited draft [1].  We can discuss
> further the possibilities if this approach gets some traction.  Thanks.
>
> Please let the proposal stay dead.  Carving up the globally visible BGP AS
> space with too many "this is special" numbers is a bad idea.
>
>
>
> -- Jeff
>
> ___
> GROW mailing list -- grow@ietf.org
> To unsubscribe send an email to grow-le...@ietf.org
>
___
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

[Robert Raszuk]

> Nitpick: one can only encode a single IPv6 address in an 5701 attribute,
> not an IPv6 prefix.
>

Hmmm you have 18 octets to play with ... I can think of at least two easy
ways to encode IPv6 prefix there to be used as policy parameter.

Even with one octet still being free to mean special policy function.

- - -

Of course as indicated in RFC7948 in number of cases ORF could be used too
in place of community based policies.

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

[GROW]Re: well known large communities

[Robert Raszuk]

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: I-D Action: draft-ietf-grow-ixp-ext-comms-00.txt

[Robert Raszuk]

Well I was going a little bit further than just examples included in
RFC8195 ..

I think it would be helpful to have IANA maintain a registry for most
important IXP community based signalling.

Analogy to
https://www.iana.org/assignments/bgp-well-known-communities/bgp-well-known-communities.xhtml

Thx,
R.

On Sat, Jun 8, 2024 at 12:30 AM David Farmer  wrote:

> Doesn't RFC 8195 already cover much of that?
>
> https://datatracker.ietf.org/doc/rfc8195/
>
> Thanks
>
> On Fri, Jun 7, 2024 at 5:04 PM 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.
>>
>> Regards,
>> Robert
>>
>>
>> On Fri, Jun 7, 2024 at 11:35 PM Job Snijders  wrote:
>>
>>> It seems out of scope to me
>>>
>>> On Fri, 7 Jun 2024 at 23:30, Robert Raszuk  wrote:
>>>
>>>> Jeff,
>>>>
>>>> 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.
>>>>
>>>> Thx,
>>>> R.
>>>>
>>>> On Fri, Jun 7, 2024 at 11:23 PM Jeffrey Haas  wrote:
>>>>
>>>>> There is no such thing as a well known large bgp community.
>>>>>
>>>>>
>>>>> Jeff
>>>>>
>>>>> On Jun 7, 2024, at 15:51, Robert Raszuk  wrote:
>>>>>
>>>>> 
>>>>> Hi Job/WG,
>>>>>
>>>>> Reading the document I have a feeling/suggestion that perhaps this is
>>>>> a very good time now to define few IXP focused well known Large 
>>>>> Communities
>>>>> such that most often signalled policies between RS and their clients are
>>>>> well defined and not random among IXPs.
>>>>>
>>>>> That may also in fact encourage faster migration to LCs from Extended
>>>>> Commuities.
>>>>>
>>>>> Thx a lot,
>>>>> Robert
>>>>>
>>>>>
>>>>> On Fri, Jun 7, 2024 at 9:39 PM Job Snijders >>>> 40fastly@dmarc.ietf.org> wrote:
>>>>>
>>>>>> Thanks David, we will incorporate this in the next revision
>>>>>>
>>>>>> On Fri, 7 Jun 2024 at 21:15, David Farmer >>>>> 40umn@dmarc.ietf.org> wrote:
>>>>>>
>>>>>>> I reviewed the draft;
>>>>>>>
>>>>>>> The Abstract and Introduction says, "It includes guidance for
>>>>>>> both the Internet Service Provider side peering with Route Servers and 
>>>>>>> IXPs
>>>>>>> operating Route Servers."
>>>>>>>
>>>>>>> However, the document no longer calls for any direct actions by
>>>>>>> ISPs. Obviously, the actions recommended for IXPs will impact the ISPs
>>>>>>> using IXPs. However, the statements above imply direct actions by ISPs 
>>>>>>> in
>>>>>>> addition to IXPs, not indirect impacts on ISPs from IXP actions.
>>>>>>>
>>>>>>> You should probably rephrase the above statements to refer to
>>>>>>> indirect impacts on ISPs unless you expect ISPs to take other direct
>>>>>>> actions, and if you do, those other actions need to be more clearly 
>>>>>>> stated.
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> On Wed, Jun 5, 2024 at 11:09 AM  wrote:
>>>>>>>
>>>>>>>> Internet-Draft draft-ietf-grow-ixp-ext-comms-00.txt is now
>>>>>>>> available. It is a
>>>>>>>> work item of the Global Routing Operations (GROW) WG of the IETF.
>>>>>>>>
>>>>>>>>Title:   Recommendation to avoid use of BGP Extended Communities
>>>>>>>> at Internet Exchange Route Server

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

[Robert Raszuk]

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.

Regards,
Robert


On Fri, Jun 7, 2024 at 11:35 PM Job Snijders  wrote:

> It seems out of scope to me
>
> On Fri, 7 Jun 2024 at 23:30, Robert Raszuk  wrote:
>
>> Jeff,
>>
>> 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.
>>
>> Thx,
>> R.
>>
>> On Fri, Jun 7, 2024 at 11:23 PM Jeffrey Haas  wrote:
>>
>>> There is no such thing as a well known large bgp community.
>>>
>>>
>>> Jeff
>>>
>>> On Jun 7, 2024, at 15:51, Robert Raszuk  wrote:
>>>
>>> 
>>> Hi Job/WG,
>>>
>>> Reading the document I have a feeling/suggestion that perhaps this is a
>>> very good time now to define few IXP focused well known Large Communities
>>> such that most often signalled policies between RS and their clients are
>>> well defined and not random among IXPs.
>>>
>>> That may also in fact encourage faster migration to LCs from Extended
>>> Commuities.
>>>
>>> Thx a lot,
>>> Robert
>>>
>>>
>>> On Fri, Jun 7, 2024 at 9:39 PM Job Snijders >> 40fastly@dmarc.ietf.org> wrote:
>>>
>>>> Thanks David, we will incorporate this in the next revision
>>>>
>>>> On Fri, 7 Jun 2024 at 21:15, David Farmer >>> 40umn@dmarc.ietf.org> wrote:
>>>>
>>>>> I reviewed the draft;
>>>>>
>>>>> The Abstract and Introduction says, "It includes guidance for both the
>>>>> Internet Service Provider side peering with Route Servers and IXPs
>>>>> operating Route Servers."
>>>>>
>>>>> However, the document no longer calls for any direct actions by ISPs.
>>>>> Obviously, the actions recommended for IXPs will impact the ISPs using
>>>>> IXPs. However, the statements above imply direct actions by ISPs in
>>>>> addition to IXPs, not indirect impacts on ISPs from IXP actions.
>>>>>
>>>>> You should probably rephrase the above statements to refer to indirect
>>>>> impacts on ISPs unless you expect ISPs to take other direct actions, and 
>>>>> if
>>>>> you do, those other actions need to be more clearly stated.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> On Wed, Jun 5, 2024 at 11:09 AM  wrote:
>>>>>
>>>>>> Internet-Draft draft-ietf-grow-ixp-ext-comms-00.txt is now available.
>>>>>> It is a
>>>>>> work item of the Global Routing Operations (GROW) WG of the IETF.
>>>>>>
>>>>>>Title:   Recommendation to avoid use of BGP Extended Communities
>>>>>> at Internet Exchange Route Servers
>>>>>>Authors: Job Snijders
>>>>>> Stavros Konstantaras
>>>>>> Mo Shivji
>>>>>>Name:draft-ietf-grow-ixp-ext-comms-00.txt
>>>>>>Pages:   5
>>>>>>Dates:   2024-06-04
>>>>>>
>>>>>> Abstract:
>>>>>>
>>>>>>This document outlines a recommendation to the Internet operational
>>>>>>community to avoid the use of BGP Extended Communities at Internet
>>>>>>Exchange Point (IXP) Route Servers.  It includes guidance for both
>>>>>>the Internet Service Provider side peering with Route Servers and
>>>>>>IXPs operating Route Servers.  This recommendation aims to help the
>>>>>>global Internet routing system's performance and help protect Route
>>>>>>Server participants against misconfigurations.
>>>>>>
>>>>>> The IETF datatracker status page for this Internet-Draft is:
>>>>>> https://datatracker.ietf.org/doc/draft-ietf-grow-ixp-ext-comms/
>>>>>>
>>>>>> There is also an HTMLized version available at:
>>>>>> https://datatracker.ietf.or

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

[Robert Raszuk]

Jeff,

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.

Thx,
R.

On Fri, Jun 7, 2024 at 11:23 PM Jeffrey Haas  wrote:

> There is no such thing as a well known large bgp community.
>
>
> Jeff
>
> On Jun 7, 2024, at 15:51, Robert Raszuk  wrote:
>
> 
> Hi Job/WG,
>
> Reading the document I have a feeling/suggestion that perhaps this is a
> very good time now to define few IXP focused well known Large Communities
> such that most often signalled policies between RS and their clients are
> well defined and not random among IXPs.
>
> That may also in fact encourage faster migration to LCs from Extended
> Commuities.
>
> Thx a lot,
> Robert
>
>
> On Fri, Jun 7, 2024 at 9:39 PM Job Snijders  40fastly@dmarc.ietf.org> wrote:
>
>> Thanks David, we will incorporate this in the next revision
>>
>> On Fri, 7 Jun 2024 at 21:15, David Farmer > 40umn@dmarc.ietf.org> wrote:
>>
>>> I reviewed the draft;
>>>
>>> The Abstract and Introduction says, "It includes guidance for both the
>>> Internet Service Provider side peering with Route Servers and IXPs
>>> operating Route Servers."
>>>
>>> However, the document no longer calls for any direct actions by ISPs.
>>> Obviously, the actions recommended for IXPs will impact the ISPs using
>>> IXPs. However, the statements above imply direct actions by ISPs in
>>> addition to IXPs, not indirect impacts on ISPs from IXP actions.
>>>
>>> You should probably rephrase the above statements to refer to indirect
>>> impacts on ISPs unless you expect ISPs to take other direct actions, and if
>>> you do, those other actions need to be more clearly stated.
>>>
>>> Thanks.
>>>
>>> On Wed, Jun 5, 2024 at 11:09 AM  wrote:
>>>
>>>> Internet-Draft draft-ietf-grow-ixp-ext-comms-00.txt is now available.
>>>> It is a
>>>> work item of the Global Routing Operations (GROW) WG of the IETF.
>>>>
>>>>Title:   Recommendation to avoid use of BGP Extended Communities at
>>>> Internet Exchange Route Servers
>>>>Authors: Job Snijders
>>>> Stavros Konstantaras
>>>> Mo Shivji
>>>>Name:draft-ietf-grow-ixp-ext-comms-00.txt
>>>>Pages:   5
>>>>Dates:   2024-06-04
>>>>
>>>> Abstract:
>>>>
>>>>This document outlines a recommendation to the Internet operational
>>>>community to avoid the use of BGP Extended Communities at Internet
>>>>Exchange Point (IXP) Route Servers.  It includes guidance for both
>>>>the Internet Service Provider side peering with Route Servers and
>>>>IXPs operating Route Servers.  This recommendation aims to help the
>>>>global Internet routing system's performance and help protect Route
>>>>Server participants against misconfigurations.
>>>>
>>>> The IETF datatracker status page for this Internet-Draft is:
>>>> https://datatracker.ietf.org/doc/draft-ietf-grow-ixp-ext-comms/
>>>>
>>>> There is also an HTMLized version available at:
>>>> https://datatracker.ietf.org/doc/html/draft-ietf-grow-ixp-ext-comms-00
>>>>
>>>> Internet-Drafts are also available by rsync at:
>>>> rsync.ietf.org::internet-drafts
>>>>
>>>>
>>>> ___
>>>> GROW mailing list -- grow@ietf.org
>>>> To unsubscribe send an email to grow-le...@ietf.org
>>>>
>>>
>>>
>>> --
>>> ===
>>> David Farmer   Email:far...@umn.edu
>>> Networking & Telecommunication Services
>>> Office of Information Technology
>>> University of Minnesota
>>> 2218 University Ave SE
>>> <https://www.google.com/maps/search/2218+University+Ave+SE?entry=gmail=g>
>>>   Phone: 612-626-0815
>>> Minneapolis, MN 55414-3029   Cell: 612-812-9952
>>> ===
>>> ___
>>> GROW mailing list -- grow@ietf.org
>>> To unsubscribe send an email to grow-le...@ietf.org
>>>
>> ___
>> GROW mailing list -- grow@ietf.org
>> To unsubscribe send an email to grow-le...@ietf.org
>>
> ___
> GROW mailing list -- grow@ietf.org
> To unsubscribe send an email to grow-le...@ietf.org
>
>
___
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

[Robert Raszuk]

Hi Job/WG,

Reading the document I have a feeling/suggestion that perhaps this is a
very good time now to define few IXP focused well known Large Communities
such that most often signalled policies between RS and their clients are
well defined and not random among IXPs.

That may also in fact encourage faster migration to LCs from Extended
Commuities.

Thx a lot,
Robert


On Fri, Jun 7, 2024 at 9:39 PM Job Snijders 
wrote:

> Thanks David, we will incorporate this in the next revision
>
> On Fri, 7 Jun 2024 at 21:15, David Farmer 
> wrote:
>
>> I reviewed the draft;
>>
>> The Abstract and Introduction says, "It includes guidance for both the
>> Internet Service Provider side peering with Route Servers and IXPs
>> operating Route Servers."
>>
>> However, the document no longer calls for any direct actions by ISPs.
>> Obviously, the actions recommended for IXPs will impact the ISPs using
>> IXPs. However, the statements above imply direct actions by ISPs in
>> addition to IXPs, not indirect impacts on ISPs from IXP actions.
>>
>> You should probably rephrase the above statements to refer to indirect
>> impacts on ISPs unless you expect ISPs to take other direct actions, and if
>> you do, those other actions need to be more clearly stated.
>>
>> Thanks.
>>
>> On Wed, Jun 5, 2024 at 11:09 AM  wrote:
>>
>>> Internet-Draft draft-ietf-grow-ixp-ext-comms-00.txt is now available. It
>>> is a
>>> work item of the Global Routing Operations (GROW) WG of the IETF.
>>>
>>>Title:   Recommendation to avoid use of BGP Extended Communities at
>>> Internet Exchange Route Servers
>>>Authors: Job Snijders
>>> Stavros Konstantaras
>>> Mo Shivji
>>>Name:draft-ietf-grow-ixp-ext-comms-00.txt
>>>Pages:   5
>>>Dates:   2024-06-04
>>>
>>> Abstract:
>>>
>>>This document outlines a recommendation to the Internet operational
>>>community to avoid the use of BGP Extended Communities at Internet
>>>Exchange Point (IXP) Route Servers.  It includes guidance for both
>>>the Internet Service Provider side peering with Route Servers and
>>>IXPs operating Route Servers.  This recommendation aims to help the
>>>global Internet routing system's performance and help protect Route
>>>Server participants against misconfigurations.
>>>
>>> The IETF datatracker status page for this Internet-Draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-grow-ixp-ext-comms/
>>>
>>> There is also an HTMLized version available at:
>>> https://datatracker.ietf.org/doc/html/draft-ietf-grow-ixp-ext-comms-00
>>>
>>> Internet-Drafts are also available by rsync at:
>>> rsync.ietf.org::internet-drafts
>>>
>>>
>>> ___
>>> GROW mailing list -- grow@ietf.org
>>> To unsubscribe send an email to grow-le...@ietf.org
>>>
>>
>>
>> --
>> ===
>> David Farmer   Email:far...@umn.edu
>> Networking & Telecommunication Services
>> Office of Information Technology
>> University of Minnesota
>> 2218 University Ave SE
>> 
>>   Phone: 612-626-0815
>> Minneapolis, MN 55414-3029   Cell: 612-812-9952
>> ===
>> ___
>> GROW mailing list -- grow@ietf.org
>> To unsubscribe send an email to grow-le...@ietf.org
>>
> ___
> GROW mailing list -- grow@ietf.org
> To unsubscribe send an email to grow-le...@ietf.org
>
___
GROW mailing list -- grow@ietf.org
To unsubscribe send an email to grow-le...@ietf.org

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)

[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)

[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)

[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] [Idr] draft-dong-idr-node-target-ext-comm-05.txt - WG Adoption and IPR call (9/27 to 10/11/2022)

[Robert Raszuk]

/* adding GROW WG as what is being discussed is much more operational topic
then protocol extension */

Hi Jeff,

Minimally, the proposal
> covers an extended community that can be used by policy to say:
>
>   Is my BGP Identifier present in this list of extended communities?
>   If so, I'm interested in it.


I would like to comment on this point. Looks very innocent on the surface.

*Point #1: *

At the target deployment (as per current version of the draft) this means
p2p distribution of information with inherently p2mp protocol. I do not
think this is efficient. This is trying to use BGP as a policy/config push
mechanism only because we do not have a good one yet in IETF.

*Point #2: *

I do have some sympathy (as noted already earlier) that if my extended
community carries a prefix of BGP_ROUTE_IDs this could have potentially
some useful applications**. But not a list of 1:1 mapped BGP_IDs. That list
can get really long and neither processing it at each node now attaching it
to each UPDATE is efficient.

*Point #3: *

As it has been noted already by Gert you can accomplish what you need today
already with just adding a community and applying filtering on it. Of
course modulo filtering on IBGP has its own risks, but those I assume are
well understood.

*Point #4: *

As previously discussed, the draft should discuss handling withdrawals in
all previously described scenarios. Not only in terms of implementation's
ability to do so, but actual protocol correctness (case where UPDATE
carries both MP_REACH and MP_UNREACH and node-target-ext-comm applies to
the former not the latter. Splitting those into different UPDATE messages
may not always be easy.

*Point #5: *

We are starting to get to the point of ingress inline signalling atomic
filtering rules. Nothing wrong with this. But if so I would rather see this
generalized. With that, Wide-Communities provide such ability. Why define
more in encoding which by design is limited in size ? What if next would be
a request to only accept UPDATE by a node which has a client belonging to a
fixed IPv6 prefix ?

Likewise why not enable sender to advertise routes to only a subset of
upstream or peer ASNs ?

We are really walking on the line of protocol inline encoding of policies
vs mgmt driven policy/cfg push (both modulo current RTC like option).

Comments more than welcome (before it's too late :),
Robert
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] RFC7854: EoR

[Robert Raszuk]

Hi Henk,

Ok we are on the same page.

As you can see in this message I exactly described that in monitoring mode
we send the "latest" not all messages:
https://mailarchive.ietf.org/arch/msg/grow/I83kOjy63OCg34e4a9ygdU8XkfI/

I did not even know we call it "compression" :)

But then there is mirroring mode of operation where I think by the spec it
is bit by bit replay. Perhaps as Jeff and later I noted with some vendor
secret sauce filtering.

I agree with Jeff that sending all counters which I suggested would mean
sending all RIB (or rather Adj_Rib_In). But that was not really what I
meant by asking if extension to BMP to carry such churn counters is
something folks would like to see happening.

I was more thinking that we specify such counters + add b_net info and send
it periodically only when it increases above a wise threshold. Not sending
a full table at all.

Sure here we come to really ask if such counters should be sent by BMP or
MGMT/YANG channels. I am a bit split on this. Input welcome !

Best,
Robert





On Fri, Sep 23, 2022 at 5:41 PM Henk Smit  wrote:

> Hi Robert,
>
> > I do not agree that exposing churn is hard.
>
> Maybe not. But not by reporting every incoming BGP packet bit-for-bit to
> the collector.
> You want to keep the "compression". I wouldn't call it compression, I
> would call it "reporting only the latest state".
>
> If you want to look at problems, you have your periodic counters. Those
> should help.
>
> > just keep local churn counter per NLRI
>
> If you want to look at per-NLRI granularity, indeed we could use some more
> information in the message-format.
> If people had been interested in my BMPv4-draft from 2018, we would have
> had proper TLVs for all packet-types.
> And adding a "churn-counter TLV" to monitoring messages would have been
> trivial. And backwards compatible.
> Has:
> https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-tlv
> been implemented yet? Do we have TLVs for Route Monitoring messages?
>
> In any case, I would advocate for keeping the "compression" mechanism in
> BMP. Only report the lastest state.
>
> henk.
>
>
> Op 21-09-2022 22:55 schreef Robert Raszuk :
>
>
> Hey Henk,
>
> The point is that what matters in BGP is reachability and stability //
> Leave aside all the opaque junk BGP carries today //. Reachability you can
> pretty much monitor by vanilla IBGP session say with Add-Paths if you want
> to be fancy. Stability or more importantly filtering the "bad" routes is a
> bit harder.
>
> So I do not agree that exposing churn is hard. You perhaps think about it
> in the atomic model where you have to mirror all received messages. Well
> BMP original idea was about just that. But here we need to decouple
> discussion about sharing Adj_RIB_In from global bRIB.
>
> But here you can just keep local churn counter per NLRI to periodically
> send it in BMP indicating how many paths for a given b_net was received or
> withdrawn since your last BMP update. And it does not need to take much
> space on the sender nor BMP receiver.
>
> I would call it smart-compression where you significantly reduce make the
> bits on the wire or in the ram/ssd yet you do not drop useful information.
>
> Many thx,
> R.
>
> On Wed, Sep 21, 2022 at 3:45 PM Henk Smit  wrote:
>
> Hi Robert,
>
> > But this will hide BGP churn for a given NET to be detectable by BMP
> receiver. Is this a good thing ?
>
> The question is: how expensive is it to report everything bit-for-bit to
> the BMP collector?
> If you want to report everything, you have to store everything.
> Which will require bufferspace. How much? You don't know in advance. Might
> be a lot.
>
> The current way of doing things allows the BMP implementation on a router
> to be pretty efficient.
> When BGP receives routes, you store them in the BRIB. You don't store
> anything special for BMP (expect maybe timestamps, or other meta-data).
> When BMP on a router is going to send BMP updates, it just walks the BRIB,
> and sees which NLRI/routes have not been sent to the collector yet.
> BGP needs only 1 bit of information for that (to be precise: 1 bit per BMP
> session per NLRI/route).
>
> If you want to see all churn, you need loads of buffers.
> And BMP stops being an easy and efficient protocol.
> So yeah, I am greatly in favor of allowing "compression" (aka skipping
> reporting outdated info).
>
> henk.
>
>
> Op 21-09-2022 07:52 schreef Robert Raszuk :
>
>
> Hi Paolo,
>
> A-la: there is multiple updates related to a certain NLRI by when a BMP
> message is to be sent out, let's state-compress (ie. not send 

Re: [GROW] [Idr] RFC7854: EoR

[Robert Raszuk]

Hi,

That's orthogonal to using BMP to carry BGP-LS AF.

Anyway RFC7854 section 4.7 does not seem to limit mirroring to only
BGP_UPDATE Messages. So all messages can be mirrored to BMP collectors
including Type 5.

That means that it should be possible today to use route monitoring and
mirroring together. And filter route mirroring to type 5 (or other bgp
messages) if needed.

Not sure if we need a new extension to explicitly carry route refresh as
part of route monitoring, but if so it would be fine.

Thx,
R.

On Fri, Sep 23, 2022 at 2:35 PM Zhuangshunwan 
wrote:

> Hi Robert,
>
>
>
> According to my knowledge, the current BMP protocol is completely unaware
> of the existence of the BGP Route Refresh message.
>
> This is why the proposal of the BMP client sends an refresh signal to the
> BMP server arise.
>
>
>
> Thanks,
>
> Shunwan
>
>
>
> *From:* Robert Raszuk [mailto:rob...@raszuk.net]
> *Sent:* Friday, September 23, 2022 3:54 PM
> *To:* Tim Evens (tievens) 
> *Cc:* Jeffrey Haas ; Zhuangshunwan <
> zhuangshun...@huawei.com>; grow@ietf.org; Maximilian Wilhelm <
> m...@rfc2324.org>
> *Subject:* Re: [GROW] [Idr] RFC7854: EoR
>
>
>
> Tim,
>
>
>
> Why not just send BGP Message Type 5 verbatim ? Are you saying that BMP is
> not sending this message to BMP receivers when arriving from BGP peers of
> the router ? If so why ?
>
>
>
> Thx,
>
> R.
>
>
>
>
>
> On Fri, Sep 23, 2022 at 2:03 AM Tim Evens (tievens)  40cisco@dmarc.ietf.org> wrote:
>
> When I wrote route-refresh, that was from the router/sender side, not BMP
> receiver sending a route-refresh. BMP is still write-only.
>
>
>
> There are use-cases for re-syncing the RIB to the BMP receiver.  Some of
> the methods today are to clear the peer, request a route-refresh in, or to
> reset the BMP feed. This is a bit intrusive to the router (sender) and BMP
> receiver. Having to go to the router to request a refresh to the BMP
> server, IMO, is still okay.  The problem is that control knobs for refresh
> are at the BGP peer level, not BMP.  For Adj-RIB-In Pre-Policy, it makes
> sense to do that on the peer, but for Post-Policy, Adj-RIB-Out and
> Local-RIB, it doesn’t really make sense.  Having a knob to initiate BMP
> side refresh would be very nice and hopefully less intrusive.
>
>
>
> Regardless of the BMP server needing a refresh, a BMP server does not know
> when someone has requested route-refresh IN at the peer level (maybe it was
> requested for policy change, …) Instead, the BMP receiver, blindly,
> receives a boat load of updates with no awareness that it was a new RIB
> dump or controlled refresh. In this case, it would appear to be churn.
> IMO, there is value in having a message to signal the receiver that a
> refresh is coming, followed by an EoR.  A PEER_UP could be used for this,
> but that is intrusive and misuse of PEER_UP.
>
>
>
> --Tim
>
>
>
> On 9/22/22, 11:03 AM, "Jeffrey Haas"  wrote:
>
>
>
>
>
> > On Sep 21, 2022, at 7:42 AM, Zhuangshunwan  40huawei@dmarc.ietf.org> wrote:
> >
> > Hi Tim and All,
> >
> > I think the idea of a "BMP route refresh" would be appreciated,  it will
> helps keep the information synchronized between the BMP Server and the BMP
> Client.
>
> Would someone clarify what they mean by a bmp route refresh?
>
> The BMP protocol was intentionally designed as write-only.
>
> -- Jeff
>
> ___
> 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] [Idr] RFC7854: EoR

[Robert Raszuk]

> Especially in the BMP for BGP-LS address family

What ? Are you serious ??? BMP for BGP-LS ... It must be a joke !

Best,
R.




On Fri, Sep 23, 2022 at 2:21 PM Zhuangshunwan  wrote:

> +1 for the value in having a message to signal the receiver that a refresh
> is coming, followed by an EoR.
>
> I think Tim's proposal is very useful.
>
> Especially in the BMP for BGP-LS address family, the controller builds a
> real-time topology based on BGP-LS information.
>
> Another scenario is where the controller collects BGP routes through BMP
> and correlates them with traffic information collected by IPFIX to build a
> traffic matrix.
>
>
>
> Thanks,
>
> Shunwan
>
>
>
> *From:* Tim Evens (tievens) [mailto:tiev...@cisco.com]
> *Sent:* Friday, September 23, 2022 8:03 AM
> *To:* Jeffrey Haas ; Zhuangshunwan <
> zhuangshun...@huawei.com>
> *Cc:* Luuk Hendriks ; Maximilian Wilhelm <
> m...@rfc2324.org>; John Scudder ; Paolo Lucente <
> pa...@ntt.net>; grow@ietf.org
> *Subject:* Re: [GROW] [Idr] RFC7854: EoR
>
>
>
> When I wrote route-refresh, that was from the router/sender side, not BMP
> receiver sending a route-refresh. BMP is still write-only.
>
>
>
> There are use-cases for re-syncing the RIB to the BMP receiver.  Some of
> the methods today are to clear the peer, request a route-refresh in, or to
> reset the BMP feed. This is a bit intrusive to the router (sender) and BMP
> receiver. Having to go to the router to request a refresh to the BMP
> server, IMO, is still okay.  The problem is that control knobs for refresh
> are at the BGP peer level, not BMP.  For Adj-RIB-In Pre-Policy, it makes
> sense to do that on the peer, but for Post-Policy, Adj-RIB-Out and
> Local-RIB, it doesn’t really make sense.  Having a knob to initiate BMP
> side refresh would be very nice and hopefully less intrusive.
>
>
>
> Regardless of the BMP server needing a refresh, a BMP server does not know
> when someone has requested route-refresh IN at the peer level (maybe it was
> requested for policy change, …) Instead, the BMP receiver, blindly,
> receives a boat load of updates with no awareness that it was a new RIB
> dump or controlled refresh. In this case, it would appear to be churn.
> IMO, there is value in having a message to signal the receiver that a
> refresh is coming, followed by an EoR.  A PEER_UP could be used for this,
> but that is intrusive and misuse of PEER_UP.
>
>
>
> --Tim
>
>
>
> On 9/22/22, 11:03 AM, "Jeffrey Haas"  wrote:
>
>
>
>
>
> > On Sep 21, 2022, at 7:42 AM, Zhuangshunwan <
> zhuangshunwan=40huawei@dmarc.ietf.org> wrote:
> >
> > Hi Tim and All,
> >
> > I think the idea of a "BMP route refresh" would be appreciated,  it will
> helps keep the information synchronized between the BMP Server and the BMP
> Client.
>
> Would someone clarify what they mean by a bmp route refresh?
>
> The BMP protocol was intentionally designed as write-only.
>
> -- Jeff
> ___
> 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] [Idr] RFC7854: EoR

[Robert Raszuk]

Tim,

Why not just send BGP Message Type 5 verbatim ? Are you saying that BMP is
not sending this message to BMP receivers when arriving from BGP peers of
the router ? If so why ?

Thx,
R.


On Fri, Sep 23, 2022 at 2:03 AM Tim Evens (tievens)  wrote:

> When I wrote route-refresh, that was from the router/sender side, not BMP
> receiver sending a route-refresh. BMP is still write-only.
>
>
>
> There are use-cases for re-syncing the RIB to the BMP receiver.  Some of
> the methods today are to clear the peer, request a route-refresh in, or to
> reset the BMP feed. This is a bit intrusive to the router (sender) and BMP
> receiver. Having to go to the router to request a refresh to the BMP
> server, IMO, is still okay.  The problem is that control knobs for refresh
> are at the BGP peer level, not BMP.  For Adj-RIB-In Pre-Policy, it makes
> sense to do that on the peer, but for Post-Policy, Adj-RIB-Out and
> Local-RIB, it doesn’t really make sense.  Having a knob to initiate BMP
> side refresh would be very nice and hopefully less intrusive.
>
>
>
> Regardless of the BMP server needing a refresh, a BMP server does not know
> when someone has requested route-refresh IN at the peer level (maybe it was
> requested for policy change, …) Instead, the BMP receiver, blindly,
> receives a boat load of updates with no awareness that it was a new RIB
> dump or controlled refresh. In this case, it would appear to be churn.
> IMO, there is value in having a message to signal the receiver that a
> refresh is coming, followed by an EoR.  A PEER_UP could be used for this,
> but that is intrusive and misuse of PEER_UP.
>
>
>
> --Tim
>
>
>
> On 9/22/22, 11:03 AM, "Jeffrey Haas"  wrote:
>
>
>
>
>
> > On Sep 21, 2022, at 7:42 AM, Zhuangshunwan  40huawei@dmarc.ietf.org> wrote:
> >
> > Hi Tim and All,
> >
> > I think the idea of a "BMP route refresh" would be appreciated,  it will
> helps keep the information synchronized between the BMP Server and the BMP
> Client.
>
> Would someone clarify what they mean by a bmp route refresh?
>
> The BMP protocol was intentionally designed as write-only.
>
> -- Jeff
> ___
> 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] [Idr] RFC7854: EoR

[Robert Raszuk]

Generating those could be done by running RFD in "informational mode" ie.
without applying actual dampening.

As far as saturating the pipe - I do not see how that would happen if
implementation would be sending such counters every X minutes.

I will look how easy/hard is to provide it in our BGP code base. However
question for this thread is if there is any interest to extend BMP to send
them to BMP receiver(s) ?

Thx,
R.



On Thu, Sep 22, 2022 at 10:13 PM Jeffrey Haas  wrote:

>
>
> On Sep 22, 2022, at 3:07 PM, Robert Raszuk  wrote:
>
> Hi Jeff,
>
>
>> State compression for route-monitoring messages in BMP is common.
>>
>> If you wanted perfect state, you would use route-mirroring mode, if the
>> implementation supported it.
>>
>
>  And why not use the churn counter.
>
>
> If your implementation supported such a thing.
>
> Most implementations keep per-peer in/out updates + messages for
> supporting the BGP MIB.  Those help.
>
> Per-prefix churn requires you to maintain at least some level of route
> state for that path.  That sort of state is kept as part of route flap
> damping, but RFD isn't as popular as it once was. (For good reasons.)
>
>
> I could see it being quite useful even without BMP running at all.
> And once available, sending it via BMP message would be pretty trivial.
>
>
> Very noisy, likely just contributing to saturating the pipe.
>
> If it was put into the stats reports, you'd get stats reports in roughly
> the same amount as your RIB activity.
>
> For stuff that can be hooked to rib-in state, the TLV feature can let you
> get the stuff as annotations... but the noise level of it probably doesn't
> help the analysis case terribly well.
>
>
> I could think of three such counters:
>
> - "Number of received paths for a given net during the session"
>
> - "Number of received withdraws for a given net during the session"
>
>
> Per-prefix state won't scale nicely as stats report, and doesn't fit into
> one of the five logical rib views.
>
> - "Number of next hop metric changes for registered next hops"
>
>
> This one potentially scales well and would fit into a stats report.
>
> -- Jeff
>
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] RFC7854: EoR

[Robert Raszuk]

Hi Jeff,


> State compression for route-monitoring messages in BMP is common.
>
> If you wanted perfect state, you would use route-mirroring mode, if the
> implementation supported it.
>

 And why not use the churn counter.

I could see it being quite useful even without BMP running at all.
And once available, sending it via BMP message would be pretty trivial.

I could think of three such counters:

- "Number of received paths for a given net during the session"
- "Number of received withdraws for a given net during the session"
- "Number of next hop metric changes for registered next hops"

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

Re: [GROW] [Idr] RFC7854: EoR

[Robert Raszuk]

Hey Henk,

The point is that what matters in BGP is reachability and stability //
Leave aside all the opaque junk BGP carries today //. Reachability you can
pretty much monitor by vanilla IBGP session say with Add-Paths if you want
to be fancy. Stability or more importantly filtering the "bad" routes is a
bit harder.

So I do not agree that exposing churn is hard. You perhaps think about it
in the atomic model where you have to mirror all received messages. Well
BMP original idea was about just that. But here we need to decouple
discussion about sharing Adj_RIB_In from global bRIB.

But here you can just keep local churn counter per NLRI to periodically
send it in BMP indicating how many paths for a given b_net was received or
withdrawn since your last BMP update. And it does not need to take much
space on the sender nor BMP receiver.

I would call it smart-compression where you significantly reduce make the
bits on the wire or in the ram/ssd yet you do not drop useful information.

Many thx,
R.

On Wed, Sep 21, 2022 at 3:45 PM Henk Smit  wrote:

> Hi Robert,
>
> > But this will hide BGP churn for a given NET to be detectable by BMP
> receiver. Is this a good thing ?
>
> The question is: how expensive is it to report everything bit-for-bit to
> the BMP collector?
> If you want to report everything, you have to store everything.
> Which will require bufferspace. How much? You don't know in advance. Might
> be a lot.
>
> The current way of doing things allows the BMP implementation on a router
> to be pretty efficient.
> When BGP receives routes, you store them in the BRIB. You don't store
> anything special for BMP (expect maybe timestamps, or other meta-data).
> When BMP on a router is going to send BMP updates, it just walks the BRIB,
> and sees which NLRI/routes have not been sent to the collector yet.
> BGP needs only 1 bit of information for that (to be precise: 1 bit per BMP
> session per NLRI/route).
>
> If you want to see all churn, you need loads of buffers.
> And BMP stops being an easy and efficient protocol.
> So yeah, I am greatly in favor of allowing "compression" (aka skipping
> reporting outdated info).
>
> henk.
>
>
> Op 21-09-2022 07:52 schreef Robert Raszuk :
>
>
> Hi Paolo,
>
> A-la: there is multiple updates related to a certain NLRI by when a BMP
> message is to be sent out, let's state-compress (ie. not send out) those
> that were already obsoleted by a subsequent update.
>
>
> But this will hide BGP churn for a given NET to be detectable by BMP
> receiver. Is this a good thing ? I am not sure. It is a loss of information
> to me.
>
> Thx,
> R.
> ___
> 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] [Idr] RFC7854: EoR

[Robert Raszuk]

Hi Paolo,


> A-la: there is multiple updates related to a certain NLRI by when a BMP
> message is to be sent out, let's state-compress (ie. not send out) those
> that were already obsoleted by a subsequent update.
>

But this will hide BGP churn for a given NET to be detectable by BMP
receiver. Is this a good thing ? I am not sure. It is a loss of information
to me.

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

Re: [GROW] [Idr] RFC7854: EoR

[Robert Raszuk]

Hey Tim,

> It’ll have to wait till after the RIB dump, or does it?

For me, the RIB dump is just a trigger/instruction to send all NLRIs and
their paths from the BGP RIB of a given AFI/SAFI. It should not really be a
different BMP feature in the sense of how we send BGP data to the BMP
receiver.

Now as far as compression I am not sure there is a need for it considering
today's interface speeds. It would be just unnecessary CPU cycles on both
sides of the BMP session.

Now to your question how BGP enqueues routes for UPDATE generation it is
very much implementation dependent. But normally yes the subsequent update
for already advertised 1.1.1.0/24 would have to wait till all other updates
subject to be sent with version bumped would be processed.

Thx,
R.

On Tue, Sep 20, 2022 at 2:05 AM Tim Evens (tievens) 
wrote:

> Inline, marked 
>
>
>
> On 9/19/22, 3:10 PM, "Robert Raszuk"  wrote:
>
>
>
> Hi Tim,
>
>
>
> · What does the sender do with the live updates that are
> happening while the RIB dump is taking place, should they queue/buffer and
> flood after RIB dump or drop them? IMO, dropping them is not an option.
> Ideally the sender should queue those and then send them (e.g., replay)
> them after the RIB dump (after sending the EoR).  Basically append them to
> the end of queue for transmission to the BMP receiver. State-compression
> could be used here to reduce the queue after RIB-DUMP.  We’ll likely need
> to discuss this a bit more…
>
>
>
>
>
> BGP RIB dump is just a full BGP table being sent to a peer (regular peer
> or BMP peer). The main BGP RIB table does not freeze during such an event.
> It is still live - for BGP it is business as usual.
>
>
>
>
>
> So when new updates come in during sending they are added to the BGP
> table, best path is run etc ... If the prefix sent to the receiver was not
> yet sent it will be propagated with new info.  If it was already sent the
> new update will be generated and sent after initial dump as simple BGP
> increment. It could be UPDATE MSG or WITHDRAW depending on the actual info
> which arrived during the cycle.
>
>
>
>  The above works with a per flow/session based transmission, as
> in BGP peering sessions. This would work well if BMP senders implemented a
> per peer buffer where messages were either delayed or enqueued in FIFO
> order per peer.  Basically start RIB dump, keep track of where you are
> sending the RIB and enqueue updates to the tail end.   NOTE, state
> compression can be performed for pending updates to BMP, but for pre-policy
> but it does not involve best-path.
>
> The challenge comes with the BMP buffer/queue via the TCP connection and
> how the sender handles sending a RIB dump while changes are happening
> real-time. For example, 100’s of peers need to be RIB dumped, the sender
> starts in parallel (threaded) to send the first 10 peers, then it
> progressively moves on to other peers 10 at a time. RIB dump is delayed by
> the BMP buffer/TCP connection.  If peer 1 RIB dump NLRI 1.1.1.0/24 has
> been sent/enqueued with state A, this is transmitted, but while the RIB
> dump is in progress, state of 1.1.1.0/24 has changed. It’ll have to wait
> till after the RIB dump, or does it?  Do you add it to the live stream of
> the RIB DUMP still in progress or do you wait till after the initial RIB
> DUMP with an EoR? Obviously if a prefix, such as 8.8.8.0/24 that has yet
> to be enqueued can benefit from state compress before enqueuing.  Although,
> that’s not written.
>
>
>
>
>
>
>
> Note that in some implementations all of the above may be
> multithreaded and happening in parallel. That is why there are flags in BGP
> RIB to assist with per peer deltas or per peer BGP tables like Adj-RIB-out.
>
>
>
> Thx,
>
> R.
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Mon, Sep 19, 2022 at 10:42 PM Tim Evens (tievens)  40cisco@dmarc.ietf.org> wrote:
>
> Let’s make sure to address that the bis is more than just an EoR update…
>
> @John Scudder , @Paolo Lucente
>  and I discussed back in 2017 several updates to
> fix/clarify 7854 in terms of implementations of senders and receivers…  It
> was on the table to create a new RFC instead of a bis to go over sender and
> receiver implementations.
>
> Somethings have changed with RFC8671 (Adj-RIB-Out) and RFC9069
> (Local-RIB).   RFC9069 defines a new peer type and makes it very clear to
> the receiver that the messages are for Local-RIB. RFC8671 follows RFC7854,
> but clarifies that PEER_(UP|DOWN) are singular to the route-(mirroring |
> monitor) messages.  In other words, for Local-RIB we know which messages
> are Local-RIB by peer type, but for Adj-RIB-Out and Adj-RIB-In (both 

Re: [GROW] [Idr] RFC7854: EoR

[Robert Raszuk]

Hi Tim,


   - What does the sender do with the live updates that are happening while
   the RIB dump is taking place, should they queue/buffer and flood after RIB
   dump or drop them? IMO, dropping them is not an option. Ideally the sender
   should queue those and then send them (e.g., replay) them after the RIB
   dump (after sending the EoR).  Basically append them to the end of queue
   for transmission to the BMP receiver. State-compression could be used here
   to reduce the queue after RIB-DUMP.  We’ll likely need to discuss this a
   bit more…



BGP RIB dump is just a full BGP table being sent to a peer (regular peer or
BMP peer). The main BGP RIB table does not freeze during such an event. It
is still live - for BGP it is business as usual.

So when new updates come in during sending they are added to the BGP table,
best path is run etc ... If the prefix sent to the receiver was not yet
sent it will be propagated with new info.  If it was already sent the new
update will be generated and sent after initial dump as simple BGP
increment. It could be UPDATE MSG or WITHDRAW depending on the actual info
which arrived during the cycle.

Note that in some implementations all of the above may be multithreaded and
happening in parallel. That is why there are flags in BGP RIB to assist
with per peer deltas or per peer BGP tables like Adj-RIB-out.

Thx,
R.






On Mon, Sep 19, 2022 at 10:42 PM Tim Evens (tievens)  wrote:

> Let’s make sure to address that the bis is more than just an EoR update…
>
> @John Scudder , @Paolo Lucente
>  and I discussed back in 2017 several updates to
> fix/clarify 7854 in terms of implementations of senders and receivers…  It
> was on the table to create a new RFC instead of a bis to go over sender and
> receiver implementations.
>
> Somethings have changed with RFC8671 (Adj-RIB-Out) and RFC9069
> (Local-RIB).   RFC9069 defines a new peer type and makes it very clear to
> the receiver that the messages are for Local-RIB. RFC8671 follows RFC7854,
> but clarifies that PEER_(UP|DOWN) are singular to the route-(mirroring |
> monitor) messages.  In other words, for Local-RIB we know which messages
> are Local-RIB by peer type, but for Adj-RIB-Out and Adj-RIB-In (both pre
> and post policy) we have to look at flags (per mirroring/monitor message)
> and distinguish.
>
>
>
> Correlating NLRIs (BGP updates) to PEER state (peer-(up|down) and
> capabilities advertised) works when we can hash/identify per-peer header to
> PEER_(UP|DOWN) per-peer headers.  If they equal, then they are associated.
>
>
>
> When working with anything other than RFC9069, you send a SINGLE
> PEER-(UP|DOWN). The route-(mirroring/monitor) messages are then
> linked/associated by peer type. AFI/SAFI (rib-out, rib-in, pre-policy,
> post-policy) are NLRI level.  OpenBMP, as an example, will hash based on
> this.  It expects a single PEER-(UP|DOWN) that is re-used for the other
> AFI/SAFIs and tables (in, out) and mix of pre vs post policy.   The only
> exception to this is Local-RIB, which is very clear on the usage. The
> problem I see is that this is not clearly articulated in RFC7854 or
> RFC8671…. Although 8671 inherits 7854, so a BIS for 7854 will address 8671.
>
>
>
> OpenBMP takes the approach of hashing NLRI (bgp updates) and peer up/down
> messages to associate them together. When we receive a PEER DOWN, we mark
> NLRIs associated as withdrawn.   Upon PEER UP, we delete and rebuild the
> RIB. This is where EoR is very important!!!
>
>
>
> The problem I see today is that senders (Cisco, Juniper, Huawei, Arista,
> …) are unclear based on RFC7854 if they:
>
>
>
>- should send multiple PEER_(UP|DOWN) messages based on flags
>(rib-out, rib-in, pre-policy, post-policy)
>- EoR should be per AFI/SAFI (IMO this should be an obvious yes)
>- Route-Refresh; 7854 doesn’t call this out, but should I send a
>ROUTE-REFRESH message to BMP receiver or not?? IMO, YES… send it and we’ll
>trigger a delete/purge and rebuild based on it. EoR will be expected.
>- What does the sender do with the live updates that are happening
>while the RIB dump is taking place, should they queue/buffer and flood
>after RIB dump or drop them? IMO, dropping them is not an option. Ideally
>the sender should queue those and then send them (e.g., replay) them after
>the RIB dump (after sending the EoR).  Basically append them to the end of
>queue for transmission to the BMP receiver. State-compression could be used
>here to reduce the queue after RIB-DUMP.  We’ll likely need to discuss this
>a bit more…
>
>
>
>
>
> Thanks,
>
> Tim
>
>
>
> On 9/16/22, 3:17 AM, "GROW"  wrote:
>
>
>
> Hi all,
>
> Vincent, thanks for bringing this up. We've been puzzled about what to
> expect exactly, too.
>
> On Thu 15 Sep 2022, 01:08, Maximilian Wilhelm wrote:
> > Anno domini 2022 Jeffrey Haas scripsit:
> >
> > > (..) the per-AFI/SAFI end of rib is a feature rather than a bug.
> > >
> >
> > I fully agree with 

Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol

[Robert Raszuk]

Hi,


> Did you read the draft? The main difference is that since OSPF-GT is
>> generalized to be used for non-routing, there is no installation of routes.
>>
>

> Gyan> So The routes would be application use case specific “non
> routing” routes for example for BGP-LS it would be the related LSDB data
> that maybe similar data formatting as in RFC 7752 or new formatting
> described in separate draft.  The other possible use cases it’s “non
> routing” use cases, however in the BGP-LS case it is routing related info,
> not “non routing” related, so would this really be a good solution for
> BGP-LS?  I am thinking maybe not.
>

Guys,

It really does not matter if the northbound distribution of link state data
results in route installation or not. I understand why Acee is bringing
this point, but holistically looking at the entire domain it is irrelevant.

The data received is used for end to end path computation within a given
domain which is equally critical as local route installation.

So no matter what - Gyan you are correct here - it is better to be
accurate.

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

Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol

[Robert Raszuk]

> but kindly don't assert that others can't do it when it's being done.

I did not assert that it can not be done as it is done today.

But not everything which is done today should be kept that way for an
endless future.

Many thx,
R.


On Mon, Jul 11, 2022 at 8:18 PM Jeffrey Haas  wrote:

> Robert,
>
>
> On Jul 11, 2022, at 12:16 PM, Robert Raszuk  wrote:
> On Mon, Jul 11, 2022 at 6:09 PM Jeffrey Haas  wrote:
>
>> Tianran,
>>
>> Please note that nothing prohibits BGP-LS from being distributed over BMP
>> today aside from implementation support.  It's just another AFI/SAFI.
>>
>> -- Jeff
>>
>
> Do you mean to build a dummy Adj_RIB_IN or OUT just to feed BMP with the
> BGP-LS formatted data at the IGP node exporting this data ?
>
>
> Do whatever you'd do in your implementation for BMP for the scenario that
> makes sense for you.
>
> If you want to know what an upstream BGP router sent you, look at your
> rib-in.
> If you want to know what local state you've got and are intending to
> disseminate to your downstreams, look at your loc-rib.
> If you want to know what state you've sent to your downstream, look at
> your rib-out.
>
> None of this is unusual.
>
> rib-in and rib-out are clear from a BGP protocol fundamentals perspective.
>
> loc-rib has a touch of ambiguity, along with exactly the same dose of
> ambiguity about "where does locally originated state manifest in
> implementations" that made for a lot of discussion in GROW "recently" as
> the loc-rib and rib-out specs were being finished for RFC purposes.
>
> In our implementation, where loc-rib tracks the "lsdist.0" table, I'd
> probably use that for the majority of use cases that I'd want to get a feed
> for BGP-LS from BMP.  Or, I could just do a BGP-LS peering session and get
> it that way, but the discussion is that BMP works fine.
>
>
> If this would avoid BGP to check the syntax of what is send it would work
> fine .. but it would not. And BGP has no business on doing that check and
> to understand zoo of foreign extensions completely not related to BGP
> itself.
>
>
> Feel free to speak for your own implementation, but kindly don't assert
> that others can't do it when it's being done.
>
> -- Jeff
>
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol

[Robert Raszuk]

HI Jeff,

On Mon, Jul 11, 2022 at 6:09 PM Jeffrey Haas  wrote:

> Tianran,
>
> Please note that nothing prohibits BGP-LS from being distributed over BMP
> today aside from implementation support.  It's just another AFI/SAFI.
>
> -- Jeff
>

Do you mean to build a dummy Adj_RIB_IN or OUT just to feed BMP with the
BGP-LS formatted data at the IGP node exporting this data ?

If this would avoid BGP to check the syntax of what is send it would work
fine .. but it would not. And BGP has no business on doing that check and
to understand zoo of foreign extensions completely not related to BGP
itself.

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

Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol

[Robert Raszuk]

Hi,

I think BMP is busy enough that loading more on it will be problematic.

Sourcing from two protocols just to leverage single transport session seems
not best idea.

IMO opening a new unicast session directly by the producer of subject data
is best way to share/export it.

Many thx,
R.

On Mon, Jul 11, 2022 at 5:34 PM Tianran Zhou  wrote:

> Hi Robert,
>
>
> Since our work is just follow the BMP which is in GROW in OPS area, we 
> presented this in OPSAWG and GROW.
>
>
> We want to reuse BMP for IGP with some simple extensions. We do not want to 
> create a new protocol only because of the BMP name.
>
> Cheers,
> Tianran
>
>
>
>
> ----------
>
> Sent from WeLink
> *发件人： *Robert Raszuk
> *收件人： *Tianran Zhou
> *抄送： *Yingzhen Qu;idr;grow<
> grow@ietf.org>;lsr
> *主题： *Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol
> *时间： *2022-07-11 23:05:56
>
> Hello Tianran,
>
> Oh I was not aware of such document. Did you ever share it with LSR WG
> before ?
>
> Quick browsing reveals that you have taken a bit different approach ..
> very IGP centric borrowing IGP encoding at the message level.
>
> For example peer state notification I purposely decided not to include as
> this is already reflected in the LSDB.
>
> I will take a more detail read of your spec. Then we can talk if there is
> some overlap or both approaches are so different then it makes sense to
> progress both. One size does not fit all :)
>
> Best,
> R.
>
>
>
>
> On Mon, Jul 11, 2022 at 4:54 PM Tianran Zhou 
> wrote:
>
>> Hi Robert,
>>
>>
>> This is very interesting to me. We had a protocol design for IGP monitoring:
>>
>>
>> https://datatracker.ietf.org/doc/html/draft-gu-opsawg-network-monitoring-igp-01
>>
>> It would be a good idea if we can find some common ground.
>>
>> Cheers,
>> Tianran
>>
>>
>>
>>
>> --
>>
>> Sent from WeLink
>> *发件人： *Robert Raszuk
>> *收件人： *Tianran Zhou
>> *抄送： *Yingzhen Qu;idr;grow<
>> grow@ietf.org>;lsr
>> *主题： *Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol
>> *时间： *2022-07-11 22:05:31
>>
>> Hi Tianran,
>>
>> Yes it is,
>>
>> I dedicated entire paragraph in section 1 of the document to highlight
>> that point:
>>
>>The primary inspiration for this work has been based on the success
>>of BGP Monitoring Protocol (BMP) [RFC7854] which in a number of
>>aspects shares the same high level requirements - point to point
>>routing information distribution, protocol observability and enhanced
>>operations.  It also needs to be highlighted that BMP (while it
>>technically could) does not use native BGP sessions to propagate such
>>information, but is running a separate transport.  IMP authors have
>>chosen to reuse selected BMP building blocks and BMP operational and
>>deployment experience.
>>
>>
>>
>> Many thx,
>> R.
>>
>> On Mon, Jul 11, 2022 at 4:02 PM Tianran Zhou 
>> wrote:
>>
>>> Hi Robert,
>>>
>>> I see this name very similar to BMP bgp monitoring protocol.
>>> Is this the similar function and scope as BMP?
>>>
>>>
>>> Best,
>>> Tianran
>>>
>>> --
>>>
>>> Sent from WeLink
>>> *发件人： *Robert Raszuk
>>> *收件人： *Yingzhen Qu
>>> *抄送： *idr;grow;lsr
>>> *主题： *Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol
>>> *时间： *2022-07-11 18:01:47
>>>
>>> Hi Yingzhen,
>>>
>>> Yes I understand that OSPF-GT is a new protocol leveraging some OSPF
>>> elements.
>>>
>>> And please do not get me wrong ... way before OSPF Transport Instance I
>>> wrote BGP Transport Instance proposal and I do consider such additions to
>>> protocols as a very useful thing. In fact honestly recent discussions on
>>> UPA/PUA/PULSE could be very well served by OSPF-GT in a stateful fashion.
>>>
>>> But I just do not see this fits well as a replacement of BGP-LS.
>>>
>>> Yes, protocol designers like a swiss army knife approach (not to use
>>> nail and hammer analogy). However I think custom tools in the toolkit work
>>> much better for specific tasks :)
>>>
>>> Cheers,
>>> R.
>>>
>>>
>>>
>>> On Mon, Jul 11, 2022 at 3:20 AM Yingzhen Qu 
>>> wrote:
>>>
>>>> Hi Robert,
>>>>
>>>> Please think of OSPF

Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol

[Robert Raszuk]

Tony,


> a) configuration is already standardized via NETCONF WG/channels/methods.
> pulling it via this seems redundant.
>

It is optional.


> b) YANG is already pulled via other channels so I see little value of
> pulling it here. same as a) basically
>

Please enumerate what channels ? And in the same time please indicate why
those channels are not good enough such that we need to keep stuffing BGP
protocol with the IGP, SR, Detnet etc .. data.



> c) adding all those "sync" via SNP is basically building a flooding peer
> again as far I can deduct having flown quickly over the draft. Doing that
> over QUIC/TCP is a bad idea due to head-on blocking problems well known
> with flooding. if the consumer cannot keep up with the real stream the
> sender can only start to throw away stuff or reset the session practically
> speaking
>

IMP is NOT doing flooding. If you think that control plane with 100s of CPU
cores will be slower in accepting your RE generated streams please kindly
reconsider.

But if the rate of data change would be a problem we would already choke
with TCP based BGP-LS. So not sure what problem are you seeing. Are you
referring to one interface flood mirroring ? For debugging it either be
nicely packed and sent or screen scraped. Which one do you prefer ?

d) beats me why you would want this to carry BGP-LS again if y6ou can
> simply run another session/BGP instance on any good implementation today.
>

beats me why would ever want to keep polluting BGP protocol like this. Are
you saying that IGP can not open a TCP socket or setup a QUIC session ? Is
it too much to ask ? Too complex ?


> Given all the big wishlist included in the draft protocol needs probably
> something to negotiate WHAT of all the whole panopticum the producer can
> support unless it's somehow in the PUB/SUB (but then again, this probably
> needs mode negotiation as well given the plethora of possibilities there).
>

Please kindly observe what is mandatory and what is optional. Also kindly
notice the split between Producer and Producer's Proxy.

Thx,
R.






>
> -- tony
>
> On Mon, Jul 11, 2022 at 4:54 PM Tianran Zhou  40huawei@dmarc.ietf.org> wrote:
>
>> Hi Robert,
>>
>>
>> This is very interesting to me. We had a protocol design for IGP monitoring:
>>
>>
>> https://datatracker.ietf.org/doc/html/draft-gu-opsawg-network-monitoring-igp-01
>>
>> It would be a good idea if we can find some common ground.
>>
>> Cheers,
>> Tianran
>>
>>
>>
>>
>> --
>>
>> Sent from WeLink
>> *发件人： *Robert Raszuk
>> *收件人： *Tianran Zhou
>> *抄送： *Yingzhen Qu;idr;grow<
>> grow@ietf.org>;lsr
>> *主题： *Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol
>> *时间： *2022-07-11 22:05:31
>>
>> Hi Tianran,
>>
>> Yes it is,
>>
>> I dedicated entire paragraph in section 1 of the document to highlight
>> that point:
>>
>>The primary inspiration for this work has been based on the success
>>of BGP Monitoring Protocol (BMP) [RFC7854] which in a number of
>>aspects shares the same high level requirements - point to point
>>routing information distribution, protocol observability and enhanced
>>operations.  It also needs to be highlighted that BMP (while it
>>technically could) does not use native BGP sessions to propagate such
>>information, but is running a separate transport.  IMP authors have
>>chosen to reuse selected BMP building blocks and BMP operational and
>>deployment experience.
>>
>>
>>
>> Many thx,
>> R.
>>
>> On Mon, Jul 11, 2022 at 4:02 PM Tianran Zhou 
>> wrote:
>>
>>> Hi Robert,
>>>
>>> I see this name very similar to BMP bgp monitoring protocol.
>>> Is this the similar function and scope as BMP?
>>>
>>>
>>> Best,
>>> Tianran
>>>
>>> --
>>>
>>> Sent from WeLink
>>> *发件人： *Robert Raszuk
>>> *收件人： *Yingzhen Qu
>>> *抄送： *idr;grow;lsr
>>> *主题： *Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol
>>> *时间： *2022-07-11 18:01:47
>>>
>>> Hi Yingzhen,
>>>
>>> Yes I understand that OSPF-GT is a new protocol leveraging some OSPF
>>> elements.
>>>
>>> And please do not get me wrong ... way before OSPF Transport Instance I
>>> wrote BGP Transport Instance proposal and I do consider such additions to
>>> protocols as a very useful thing. In fact honestly recent discussions on
>>> UPA/PUA/PULSE could be very well served by OSPF-

Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol

[Robert Raszuk]

Hello Tianran,

Oh I was not aware of such document. Did you ever share it with LSR WG
before ?

Quick browsing reveals that you have taken a bit different approach .. very
IGP centric borrowing IGP encoding at the message level.

For example peer state notification I purposely decided not to include as
this is already reflected in the LSDB.

I will take a more detail read of your spec. Then we can talk if there is
some overlap or both approaches are so different then it makes sense to
progress both. One size does not fit all :)

Best,
R.




On Mon, Jul 11, 2022 at 4:54 PM Tianran Zhou  wrote:

> Hi Robert,
>
>
> This is very interesting to me. We had a protocol design for IGP monitoring:
>
>
> https://datatracker.ietf.org/doc/html/draft-gu-opsawg-network-monitoring-igp-01
>
> It would be a good idea if we can find some common ground.
>
> Cheers,
> Tianran
>
>
>
>
> ----------
>
> Sent from WeLink
> *发件人： *Robert Raszuk
> *收件人： *Tianran Zhou
> *抄送： *Yingzhen Qu;idr;grow<
> grow@ietf.org>;lsr
> *主题： *Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol
> *时间： *2022-07-11 22:05:31
>
> Hi Tianran,
>
> Yes it is,
>
> I dedicated entire paragraph in section 1 of the document to highlight
> that point:
>
>The primary inspiration for this work has been based on the success
>of BGP Monitoring Protocol (BMP) [RFC7854] which in a number of
>aspects shares the same high level requirements - point to point
>routing information distribution, protocol observability and enhanced
>operations.  It also needs to be highlighted that BMP (while it
>technically could) does not use native BGP sessions to propagate such
>information, but is running a separate transport.  IMP authors have
>chosen to reuse selected BMP building blocks and BMP operational and
>deployment experience.
>
>
>
> Many thx,
> R.
>
> On Mon, Jul 11, 2022 at 4:02 PM Tianran Zhou 
> wrote:
>
>> Hi Robert,
>>
>> I see this name very similar to BMP bgp monitoring protocol.
>> Is this the similar function and scope as BMP?
>>
>>
>> Best,
>> Tianran
>>
>> --
>>
>> Sent from WeLink
>> *发件人： *Robert Raszuk
>> *收件人： *Yingzhen Qu
>> *抄送： *idr;grow;lsr
>> *主题： *Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol
>> *时间： *2022-07-11 18:01:47
>>
>> Hi Yingzhen,
>>
>> Yes I understand that OSPF-GT is a new protocol leveraging some OSPF
>> elements.
>>
>> And please do not get me wrong ... way before OSPF Transport Instance I
>> wrote BGP Transport Instance proposal and I do consider such additions to
>> protocols as a very useful thing. In fact honestly recent discussions on
>> UPA/PUA/PULSE could be very well served by OSPF-GT in a stateful fashion.
>>
>> But I just do not see this fits well as a replacement of BGP-LS.
>>
>> Yes, protocol designers like a swiss army knife approach (not to use nail
>> and hammer analogy). However I think custom tools in the toolkit work much
>> better for specific tasks :)
>>
>> Cheers,
>> R.
>>
>>
>>
>> On Mon, Jul 11, 2022 at 3:20 AM Yingzhen Qu 
>> wrote:
>>
>>> Hi Robert,
>>>
>>> Please think of OSPF-GT as a new protocol and it borrows ideas from
>>> OSPF. BGP-LS is one use case. In LSR WG, there have been proposals asking
>>> IGPs to carry non-routing information which will have impacts on protocol
>>> convergence, and OSPF-GT is meant to be the vehicle for such information.
>>>
>>> BMP started before YANG, now with NETCONF/YANG or gNMI, you can retrieve
>>> the entire LSDB or part of it from a router, or subscribe to some data
>>> instances.
>>>
>>> Thanks,
>>> Yingzhen
>>>
>>> On Jul 10, 2022, at 3:44 PM, Robert Raszuk  wrote:
>>>
>>> Hi Acee,
>>>
>>> My questions were based on section 3.4 of the latest version of the
>>> draft.
>>>
>>> So I do not think I misinterpreted it.
>>>
>>> Thank you,
>>> R.
>>>
>>>
>>>
>>> On Mon, Jul 11, 2022 at 12:38 AM Acee Lindem (acee) 
>>> wrote:
>>>
>>>> Hi Robert,
>>>>
>>>>
>>>>
>>>> *From: *Lsr  on behalf of Robert Raszuk <
>>>> rob...@raszuk.net>
>>>> *Date: *Sunday, July 10, 2022 at 1:32 PM
>>>> *To: *Yingzhen Qu 
>>>> *Cc: *Gyan Mishra , Susan Hares ,
>>>> IDR List , "grow@ietf.org grow@ietf.org&qu

Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol

[Robert Raszuk]

Hi Tianran,

Yes it is,

I dedicated entire paragraph in section 1 of the document to highlight that
point:

   The primary inspiration for this work has been based on the success
   of BGP Monitoring Protocol (BMP) [RFC7854] which in a number of
   aspects shares the same high level requirements - point to point
   routing information distribution, protocol observability and enhanced
   operations.  It also needs to be highlighted that BMP (while it
   technically could) does not use native BGP sessions to propagate such
   information, but is running a separate transport.  IMP authors have
   chosen to reuse selected BMP building blocks and BMP operational and
   deployment experience.



Many thx,
R.

On Mon, Jul 11, 2022 at 4:02 PM Tianran Zhou  wrote:

> Hi Robert,
>
> I see this name very similar to BMP bgp monitoring protocol.
> Is this the similar function and scope as BMP?
>
>
> Best,
> Tianran
>
> --
>
> Sent from WeLink
> *发件人： *Robert Raszuk
> *收件人： *Yingzhen Qu
> *抄送： *idr;grow;lsr
> *主题： *Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol
> *时间： *2022-07-11 18:01:47
>
> Hi Yingzhen,
>
> Yes I understand that OSPF-GT is a new protocol leveraging some OSPF
> elements.
>
> And please do not get me wrong ... way before OSPF Transport Instance I
> wrote BGP Transport Instance proposal and I do consider such additions to
> protocols as a very useful thing. In fact honestly recent discussions on
> UPA/PUA/PULSE could be very well served by OSPF-GT in a stateful fashion.
>
> But I just do not see this fits well as a replacement of BGP-LS.
>
> Yes, protocol designers like a swiss army knife approach (not to use nail
> and hammer analogy). However I think custom tools in the toolkit work much
> better for specific tasks :)
>
> Cheers,
> R.
>
>
>
> On Mon, Jul 11, 2022 at 3:20 AM Yingzhen Qu 
> wrote:
>
>> Hi Robert,
>>
>> Please think of OSPF-GT as a new protocol and it borrows ideas from OSPF.
>> BGP-LS is one use case. In LSR WG, there have been proposals asking IGPs to
>> carry non-routing information which will have impacts on protocol
>> convergence, and OSPF-GT is meant to be the vehicle for such information.
>>
>> BMP started before YANG, now with NETCONF/YANG or gNMI, you can retrieve
>> the entire LSDB or part of it from a router, or subscribe to some data
>> instances.
>>
>> Thanks,
>> Yingzhen
>>
>> On Jul 10, 2022, at 3:44 PM, Robert Raszuk  wrote:
>>
>> Hi Acee,
>>
>> My questions were based on section 3.4 of the latest version of the
>> draft.
>>
>> So I do not think I misinterpreted it.
>>
>> Thank you,
>> R.
>>
>>
>>
>> On Mon, Jul 11, 2022 at 12:38 AM Acee Lindem (acee) 
>> wrote:
>>
>>> Hi Robert,
>>>
>>>
>>>
>>> *From: *Lsr  on behalf of Robert Raszuk <
>>> rob...@raszuk.net>
>>> *Date: *Sunday, July 10, 2022 at 1:32 PM
>>> *To: *Yingzhen Qu 
>>> *Cc: *Gyan Mishra , Susan Hares ,
>>> IDR List , "grow@ietf.org grow@ietf.org" ,
>>> lsr 
>>> *Subject: *Re: [Lsr] [Idr] [GROW] IGP Monitoring Protocol
>>>
>>>
>>>
>>> Hi Yingzhen & OSPF-GT authors,
>>>
>>>
>>>
>>> UP front I must state that anything is better to export IGP information
>>> from routers to interested nodes than using BGP for it.
>>>
>>>
>>>
>>> But to propose using OSPF to transport ISIS seems pretty brave :) I must
>>> admit it !
>>>
>>>
>>>
>>> With that I have few questions to the proposal - assuming the use case
>>> is to distribute links state info in a *point to point* fashion:
>>>
>>>
>>>
>>>1. What is the advantage - if any - to use a new OSPF
>>>instance/process to send link state data over a unicast session to a
>>>controller ?
>>>
>>>
>>>
>>> It doesn’t have to be unicast, the remote neighbor construct just
>>> extends the possibilities in OSPF-GT. With an OSPF LSDB, the obvious
>>> advantage is all the protocol machinery is in place.  Note that LSDB
>>> streaming is just but one use case and of OSPF-GT. The detals of this
>>> application would be specified in a separate draft.
>>>
>>>
>>>
>>>
>>>
>>>1. The draft is pretty silent on the nature of such a p2p session.
>>>Please be explicit if this is TCP, QUIC or what ?
>>>
>>>
>>>
>>> It is OSPF, 

Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol

[Robert Raszuk]

Hi Yingzhen,

Yes I understand that OSPF-GT is a new protocol leveraging some OSPF
elements.

And please do not get me wrong ... way before OSPF Transport Instance I
wrote BGP Transport Instance proposal and I do consider such additions to
protocols as a very useful thing. In fact honestly recent discussions on
UPA/PUA/PULSE could be very well served by OSPF-GT in a stateful fashion.

But I just do not see this fits well as a replacement of BGP-LS.

Yes, protocol designers like a swiss army knife approach (not to use nail
and hammer analogy). However I think custom tools in the toolkit work much
better for specific tasks :)

Cheers,
R.



On Mon, Jul 11, 2022 at 3:20 AM Yingzhen Qu  wrote:

> Hi Robert,
>
> Please think of OSPF-GT as a new protocol and it borrows ideas from OSPF.
> BGP-LS is one use case. In LSR WG, there have been proposals asking IGPs to
> carry non-routing information which will have impacts on protocol
> convergence, and OSPF-GT is meant to be the vehicle for such information.
>
> BMP started before YANG, now with NETCONF/YANG or gNMI, you can retrieve
> the entire LSDB or part of it from a router, or subscribe to some data
> instances.
>
> Thanks,
> Yingzhen
>
> On Jul 10, 2022, at 3:44 PM, Robert Raszuk  wrote:
>
> Hi Acee,
>
> My questions were based on section 3.4 of the latest version of the draft.
>
> So I do not think I misinterpreted it.
>
> Thank you,
> R.
>
>
>
> On Mon, Jul 11, 2022 at 12:38 AM Acee Lindem (acee) 
> wrote:
>
>> Hi Robert,
>>
>>
>>
>> *From: *Lsr  on behalf of Robert Raszuk <
>> rob...@raszuk.net>
>> *Date: *Sunday, July 10, 2022 at 1:32 PM
>> *To: *Yingzhen Qu 
>> *Cc: *Gyan Mishra , Susan Hares ,
>> IDR List , "grow@ietf.org grow@ietf.org" ,
>> lsr 
>> *Subject: *Re: [Lsr] [Idr] [GROW] IGP Monitoring Protocol
>>
>>
>>
>> Hi Yingzhen & OSPF-GT authors,
>>
>>
>>
>> UP front I must state that anything is better to export IGP information
>> from routers to interested nodes than using BGP for it.
>>
>>
>>
>> But to propose using OSPF to transport ISIS seems pretty brave :) I must
>> admit it !
>>
>>
>>
>> With that I have few questions to the proposal - assuming the use case is
>> to distribute links state info in a *point to point* fashion:
>>
>>
>>
>>1. What is the advantage - if any - to use a new OSPF
>>instance/process to send link state data over a unicast session to a
>>controller ?
>>
>>
>>
>> It doesn’t have to be unicast, the remote neighbor construct just extends
>> the possibilities in OSPF-GT. With an OSPF LSDB, the obvious advantage is
>> all the protocol machinery is in place.  Note that LSDB streaming is just
>> but one use case and of OSPF-GT. The detals of this application would be
>> specified in a separate draft.
>>
>>
>>
>>
>>
>>1. The draft is pretty silent on the nature of such a p2p session.
>>Please be explicit if this is TCP, QUIC or what ?
>>
>>
>>
>> It is OSPF, OSPF has its own protocol identifier (89). This draft just
>> extends OSPF. I think you’ve misinterpreted the draft. Hence, your other
>> questions aren’t really applicable or would be answered in a draft of the
>> OSPF/IS-IS LSDB usage of OSPF-GT.
>>
>>
>>
>> Thanks,
>> Acee
>>
>>
>>
>>
>>
>>
>>
>> C) The draft is pretty silent on types of authentication for such
>> sessions. Security considerations are pretty weak in that respect as well.
>>
>>
>>
>>The security considerations for OSPF-GT will be similar to those for
>>OSPFv2 [RFC2328] and OSPFv3 [RFC5340].  However, since OSPF-GT is not
>>used to update OSPF routing, the consequences of attacks will be
>>dependent on advertised non-routing information.
>>
>>
>>
>> I would actually argue that security considerations of p2p remote
>> neighbors are actually quite different from security considerations of
>> flooding data.
>>
>>
>>
>> Along the same lines security is not about protecting your routing ... it
>> is much more about protecting the entire network by exposing critical
>> information externally to non authorized parties.
>>
>>
>>
>> D) Are there any PUB-SUB options possible for OSPF-GT ?
>>
>>
>>
>> E) Is there any filtering possible for OSPF-GT ?
>>
>>
>>
>> F) Are you envisioning use of OSPF-GT proxies and if so are you planning
>> to add t

Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol

[Robert Raszuk]

Hi Acee,

My questions were based on section 3.4 of the latest version of the draft.

So I do not think I misinterpreted it.

Thank you,
R.



On Mon, Jul 11, 2022 at 12:38 AM Acee Lindem (acee)  wrote:

> Hi Robert,
>
>
>
> *From: *Lsr  on behalf of Robert Raszuk <
> rob...@raszuk.net>
> *Date: *Sunday, July 10, 2022 at 1:32 PM
> *To: *Yingzhen Qu 
> *Cc: *Gyan Mishra , Susan Hares ,
> IDR List , "grow@ietf.org grow@ietf.org" ,
> lsr 
> *Subject: *Re: [Lsr] [Idr] [GROW] IGP Monitoring Protocol
>
>
>
> Hi Yingzhen & OSPF-GT authors,
>
>
>
> UP front I must state that anything is better to export IGP information
> from routers to interested nodes than using BGP for it.
>
>
>
> But to propose using OSPF to transport ISIS seems pretty brave :) I must
> admit it !
>
>
>
> With that I have few questions to the proposal - assuming the use case is
> to distribute links state info in a *point to point* fashion:
>
>
>
>1. What is the advantage - if any - to use a new OSPF instance/process
>to send link state data over a unicast session to a controller ?
>
>
>
> It doesn’t have to be unicast, the remote neighbor construct just extends
> the possibilities in OSPF-GT. With an OSPF LSDB, the obvious advantage is
> all the protocol machinery is in place.  Note that LSDB streaming is just
> but one use case and of OSPF-GT. The detals of this application would be
> specified in a separate draft.
>
>
>
>
>
>1. The draft is pretty silent on the nature of such a p2p session.
>Please be explicit if this is TCP, QUIC or what ?
>
>
>
> It is OSPF, OSPF has its own protocol identifier (89). This draft just
> extends OSPF. I think you’ve misinterpreted the draft. Hence, your other
> questions aren’t really applicable or would be answered in a draft of the
> OSPF/IS-IS LSDB usage of OSPF-GT.
>
>
>
> Thanks,
> Acee
>
>
>
>
>
>
>
> C) The draft is pretty silent on types of authentication for such
> sessions. Security considerations are pretty weak in that respect as well.
>
>
>
>The security considerations for OSPF-GT will be similar to those for
>OSPFv2 [RFC2328] and OSPFv3 [RFC5340].  However, since OSPF-GT is not
>used to update OSPF routing, the consequences of attacks will be
>dependent on advertised non-routing information.
>
>
>
> I would actually argue that security considerations of p2p remote
> neighbors are actually quite different from security considerations of
> flooding data.
>
>
>
> Along the same lines security is not about protecting your routing ... it
> is much more about protecting the entire network by exposing critical
> information externally to non authorized parties.
>
>
>
> D) Are there any PUB-SUB options possible for OSPF-GT ?
>
>
>
> E) Is there any filtering possible for OSPF-GT ?
>
>
>
> F) Are you envisioning use of OSPF-GT proxies and if so are you planning
> to add this to the document ?
>
>
>
> G) How are you going to address Receivers which do not support OSPF-GT
> parser ?
>
>
>
> H) As you know many operators are attracted to BGP-LS based on the fact
> that it offers the same view of information irrespective of what is the
> protocol producing the data. Is there some thought on such normalization in
> the OSPF-GT proposal ?
>
>
>
> I) What's the take of OSPF-GT draft authors on the YANG model in respect
> of using it for normalization of exported data ?
>
>
>
> To summarize IMHO we should not stretch routing protocols be it OSPF, ISIS
> or BGP to be messengers of link state data running and to artificially
> force them to run in a point-to-point model between router and controller.
>
>
>
> Kind regards,
>
> Robert
>
>
>
>
>
> On Sun, Jul 10, 2022 at 7:04 AM Yingzhen Qu 
> wrote:
>
> Hi,
>
>
>
> Since we’re discussing possible solutions, I’d like to bring up the draft:
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-transport-instance/
>
>
>
> We just submitted a new version. The name of the document is changed to
> “OSPF-GT (Generalized Transport)”, and a use case is added to use OSPF-GT
> as a possible replacement of BGP-LS.
>
>
>
> Note: OSPF-GT is not traditional OSPF, and it’s not used to calculate
> routes. It uses the reachability info calculated by routing protocols,
> OSPF, ISIS or static routing etc.. It provides mechanisms to advertise
> non-routing information, and remote neighbor is supported.
>
>
>
> Reviews and comments are welcome.
>
>
>
>
>
> Thanks,
>
> Yingzhen
>
>
>
> On Jul 9, 2022, at 5:33 PM, Gy

Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol

[Robert Raszuk]

Hi Yingzhen & OSPF-GT authors,

UP front I must state that anything is better to export IGP information
from routers to interested nodes than using BGP for it.

But to propose using OSPF to transport ISIS seems pretty brave :) I must
admit it !

With that I have few questions to the proposal - assuming the use case is
to distribute links state info in a *point to point* fashion:

A) What is the advantage - if any - to use a new OSPF instance/process to
send link state data over a unicast session to a controller ?

B) The draft is pretty silent on the nature of such a p2p session. Please
be explicit if this is TCP, QUIC or what ?

C) The draft is pretty silent on types of authentication for such sessions.
Security considerations are pretty weak in that respect as well.

   The security considerations for OSPF-GT will be similar to those for
   OSPFv2 [RFC2328] and OSPFv3 [RFC5340].  However, since OSPF-GT is not
   used to update OSPF routing, the consequences of attacks will be
   dependent on advertised non-routing information.

I would actually argue that security considerations of p2p remote neighbors
are actually quite different from security considerations of flooding data.

Along the same lines security is not about protecting your routing ... it
is much more about protecting the entire network by exposing critical
information externally to non authorized parties.

D) Are there any PUB-SUB options possible for OSPF-GT ?

E) Is there any filtering possible for OSPF-GT ?

F) Are you envisioning use of OSPF-GT proxies and if so are you planning to
add this to the document ?

G) How are you going to address Receivers which do not support OSPF-GT
parser ?

H) As you know many operators are attracted to BGP-LS based on the fact
that it offers the same view of information irrespective of what is the
protocol producing the data. Is there some thought on such normalization in
the OSPF-GT proposal ?

I) What's the take of OSPF-GT draft authors on the YANG model in respect of
using it for normalization of exported data ?

To summarize IMHO we should not stretch routing protocols be it OSPF, ISIS
or BGP to be messengers of link state data running and to artificially
force them to run in a point-to-point model between router and controller.

Kind regards,
Robert


On Sun, Jul 10, 2022 at 7:04 AM Yingzhen Qu  wrote:

> Hi,
>
> Since we’re discussing possible solutions, I’d like to bring up the draft:
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-transport-instance/
>
> We just submitted a new version. The name of the document is changed to
> “OSPF-GT (Generalized Transport)”, and a use case is added to use OSPF-GT
> as a possible replacement of BGP-LS.
>
> Note: OSPF-GT is not traditional OSPF, and it’s not used to calculate
> routes. It uses the reachability info calculated by routing protocols,
> OSPF, ISIS or static routing etc.. It provides mechanisms to advertise
> non-routing information, and remote neighbor is supported.
>
> Reviews and comments are welcome.
>
>
> Thanks,
> Yingzhen
>
> On Jul 9, 2022, at 5:33 PM, Gyan Mishra  wrote:
>
>
> During the interim meeting we should keep it open to discuss all possible
> alternatives to BGP-LS.
>
> Thanks
>
> Gyan
>
> On Sat, Jul 9, 2022 at 4:45 PM Susan Hares  wrote:
>
>> Jeff:
>>
>>
>>
>> An interim sounds like a good plan.
>>
>>
>>
>> [IDR-chair hat]
>>
>> Alvaro has indicated that since all of the proposal received on the IDR
>> list are new protocol proposals,
>>
>>- Capturing IDR’s input on BGP-LS problems and potential solutions is
>>appropriate for IDR as BGP-LS home.
>>- Refining any potential non-BGP solutions is outside of the scope of
>>IDR.
>>
>>
>>
>> [IDR-chair hat off]
>>
>> [rtgwg WG member]
>>
>> I’d love to attend an interim on this topic.
>>
>>
>>
>> Sue Hares
>>
>>
>>
>>
>>
>> *From:* Jeff Tantsura 
>> *Sent:* Saturday, July 9, 2022 3:40 PM
>> *To:* Robert Raszuk 
>> *Cc:* Acee Lindem (acee) ; lsr ;
>> i...@ietf.org; Susan Hares ; grow@ietf.org grow@ietf.org
>> 
>> *Subject:* Re: [Idr] [Lsr] IGP Monitoring Protocol
>>
>>
>>
>>
>>
>> Speaking as RTGWG chair:
>>
>>
>>
>> Robert - I don’t think we’d have enough time to accommodate a good
>> discussion during IETF114 (we got only 1 slot), however would be happy to
>> provide a platform for an interim.
>>
>> The topic is important and personally (being a very large BGP-LS user)
>> I’d like to see it progressing.
>>
>> Cheers,
>>
>> Jeff
>>
>>
>>
>> On Jul 8, 2022, at 14:44, Robert Raszuk  wrote:

Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol

[Robert Raszuk]

ns at the DATA
Types. That IMO is an IMP property. I agree that what specific elements are
sent can be done with the NETCONF/RESTCONF mechanism.

For now I refrained from adding this to the spec. Only added top level TLV
filters.

Said this I am very open to follow your above recommendation for YANG DATA
Types and need for more granular subscriptions. But I think I would rather
see this applicable to Producer's Proxies not Producers directly. Just
trying to keep Producers as light as possible as not all RP/RE can handle
too much of such load.


> Regarding the terminology of "Producer" and "Receiver". I suggest to align
> the wording with existing Network Telemetry (RFC 9232) protocols.
> Unfortunately they aren't aligned among at all even though they are doing
> more or less all the same. Exporting monitoring data to a data collection.
> My personal favorite is Exporting and Collecting Process.
>
>
>
> IPFIX:   Exporting Process, Collecting Process
>
> BMP: Management Station, Monitoring Station
>
> YANG push:   Publisher, Receiver
>
> IMP:  Producer, Receiver
>

I used the Producer term as this is how some implementations call its
components. The receivers are Clients.

But if we think that "Publisher" term is a better fit I have no issue
renaming it such. Receiver could stay as is or could be called Client too.

Many thx and thank you again for your review and excellent comments.

Robert



>
>
> Best wishes
>
> Thomas
>
>
>
> *From:* GROW  *On Behalf Of *Robert Raszuk
> *Sent:* Saturday, July 9, 2022 9:49 PM
> *To:* Jeff Tantsura 
> *Cc:* lsr ; grow@ietf.org grow@ietf.org ;
> idr@ietf. org 
> *Subject:* Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol
>
>
>
> Thx Jeff !
>
>
>
> Also I welcome more reviews and suggestions for additions or deletions of
> parts of it. For now I tried to keep it very simple for routers -
> essentially setup new p2p TCP or QUIC sessions and send over exactly what
> you put in BGP today. In the same time I see use cases beyond that so added
> few optional more DATA Types.
>
>
>
> With basic DATA Types 1 or 2 there is zero changes needed on the receivers
> - some folks told me this is huge advantage.
>
>
>
> Then two optional messages REQUEST and FILTER provide ability for trimming
> excessive data either on the Producer or Producer's Proxy.
>
>
>
> Many thx,
>
> Robert
>
>
>
>
>
> On Sat, Jul 9, 2022 at 9:39 PM Jeff Tantsura 
> wrote:
>
> Speaking as RTGWG chair:
>
>
>
> Robert - I don’t think we’d have enough time to accommodate a good
> discussion during IETF114 (we got only 1 slot), however would be happy to
> provide a platform for an interim.
>
> The topic is important and personally (being a very large BGP-LS user) I’d
> like to see it progressing.
>
> Cheers,
>
> Jeff
>
>
>
> On Jul 8, 2022, at 14:44, Robert Raszuk  wrote:
>
> 
>
> Hi Acee,
>
>
>
> Yes, by all means input from the operator's community is needed. It can be
> collected through LSR WG, IDR WG or GROW WG. RTGWG could also contribute.
> We have already seen input from some operators and their opinion on adding
> and distributing more and more link state protocol and topology data in
> BGP. More such input is very welcome.
>
>
>
> And to your point about RFC9086 - I see nothing wrong in keeping BGP
> information in BGP. So IGP Monitoring Protocol does not target to shut down
> BGP-LS. It only aims to remove 100% of non BGP sourced information from it.
>
>
>
> Controllers which today listen to BGP-LS need a number of information
> sources and that spread will only keep increasing as more inputs are
> becoming necessary for its computations.
>
>
>
> Regards,
>
> Robert.
>
>
>
>
>
> On Fri, Jul 8, 2022 at 11:32 PM Acee Lindem (acee)  wrote:
>
> Hi Robert,
>
>
>
> *From: *Robert Raszuk 
> *Date: *Friday, July 8, 2022 at 4:36 PM
> *To: *Acee Lindem 
> *Cc: *lsr , IDR List , Susan Hares <
> sha...@ndzh.com>
> *Subject: *Re: [Lsr] IGP Monitoring Protocol
>
>
>
> Hi Acee,
>
>
>
> Thank you. I was not planning to present it in the upcoming IETF.
>
>
>
> > Let’s see how many stakeholders actually want to this protocol - then we
> can talk about a WG home.
>
>
>
> An alternative approach could be to see how many stakeholders do not want
> to further (for no good reason) to trash BGP. That to me would be in this
> specific case a much better gauge.
>
>
>
> In that case, it seems to me that this discussion should be relegated to
> IDR. Note that there is already non-IGP informatio

Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol

[Robert Raszuk]

Thx Jeff !

Also I welcome more reviews and suggestions for additions or deletions of
parts of it. For now I tried to keep it very simple for routers -
essentially setup new p2p TCP or QUIC sessions and send over exactly what
you put in BGP today. In the same time I see use cases beyond that so added
few optional more DATA Types.

With basic DATA Types 1 or 2 there is zero changes needed on the receivers
- some folks told me this is huge advantage.

Then two optional messages REQUEST and FILTER provide ability for trimming
excessive data either on the Producer or Producer's Proxy.

Many thx,
Robert


On Sat, Jul 9, 2022 at 9:39 PM Jeff Tantsura 
wrote:

> Speaking as RTGWG chair:
>
> Robert - I don’t think we’d have enough time to accommodate a good
> discussion during IETF114 (we got only 1 slot), however would be happy to
> provide a platform for an interim.
> The topic is important and personally (being a very large BGP-LS user) I’d
> like to see it progressing.
>
> Cheers,
> Jeff
>
> On Jul 8, 2022, at 14:44, Robert Raszuk  wrote:
>
> 
> Hi Acee,
>
> Yes, by all means input from the operator's community is needed. It can be
> collected through LSR WG, IDR WG or GROW WG. RTGWG could also contribute.
> We have already seen input from some operators and their opinion on adding
> and distributing more and more link state protocol and topology data in
> BGP. More such input is very welcome.
>
> And to your point about RFC9086 - I see nothing wrong in keeping BGP
> information in BGP. So IGP Monitoring Protocol does not target to shut down
> BGP-LS. It only aims to remove 100% of non BGP sourced information from it.
>
> Controllers which today listen to BGP-LS need a number of information
> sources and that spread will only keep increasing as more inputs are
> becoming necessary for its computations.
>
> Regards,
> Robert.
>
>
> On Fri, Jul 8, 2022 at 11:32 PM Acee Lindem (acee)  wrote:
>
>> Hi Robert,
>>
>>
>>
>> *From: *Robert Raszuk 
>> *Date: *Friday, July 8, 2022 at 4:36 PM
>> *To: *Acee Lindem 
>> *Cc: *lsr , IDR List , Susan Hares <
>> sha...@ndzh.com>
>> *Subject: *Re: [Lsr] IGP Monitoring Protocol
>>
>>
>>
>> Hi Acee,
>>
>>
>>
>> Thank you. I was not planning to present it in the upcoming IETF.
>>
>>
>>
>> > Let’s see how many stakeholders actually want to this protocol - then
>> we can talk about a WG home.
>>
>>
>>
>> An alternative approach could be to see how many stakeholders do not want
>> to further (for no good reason) to trash BGP. That to me would be in this
>> specific case a much better gauge.
>>
>>
>>
>> In that case, it seems to me that this discussion should be relegated to
>> IDR. Note that there is already non-IGP information transported in BGP-LS,
>> e.g., Egress Peer Engineering (https://datatracker.ietf.org/doc/rfc9086/).
>> I implemented this on our data center routers (NXOS) years and it is solely
>> BGP specific.
>>
>>
>>
>> Thanks,
>>
>> Acee
>>
>>
>>
>> Kind regards,
>>
>> Robert
>>
>>
>>
>>
>>
>> On Fri, Jul 8, 2022 at 9:54 PM Acee Lindem (acee)  wrote:
>>
>> Speaking as WG chair:
>>
>>
>>
>> *From: *Lsr  on behalf of Robert Raszuk <
>> rob...@raszuk.net>
>> *Date: *Friday, July 8, 2022 at 3:21 PM
>> *To: *lsr 
>> *Cc: *IDR List , Susan Hares 
>> *Subject: *[Lsr] IGP Monitoring Protocol
>>
>>
>>
>> Dear LSR WG,
>>
>>
>>
>> Based on ongoing discussion in respect to the future of BGP-LS I
>> committed myself to put together an alternate proposal.
>>
>>
>>
>> The main goal is not to just publish a -00 version of the draft using
>> different encapsulation. The goal is to make a useful tool which can help
>> to export link state information from network elements as well as assist in
>> network observability.
>>
>>
>>
>> The IGP Monitoring Protocol (IMP) draft has been posted and should be
>> available at:
>>
>>
>>
>> https://datatracker.ietf.org/doc/draft-raszuk-lsr-imp/
>>
>>
>>
>> One of the key points I wanted to accomplish was full backwards
>> compatibility with TLVs defined for BGP-LS. In parallel other formats
>> (optional) are also supported.
>>
>>
>>
>> The PUB-SUB nature or FILTERING capabilities are in the spec however as
>> noted in the deployment section there is no expectation that this should be
>> supported directly on routers. Conce

Re: [GROW] Proposing a well-known BGP community for Anycast

[Robert Raszuk]

Hi Warren,

Unless I'm misunderstanding this completely, the community doesn't "make" a
> prefix an ANYCAST prefix, it simply **marks** (denotes) it as being used
> for anycast — this is subtle, but important to note, and seems to have
> caused some confusion in discussions. It an informational tag that people
> can use for debugging to to apply policy...
>

At least for me this was obvious from the beginning.


> But, getting back to your question — the smallest v4 prefix you can
> realistically announce[0] on the Internet is a /24, and so the smallest
> granularity you can mark at is the same.
>

And here comes I think need for authors to clarify something. They said
that such marking is going to be used along with NO-EXPORT.

To me this sounds like a hint that what is getting marked are actually more
specific prefixes (maybe more then /24) if you talk to your provider and he
says "It is OK" I will accept.

Thx,
R.

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

Re: [GROW] Proposing a well-known BGP community for Anycast

[Robert Raszuk]

Hi,

While it may sound like I am against it - I am not. I am just trying to
make sure what we ship can actually effectively work.

One key question for example which no one answered so far is this:

If I have one very important service for which I would like to use ANYCAST
address across my geo distributed load balancers does this make my entire
/24 or /22 I advertise any ANYCAST prefix ? I hope not.

100s of hosts within my blocks may use high volume torrent which I really
do not need to ANYCAST at the network/routing layer - I use geo
extensions in the DNS for it.

So just asking simple operational question - when do we mark prefix block
as ANYCAST ?

I think if we are serious about actually helping ANYCASTs perhaps we should
allow to advertise those addresses separate from allocated PI or PA blocks
 For PA it will get aggregated. For PI it will a little bit pollute the
table - I guess this is why the current version of the draft says that
ANYCAST prefixes will be advertised with NO-EXPORT community.

Thx,
R.








On Sat, Jul 9, 2022 at 11:37 AM Alejandro Acosta <
alejandroacostaal...@gmail.com> wrote:

> Hello,
>
>After reading the draft and the comments on the list. I think this is
> going to be useful and will make BGP take better decisions. +1 to move
> this draft forward.
>
>I wonder about the misuse of the community ANYCAST when the prefix
> being announced is not actually an anycast prefix, can be there a kind
> of abuse from some operators?. Do we need -if not out there already- a
> list of public anycasted prefixes (and I believe I have seem this
> question somewhere).
>
>
> Regards,
>
>
> Alejandro,
>
>
> On 5/7/22 5:40 AM, Maximilian Wilhelm wrote:
> > Hey folks,
> >
> > after some discussion at RIPE84 we took the time to formalize a draft
> > to define a well-known BGP community to indicate a given prefix is
> > carrying Anycast traffic. The intent is to allow ISPs to do well
> > informed TE, especially in cases where they want to diverge from the
> > hot potato principle.
> >
> > You can find the draft at
> >
> > https://datatracker.ietf.org/doc/draft-wilhelm-grow-anycast-community/
> >
> > Happy to share this at the upcoming meeting and hear your thoughts!
> >
> > Thanks and best,
> > Max
> >
> > ___
> > 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] [Lsr] IGP Monitoring Protocol

[Robert Raszuk]

Hi Acee,

Yes, by all means input from the operator's community is needed. It can be
collected through LSR WG, IDR WG or GROW WG. RTGWG could also contribute.
We have already seen input from some operators and their opinion on adding
and distributing more and more link state protocol and topology data in
BGP. More such input is very welcome.

And to your point about RFC9086 - I see nothing wrong in keeping BGP
information in BGP. So IGP Monitoring Protocol does not target to shut down
BGP-LS. It only aims to remove 100% of non BGP sourced information from it.

Controllers which today listen to BGP-LS need a number of information
sources and that spread will only keep increasing as more inputs are
becoming necessary for its computations.

Regards,
Robert.


On Fri, Jul 8, 2022 at 11:32 PM Acee Lindem (acee)  wrote:

> Hi Robert,
>
>
>
> *From: *Robert Raszuk 
> *Date: *Friday, July 8, 2022 at 4:36 PM
> *To: *Acee Lindem 
> *Cc: *lsr , IDR List , Susan Hares <
> sha...@ndzh.com>
> *Subject: *Re: [Lsr] IGP Monitoring Protocol
>
>
>
> Hi Acee,
>
>
>
> Thank you. I was not planning to present it in the upcoming IETF.
>
>
>
> > Let’s see how many stakeholders actually want to this protocol - then we
> can talk about a WG home.
>
>
>
> An alternative approach could be to see how many stakeholders do not want
> to further (for no good reason) to trash BGP. That to me would be in this
> specific case a much better gauge.
>
>
>
> In that case, it seems to me that this discussion should be relegated to
> IDR. Note that there is already non-IGP information transported in BGP-LS,
> e.g., Egress Peer Engineering (https://datatracker.ietf.org/doc/rfc9086/).
> I implemented this on our data center routers (NXOS) years and it is solely
> BGP specific.
>
>
>
> Thanks,
>
> Acee
>
>
>
> Kind regards,
>
> Robert
>
>
>
>
>
> On Fri, Jul 8, 2022 at 9:54 PM Acee Lindem (acee)  wrote:
>
> Speaking as WG chair:
>
>
>
> *From: *Lsr  on behalf of Robert Raszuk <
> rob...@raszuk.net>
> *Date: *Friday, July 8, 2022 at 3:21 PM
> *To: *lsr 
> *Cc: *IDR List , Susan Hares 
> *Subject: *[Lsr] IGP Monitoring Protocol
>
>
>
> Dear LSR WG,
>
>
>
> Based on ongoing discussion in respect to the future of BGP-LS I
> committed myself to put together an alternate proposal.
>
>
>
> The main goal is not to just publish a -00 version of the draft using
> different encapsulation. The goal is to make a useful tool which can help
> to export link state information from network elements as well as assist in
> network observability.
>
>
>
> The IGP Monitoring Protocol (IMP) draft has been posted and should be
> available at:
>
>
>
> https://datatracker.ietf.org/doc/draft-raszuk-lsr-imp/
>
>
>
> One of the key points I wanted to accomplish was full backwards
> compatibility with TLVs defined for BGP-LS. In parallel other formats
> (optional) are also supported.
>
>
>
> The PUB-SUB nature or FILTERING capabilities are in the spec however as
> noted in the deployment section there is no expectation that this should be
> supported directly on routers. Concept of Producer's Proxies has been
> introduced to support this added functionality as well as provide fan-out
> (analogy to BGP route reflectors).
>
>
>
> I encourage everyone interested to take a look and provide comments. At
> this point this document is nothing more than my individual submission.
> Offline I have had few conversations with both operators and vendors
> expressing some level of interest in this work. How we proceed further (if
> at all :) depends on WG feedback.
>
>
>
> Kind regards,
>
> Robert.
>
>
>
> PS, I do believe this work belongs in LSR WG pretty squerly.
>
>
>
> Let’s see how many stakeholders actually want to this protocol - then we
> can talk about a WG home.  By stakeholders, I mean operators and vendors
> who are committed to implementing and deploying it - not simply those who
> you are able to enlist as co-authors. Note that our IETF 114 LSR agenda is
> full (with multiple agenda items not making the cut).
>
>
>
> Thanks,
>
> Acee
>
>
>
>
>
>
>
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Proposing a well-known BGP community for Anycast

[Robert Raszuk]

> I do not understand Robert's issues with this community.

Let me say that I like it from operational perspective.

However from routing perspective I have doubts on how this community is
going to be originated and how it is going to be used.

Example 1: Hyperscaler has global POP footprint and is offering anycast
services for its VPCs. So lot's of prefixes are going to be marked as such.
Is the expectations that ISPs will/shall use it ?

Example 2: Enterprise is injecting same prefix from different locations. It
could be anycast or not. Or maybe as mentioned one host route within such
/24 is true anycast. Is ISP suppose to alter their local pref according to
such marking ? Even if there is no really ANYCAST service behind at all ?

Example 3: How do we detect misuse and accidental or purpose marking by
malicious guys in the middle ?

Thx,
R.







On Fri, Jul 8, 2022 at 5:01 PM heasley  wrote:

> Thu, Jul 07, 2022 at 12:21:27PM -0400, Jeffrey Haas:
> >
> >
> > > On Jul 7, 2022, at 11:50 AM, Robert Raszuk  wrote:
> > > But most if not all of those do not affect intradomain traffic
> engineering rules.
> > >
> > > So I think Jeff's point is how much trust is needed to overwrite your
> own
> > > policy in selecting exit points and overwriting your EPE policy, TE
> policy, Local Pref etc ...
> >
> > Exactly.
> >
> > > And I think misuse of those can happen even over direct peerings if
> the overall objective is
> > > to avoid double checking the community against prefix lists.
> >
> > Exactly.
>
> Meaning, please add a note to the security considerations saying don't
> trust
> communities (this one included) from untrusted sources.  See rfc 7999 S6.
>
> What a receiver's policy does with the community (or several other
> well-knowns or another AS'es self-defined) is their decision.  The document
> clearly dictates that a bgp implementation SHOULD NOT (imo MUST NOT) apply
> [automatic] special handling of the community.  I do not understand
> Robert's
> issues with this community.
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Proposing a well-known BGP community for Anycast

[Robert Raszuk]

Hi,

>  the advisory nature of the community is still useful for humans when
looking at the route table.

Yes I fully agree with this.

In fact this is why I asked to exactly describe rules for
attaching/originating it.

Same prefix advertised from different locations in the topology is pretty
common in enterprises. Such prefix can be /24 or /64 or less specific.
There can be one host route within it acting as true anycast host/service.

Thx

On Thu, Jul 7, 2022 at 9:06 PM David Farmer  wrote:

>
>
> On Thu, Jul 7, 2022 at 1:47 PM Robert Raszuk  wrote:
>
>>
>>
>> WHAT? I'm suggesting that you not treat routes with the ANYCAST community
>>> learned from R peers as if they are R routes, but as if they are
>>> normal internet routes.
>>>
>>
>> If this community should be ignored when arriving via some peers then
>> what is the point to keep it in the UPDATE MSG  from those peers ?
>>
>
> I'm not suggesting ignoring the community from R peers, I'm suggesting a
> lower local preference or dropping the route when learned from an R peer.
> Further, regardless of the action taken in your routing policy, or even no
> policy action at all, the advisory nature of the community is still useful
> for humans when looking at the route table.
>
> Thanks
>
>
>> I don't think you want to require or even recommend the removal of the
>>> ANYCAST community at an EBGP boundary.
>>>
>>> Thanks
>>>
>>> On Thu, Jul 7, 2022 at 1:19 PM Robert Raszuk  wrote:
>>>
>>>> Hi David,
>>>>
>>>> Your case works only when subject routes coming over different R
>>>> network would not carry such community. Proposed NO_EXPORT does not help as
>>>> it would block advertisement of the entire prefix marked as such.
>>>>
>>>> So to fulfil your observation the draft should perhaps suggest that
>>>> ANYCAST community SHOULD (or maybe even MUST) be removed when propagating
>>>> routes over egress EBGP (from the perspective of first upstream transit).
>>>>
>>>> Many thx,
>>>> R.
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Jul 7, 2022 at 8:08 PM David Farmer >>> 40umn@dmarc.ietf.org> wrote:
>>>>
>>>>> I think this is a useful proposal and I support it moving forward.
>>>>>
>>>>> Another use case;
>>>>>
>>>>> In the Research and Education (R) networking community, it is
>>>>> commonplace to set a higher local preference for routes learned from
>>>>> another R network, on the premise that these R paths will be higher
>>>>> bandwidth and/or lower congestion, even if the AS-Path is longer. However,
>>>>> if an Anycast prefix is included by another R network this can result in
>>>>> preferring a remote version of an Anycast service over a more local 
>>>>> version
>>>>> of the same Anycast service.  In this scenario, it is not uncommon for the
>>>>> remote Anycast service to be very remote, such as on a different 
>>>>> continent,
>>>>> thereby defeating the purpose of Anycast. This community would easily 
>>>>> allow
>>>>> these Anycast prefixes to either be set to normal (default) local
>>>>> preference, to be set to a lower local preference than normal assuming 
>>>>> they
>>>>> will be remote, or even to drop the remote Anycast route altogether
>>>>> assuming they will. be very remote.
>>>>>
>>>>> Related to the trust discussion, I will note; that using this
>>>>> community to signal a lower preference for, or even dropping, a remote
>>>>> Anycast route is less of a trust issue than using the community to signal 
>>>>> a
>>>>> higher preference for a local Anycast route. That is if the community is
>>>>> used to demote routes, it is less likely to be abused by someone seeking 
>>>>> to
>>>>> increase traffic toward them.
>>>>>
>>>>> Thanks.
>>>>>
>>>>>
>>>>> On Tue, Jul 5, 2022 at 5:40 AM Maximilian Wilhelm 
>>>>> wrote:
>>>>>
>>>>>> Hey folks,
>>>>>>
>>>>>> after some discussion at RIPE84 we took the time to formalize a draft
>>>>>> to define a well-known BGP community to indicate a given prefix is
>>>>>> carrying Anycast traff

Re: [GROW] Proposing a well-known BGP community for Anycast

[Robert Raszuk]

WHAT? I'm suggesting that you not treat routes with the ANYCAST community
> learned from R peers as if they are R routes, but as if they are
> normal internet routes.
>

If this community should be ignored when arriving via some peers then what
is the point to keep it in the UPDATE MSG  from those peers ?

Thx,
R.




> I don't think you want to require or even recommend the removal of the
> ANYCAST community at an EBGP boundary.
>
> Thanks
>
> On Thu, Jul 7, 2022 at 1:19 PM Robert Raszuk  wrote:
>
>> Hi David,
>>
>> Your case works only when subject routes coming over different R
>> network would not carry such community. Proposed NO_EXPORT does not help as
>> it would block advertisement of the entire prefix marked as such.
>>
>> So to fulfil your observation the draft should perhaps suggest that
>> ANYCAST community SHOULD (or maybe even MUST) be removed when propagating
>> routes over egress EBGP (from the perspective of first upstream transit).
>>
>> Many thx,
>> R.
>>
>>
>>
>>
>> On Thu, Jul 7, 2022 at 8:08 PM David Farmer > 40umn@dmarc.ietf.org> wrote:
>>
>>> I think this is a useful proposal and I support it moving forward.
>>>
>>> Another use case;
>>>
>>> In the Research and Education (R) networking community, it is
>>> commonplace to set a higher local preference for routes learned from
>>> another R network, on the premise that these R paths will be higher
>>> bandwidth and/or lower congestion, even if the AS-Path is longer. However,
>>> if an Anycast prefix is included by another R network this can result in
>>> preferring a remote version of an Anycast service over a more local version
>>> of the same Anycast service.  In this scenario, it is not uncommon for the
>>> remote Anycast service to be very remote, such as on a different continent,
>>> thereby defeating the purpose of Anycast. This community would easily allow
>>> these Anycast prefixes to either be set to normal (default) local
>>> preference, to be set to a lower local preference than normal assuming they
>>> will be remote, or even to drop the remote Anycast route altogether
>>> assuming they will. be very remote.
>>>
>>> Related to the trust discussion, I will note; that using this community
>>> to signal a lower preference for, or even dropping, a remote Anycast route
>>> is less of a trust issue than using the community to signal a higher
>>> preference for a local Anycast route. That is if the community is used to
>>> demote routes, it is less likely to be abused by someone seeking to
>>> increase traffic toward them.
>>>
>>> Thanks.
>>>
>>>
>>> On Tue, Jul 5, 2022 at 5:40 AM Maximilian Wilhelm 
>>> wrote:
>>>
>>>> Hey folks,
>>>>
>>>> after some discussion at RIPE84 we took the time to formalize a draft
>>>> to define a well-known BGP community to indicate a given prefix is
>>>> carrying Anycast traffic. The intent is to allow ISPs to do well
>>>> informed TE, especially in cases where they want to diverge from the
>>>> hot potato principle.
>>>>
>>>> You can find the draft at
>>>>
>>>> https://datatracker.ietf.org/doc/draft-wilhelm-grow-anycast-community/
>>>>
>>>> Happy to share this at the upcoming meeting and hear your thoughts!
>>>>
>>>> Thanks and best,
>>>> Max
>>>>
>>>> ___
>>>> 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
>>>
>>
>
> --
> ===
> 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] Proposing a well-known BGP community for Anycast

[Robert Raszuk]

Hi David,

Your case works only when subject routes coming over different R  network
would not carry such community. Proposed NO_EXPORT does not help as it
would block advertisement of the entire prefix marked as such.

So to fulfil your observation the draft should perhaps suggest that ANYCAST
community SHOULD (or maybe even MUST) be removed when propagating routes
over egress EBGP (from the perspective of first upstream transit).

Many thx,
R.




On Thu, Jul 7, 2022 at 8:08 PM David Farmer 
wrote:

> I think this is a useful proposal and I support it moving forward.
>
> Another use case;
>
> In the Research and Education (R) networking community, it is
> commonplace to set a higher local preference for routes learned from
> another R network, on the premise that these R paths will be higher
> bandwidth and/or lower congestion, even if the AS-Path is longer. However,
> if an Anycast prefix is included by another R network this can result in
> preferring a remote version of an Anycast service over a more local version
> of the same Anycast service.  In this scenario, it is not uncommon for the
> remote Anycast service to be very remote, such as on a different continent,
> thereby defeating the purpose of Anycast. This community would easily allow
> these Anycast prefixes to either be set to normal (default) local
> preference, to be set to a lower local preference than normal assuming they
> will be remote, or even to drop the remote Anycast route altogether
> assuming they will. be very remote.
>
> Related to the trust discussion, I will note; that using this community to
> signal a lower preference for, or even dropping, a remote Anycast route is
> less of a trust issue than using the community to signal a higher
> preference for a local Anycast route. That is if the community is used to
> demote routes, it is less likely to be abused by someone seeking to
> increase traffic toward them.
>
> Thanks.
>
>
> On Tue, Jul 5, 2022 at 5:40 AM Maximilian Wilhelm  wrote:
>
>> Hey folks,
>>
>> after some discussion at RIPE84 we took the time to formalize a draft
>> to define a well-known BGP community to indicate a given prefix is
>> carrying Anycast traffic. The intent is to allow ISPs to do well
>> informed TE, especially in cases where they want to diverge from the
>> hot potato principle.
>>
>> You can find the draft at
>>
>> https://datatracker.ietf.org/doc/draft-wilhelm-grow-anycast-community/
>>
>> Happy to share this at the upcoming meeting and hear your thoughts!
>>
>> Thanks and best,
>> Max
>>
>> ___
>> 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
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Proposing a well-known BGP community for Anycast

[Robert Raszuk]

Hi,

As you mention we already have
> other community out there which you need to trust to act on them,
> being it NO_EXPORT / NO_ADVERTISE, BLACKHOLE (usally filtered against
> a prefix-list), or any advisory community from IXPs and ISPs.
>

But most if not all of those do not affect intradomain traffic engineering
rules.

So I think Jeff's point is how much trust is needed to overwrite your own
policy in selecting exit points and overwriting your EPE policy, TE policy,
Local Pref etc ...

And I think misuse of those can happen even over direct peerings if the
overall objective is
to avoid double checking the community against prefix lists.

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

Re: [GROW] Proposing a well-known BGP community for Anycast

[Robert Raszuk]

Hello Max,

Ad 1 - Apologies for not being clear. I meant the case (pretty common case)
where I advertise the same /24 from two distinct sites. The fact that those
sites are connected internally on the DMZ side should play no difference to
how we attack traffic from outside. Would you agree?

> 2. Are you proposing to make any changes to best path selection based on
> > the presence of the specified community ?
>
> No. The intention is to only allow operators to influence best path
> selection by means of import/export policies if they deem that a good
> idea.
>

Oh I see. So essentially you are saying that ANYCAST marked paths should
not be suppressed on ingress. If so I am not sure if they are ever
suppressed on ingress. Only on egress if they are coming from PA space. But
that's not really interesting case since you recommend to mark them with
NO-EXPORT anyway.

> 4. Or alternatively to #3 are you suggesting to always use ADD-PATHS ALL
> > for all prefixes marked with ANYCAST community ?
>
> In the RR case I presume? If so that could be an option which could
> make sense to add to the proposal as one option. I'm not sure if a
> general suggestion could be given here.
>

You could list it in your draft as one possible use case. Which is in the
event of no ADD_PATH ALL setting to make them still ALL if marked with
ANYCAST community.

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

Re: [GROW] Proposing a well-known BGP community for Anycast

[Robert Raszuk]

Hi Max,

Thank you for publishing this draft. I have few questions after reading it.

1. If I have /24 and I advertise it over N peerings N>1 to my ISP from my
DMZ does it automatically become ANYCAST prefix ?

1a. Note that I may have just one real host route in this /24 which I
consider a true anycast destination.

2. Are you proposing to make any changes to best path selection based on
the presence of the specified community ?

3. As I am sure you realize hot-potato or not-so-hot-potato routing is the
result of choosing a best paths with a given next hop. Consideration of
correct metric to this next hop is what makes it hot or not. Now with the
use of route reflection where RRs are not in the data path that metric is
normally fake (possibly hot from perspective of RR but not necessarily hot
from the perspective of the client) . That is why I wrote RFC9107 (
https://datatracker.ietf.org/doc/rfc9107/) to allow to use the correct
metric. Are mandating use of such tools for prefixes marked with ANYCAST
community ?

4. Or alternatively to #3 are you suggesting to always use ADD-PATHS ALL
for all prefixes marked with ANYCAST community ?

Bottom line you have written good justification why such marking makes
sense. But currently draft is missing more description when to mark when
advertising given prefix over eBGP sessions (redundant advertisement is a
norm these days). There is also no description on expected BGP
implementation behavior when such prefixes marked with ANYCAST community
are received by BGP speaker.

Many thx,
R.




On Tue, Jul 5, 2022 at 12:40 PM Maximilian Wilhelm  wrote:

> Hey folks,
>
> after some discussion at RIPE84 we took the time to formalize a draft
> to define a well-known BGP community to indicate a given prefix is
> carrying Anycast traffic. The intent is to allow ISPs to do well
> informed TE, especially in cases where they want to diverge from the
> hot potato principle.
>
> You can find the draft at
>
> https://datatracker.ietf.org/doc/draft-wilhelm-grow-anycast-community/
>
> Happy to share this at the upcoming meeting and hear your thoughts!
>
> Thanks and best,
> Max
>
> ___
> 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] [Sidrops] IXP Route Server question

[Robert Raszuk]

Right - but IMO route leaking can happen both in the Internet or in
customer <- via IXP -> content provider interconnects.

And in the latter case - especially for those with open peering policy -
often going via RS. After all this is how route servers are mainly used
today :) So both sides will be peering to IXP RS while IXP RS will (in most
cases) not appear in the AS_PATH.

Kind regards,
R.



On Tue, Mar 8, 2022 at 9:26 PM Christopher Morrow <
christopher.mor...@gmail.com> wrote:

>
>
> On Tue, Mar 8, 2022 at 3:15 PM Robert Raszuk  wrote:
>
>> Well I think the answer is - it depends.
>>
>> First IXP fabric can be used as pure L3 share LAN or can be used (and it
>> is often the case) as a p2p emulated VLAN over such L3 shared LAN.
>>
>> Now if this is L3 shared LAN still customer and ISP may peer directly and
>> no third party traffic would be accepted at either end.
>>
>> If we talk about emulating L2 IXP fabric becomes just an emulated circuit
>> and from the perspective of routing it a p2p interface.
>>
>> Sure the other aspects of the IXP quality, port monitoring,
>> oversubscription etc... always will apply but there are ways to mitigate or
>> handle those in real IXPs.
>>
>>
> I don't dispute your content here, except that Sriram's question was about
> seeing 'customer routes via the RS'... which I think would obviate the
> emulation examples you provided.
> (well in a bunch of cases it would, you COULD hook up some tomfoolery to
> get this to work, but... that sounds complex and prone to disaster)
>
>
>> Best,
>> R.
>>
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Mar 8, 2022 at 9:05 PM Christopher Morrow <
>> christopher.mor...@gmail.com> wrote:
>>
>>>
>>>
>>> On Tue, Mar 8, 2022 at 2:36 PM Sriram, Kotikalapudi (Fed)
>>>  wrote:
>>>
>>>> This question has relevance to the ASPA method for route leak detection.
>>>>
>>>> Is it possible that an ISP AS A peers with a customer AS C via a
>>>> non-transparent IXP AS B?
>>>> IOW, the AS path in routes propagated by the ISP A for customer C's
>>>> prefixes looks like this:  A B C.
>>>> I.e., can the AS of a non-transparent IXP/RS appear in an AS path in
>>>> the middle between an ISP and its customer?
>>>>
>>>>
>>> it seems unlikely to me that an ISP would pick up a 'customer' (someone
>>> that pays them to transport packets) at an IXP fabric.
>>> Might it happen? sure? is it messy? yes!
>>>
>>> 1) that's probably a shared port
>>> 2) there are other folk feeding routes and packets into the mix
>>> 3) how many came through the 'customer' port (which you can't really
>>> know easily) vs other participants on the ix
>>> 4) what capacity planning could the 'customer' do here? (none, basically
>>> with respect to the remote ISP port)
>>>
>>> Your question might work also as:
>>>   "ISP A has a customer C on a direct link in location Y.
>>>ISP A is present at IXP-Z, so is customer C, though they do not
>>> bilaterally peer (not do they interconnect at the IXP).
>>>   ISP A can still see Customer C's routes through the IXP-Z Route
>>> Server."
>>>
>>> that seems plausible, but not a desired outcome for the ISP :) since
>>> they will be unlikely to collect pesos for the traffic
>>> which MAY pass across that interconnect.
>>>
>>> ___
>>> 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] [Sidrops] IXP Route Server question

[Robert Raszuk]

Well I think the answer is - it depends.

First IXP fabric can be used as pure L3 share LAN or can be used (and it is
often the case) as a p2p emulated VLAN over such L3 shared LAN.

Now if this is L3 shared LAN still customer and ISP may peer directly and
no third party traffic would be accepted at either end.

If we talk about emulating L2 IXP fabric becomes just an emulated circuit
and from the perspective of routing it a p2p interface.

Sure the other aspects of the IXP quality, port monitoring,
oversubscription etc... always will apply but there are ways to mitigate or
handle those in real IXPs.

Best,
R.








On Tue, Mar 8, 2022 at 9:05 PM Christopher Morrow <
christopher.mor...@gmail.com> wrote:

>
>
> On Tue, Mar 8, 2022 at 2:36 PM Sriram, Kotikalapudi (Fed)
>  wrote:
>
>> This question has relevance to the ASPA method for route leak detection.
>>
>> Is it possible that an ISP AS A peers with a customer AS C via a
>> non-transparent IXP AS B?
>> IOW, the AS path in routes propagated by the ISP A for customer C's
>> prefixes looks like this:  A B C.
>> I.e., can the AS of a non-transparent IXP/RS appear in an AS path in the
>> middle between an ISP and its customer?
>>
>>
> it seems unlikely to me that an ISP would pick up a 'customer' (someone
> that pays them to transport packets) at an IXP fabric.
> Might it happen? sure? is it messy? yes!
>
> 1) that's probably a shared port
> 2) there are other folk feeding routes and packets into the mix
> 3) how many came through the 'customer' port (which you can't really know
> easily) vs other participants on the ix
> 4) what capacity planning could the 'customer' do here? (none, basically
> with respect to the remote ISP port)
>
> Your question might work also as:
>   "ISP A has a customer C on a direct link in location Y.
>ISP A is present at IXP-Z, so is customer C, though they do not
> bilaterally peer (not do they interconnect at the IXP).
>   ISP A can still see Customer C's routes through the IXP-Z Route Server."
>
> that seems plausible, but not a desired outcome for the ISP :) since they
> will be unlikely to collect pesos for the traffic
> which MAY pass across that interconnect.
>
> ___
> 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] BGP Looking Glass Capability

[Robert Raszuk]

Rayhaan,

Thank you for the presentation.

Homework from your session and discussion @ GROW (including some side
discussions) is that I will follow up with Operational Message and
perhaps try to get 2nd implementation for it. With that it may just catch
momentum and your and few other needs may start to see the light at the end
of the tunnel.

Cheers,
R.


On Wed, Jul 28, 2021 at 1:01 AM Rayhaan Jaufeerally (IETF) 
wrote:

> Thanks for the feedback here and in the session,
>
> I agree that using AFI / MP is a hack and would be better served by an
> operational style message. I'm not sure how to take that work and adapt it
> to carry the information for communicating route rejection based on policy.
> I guess it would be a new draft and cite the operational message in the
> acknowledgements?
>
> My key takeaways from the discussion in the meeting:
>
>
>- The problem that is to be solved is: "Did the peer accept a route
>which a speaker sent".
>   - Explicitly say forwarding routes to other peers is out of scope
>   because that depends on other factors that not all networks want to 
> share
>   - A looking glass does not actually show the state of the RIB of
>   the peering router, because provider architectures send the routes from 
> the
>   ASBR through other internal mechanisms before showing up on the looking
>   glass, and as such looking at the LG, it's not clear or not visible at 
> all
>   what happened to a particular route.
>   - It's cleaner to flip the problem statement around: "Did a route
>   that a peer sent get rejected (i.e. not imported to the local RIB or
>   considered as a viable path) for some policy reason?".
>- There is also value in collecting looking glass addresses, but
>that's out of scope of what this discussion is about, maybe some kind of
>DNS SRV record on the peering router's IP or something but look into that
>separately.
>
> Cheers,
> Rayhaan
>
> On Tue, Jul 27, 2021 at 11:25 PM Thomas Mangin <
> thomas.man...@exa-networks.co.uk> wrote:
>
>> Hello everyone,
>>
>> While quite a few drafts have been using attributes to carry weird
>> information into BGP, this one proposes to use MP.
>> I can see how one may think it would be helpful and reduce implementation
>> burgen but I am not sure it is wise and I believe it goes beyond what
>> AFI/SAFI are for.
>>
>> Also this reminds me very much of
>> https://datatracker.ietf.org/doc/html/draft-ietf-idr-operational-message
>> which I implemented but never saw traction.
>> So while I can see why this would benefit operational matters, I do not
>> believe the RFC as proposed should be accepted.
>>
>> Sorry for being such a party pooper !
>>
>> Thomas
>>
>> On Sat, 24 Apr 2021 at 14:38, Rayhaan Jaufeerally (IETF) 
>> wrote:
>>
>>> Dear GROW chairs and participants,
>>>
>>> I would like to propose draft-jaufeerally-bgp-lg-cap-00 (
>>> https://datatracker.ietf.org/doc/draft-jaufeerally-bgp-lg-cap/) as a
>>> mechanism for in-band dissemination of looking glass endpoints in BGP,
>>> using a new OPEN message capability.
>>>
>>> The rationale behind this is to facilitate automation around eBGP
>>> peering, for example  to make it possible to automatically detect if the
>>> peer has accepted some routes which are expected to be accepted.
>>>
>>> I'm aware that the underlying RFC8522 is an informational RFC and leaves
>>> some details unspecified for the response format (i.e. a schema for the
>>> queries/responses) but I believe that can be further refined in other works
>>> independent to this proposal.
>>>
>>> I would like to hear what the WG thinks, if this is a reasonable
>>> proposal which fits into the broader charter of GROW?
>>>
>>> Thanks,
>>> Rayhaan
>>> ___
>>> 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] BGP Looking Glass Capability

[Robert Raszuk]

Hi,

I think Nick meant API to query the local BGP RIB of the router itself not
the LG.

For DNS domain there are couple of options. For example we could
register new root domain .bgp which would be reserved to be allocated
automatically with well known names like ASN.bgp by RIR which allocates
ASN.

Then lg.[ASN].bgp would be what you are looking for.


> The in-band approach solves this by having the BGP speaker forward the LG
address of peers that announcements have been forwarded to.

Sorry but I assume you know your peers and their ASNs. So not sure I get
the benefit of same session (not even guaranteed) autodiscovery. Besides in
looking glass you normally do not have access to specific ASBR's RIB ...
maybe POP. If so I assume you know which POP to check.

Do you rather mean that you want to autodiscover your peer's POP and in the
case of LG per POP you want to get specific Looking Glass server address
serving that POP ?

Keep in mind that accepting the announcement does not mean it is going to
be used in forwarding or propagated by BGP upstream. If you are looking for
the assurance of the latter I would rather use data plane tools with wisely
chosen src address of say enhanced trace to make sure what you announced is
installed and used by the peer.

Cheers,
R,


On Mon, Jul 26, 2021 at 2:03 PM Rayhaan Jaufeerally (IETF) 
wrote:

> I totally agree that an API for programmatically querying the LG would be
> the next step on the road to implementing the overall goal, but I picked
> this smaller task of discovering the looking glass first, before designing
> the broader ecosystem.
>
> I thought of the following concerns when evaluating the DNS approach (I
> think it's been discussed earlier too):
>
>- You need to have some DNS zone for the AS, and there's no guarantee
>that AS 65534 can get a domain like as65534.net
>- You could use something like reverse DNS zones in in-addr.arpa for
>example to map the IP of the ASBR to an SRV record or something, but
>   - That requires a coordination between the DNS zone management and
>   looking glass / BGP operations, and in larger organizations it might be
>   more work to set that up which I fear will impede adoption,
>- In the DNS approach you don't know to which peers a route
>announcement was forwarded to, so how would you then know which ASes to
>look up the looking glass for? The in-band approach solves this by having
>the BGP speaker forward the LG address of peers that announcements have
>been forwarded to. That way the downstream AS can discover which upstream
>peers exist and query the LG and probe reachability that way,
>
> I think the last point is the most concerning for me, the fact that it's
> all self contained is more of a nice to have, but I think not knowing
> programatically what peers announcements are being forwarded to would limit
> the usefulness of the DNS approach, I'm happy to be convinced otherwise
> though :).
>
> Cheers,
> Rayhaan
>
> On Mon, Jul 26, 2021 at 11:31 AM Nick Hilliard  wrote:
>
>> Robert Raszuk wrote on 26/07/2021 00:04:
>> > I am still not sure what is wrong using DNS for this type of discovery.
>> > If I were to tackle this problem I would start with DNS.
>>
>> ^^^ this, but I'm not convinced that dynamic discovery of LG endpoints
>> is a pressing issue to start with.  What's more important is a
>> functional API which can retrieve the rib info dynamically (netconf or
>> otherwise).
>>
>> Nick
>>
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] BGP Looking Glass Capability

[Robert Raszuk]

Hi,

Just few comments:

Ah I just realized that you mention SAFI here, but when writing the draft I
> was thinking about an AFI.
>

To define a new MP_REACH you need both AFI (two octets) + SAFI (1 octet)
RFC 4760 section 2.

interface, so it does not need to be advertised in band. Now you mentioned
> it though, it seems that actually using the proper AFI set (e.g. IPv4 or
> IPv6 etc) and then using a new SAFI to carry the looking glass address
> would be an elegant design too.
>

You mean that address of the same LG would be send over AFI=1/SAFI=LG to
send IPv4 address and AFI=2/SAFI=LG to send given LG's IPv6 address ? Looks
ok if you want to really negotiate two capabilities for that.


>  For example, I can imagine looking glass reachability can use MP_REACH
> and then when the looking glass is no longer reachable it can be withdrawn
> with MP_UNREACH, without needing to add that complexity into the looking
> glass message itself.
>

Typically in BGP we try to shield the world from say switch flap given
server is connected to.  Sending host routes all over the place - while
doable - I am not sure will be best for protocol stability.

I am still not sure what is wrong using DNS for this type of discovery. If
I were to tackle this problem I would start with DNS.

Say your draft will define a well known name  ASN-LG (example: 6939-lg) .
Then each AS willing to play the game will just push the current IP
address(es) into such well known DNS record so anyone can get seamlessly to
their looking glasses pool. Done.

And this does not require any extension to BGP :) Moreover such draft can
be worked on and published by GROW WG too.

Interesting, I hadn't considered this type of architecture where there is a
> centralized looking glass that is fed from the border routers.
>

Well I am sure there is a lot of such collectors in the wild. Maybe we also
have as you say just type of jump hosts where under the hood when you query
LG a box get's to production box to get the info live. And even so maybe it
would log into POP's RR not ASBR so the requirement of best external still
applies.

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

Re: [GROW] BGP Looking Glass Capability

[Robert Raszuk]

Dear Rayhaan,

Thank you for working on this draft.

As far as your suggestion to use new SAFI to auto discover presence and
addresses of Looking Glass servers across ASN boundaries I have
nothing against.

As you know the alternative to exchange this type of information would be
via defining a new BGP Message (just like we ddi this in the past in case
of BGP Operational Message). But here perhaps you want to propagate this
beyond single ASN peer so new SAFI may work better.

I however have one major concern on how are Looking Glasses going to help
to address your original problem ie. to check if my prefix was announced
and accepted by peering AS.

Note that ASBRs normally send only best paths. If best path was learned
over IBGP (tie breaker was Local Pref or MED) ASBR may receive and accept
your route, but that route would not be advertised to LGs.

The natural solution here is use of best external and add-paths to make
sure LGs really get all received and accepted paths for a given net - but I
am not sure how common that is deployed today on sessions between ASBRs and
LGs. Last time I checked LGs get peering with RRs and get RR paths. Even
with add-path there and no best external your original issue would not be
solved.

So I would recommend that we review this point before focusing more on LG
auto discovery mechanics. Btw this draft if progressing should be IMO
discussed in IDR and changed to Standards Track. But GROW is an excellent
forum to first make sure if the entire idea proposed here is sound enough.

Best,
R.








On Sun, Jul 25, 2021 at 9:24 PM Rayhaan Jaufeerally (IETF) 
wrote:

> Dear GROW WG,
>
> Following the feedback previously on my looking glass draft proposal, I've
> updated the looking glass draft (
> https://datatracker.ietf.org/doc/draft-jaufeerally-bgp-lg-cap/), to move
> away from a capability mechanism to a new AFI which uses the MP_REACH and
> MP_UNREACH messages in the BGP multiprotocol specification (
> https://datatracker.ietf.org/doc/html/rfc4760) to carry an administrative
> message. This administrative message is then defined to have a payload type
> that carries a URL for the looking glass (LG), as well as the ASN that is
> operating the LG.
>
> The advantage of this approach is that it allows for propagating the LGs
> of upstream peers so leaf ASes can check prefix reachability in peers not
> directly connected.
>
> Looking at the development of the idea, I think it could make sense to
> split the document into one for the administrative message and AFI, and
> another for the looking glass message type within that.
>
> I will present an overview of the draft and the expected use cases during
> the upcoming GROW meeting at IETF111, so feel free to either comment here
> or ask a question in the session if you have any feedback.
>
> Thanks,
> Rayhaan
>
>
>
> On Tue, Apr 27, 2021 at 1:29 PM Job Snijders  wrote:
>
>> On Mon, Apr 26, 2021 at 01:16:55AM +0200, Rayhaan Jaufeerally (IETF)
>> wrote:
>> > > Consistent API that serves RIB data
>> >
>> > Initially I tried to avoid defining the exact API of the looking glass
>> by
>> > pointing to https://tools.ietf.org/html/rfc8522, but unfortunately it
>> does
>> > not strictly define the response format instead leaving it up to the
>> > implementation what to return to queries, which IMO is not very useful
>> for
>> > automation.
>> >
>> > As y'all have pointed out there is a wealth of implementations out there
>> > that have tried to address this (and adding some others I've found):
>> >
>> >- Paolo's pmacct looking glass document:
>> >
>> https://github.com/pmacct/pmacct/blob/master/docs/LOOKING_GLASS_FORMAT,
>> >- Birdseye https://github.com/inex/birdseye
>> >- CAIDA looking glass API
>> >https://www.caida.org/tools/utilities/looking-glass-api/
>> >- DE-CIX: https://www.de-cix.net/en/resources/looking-glass (which
>> is
>> >using https://github.com/alice-lg/alice-lg)
>> >- RIPEStat's API, e.g.
>> >
>> https://stat.ripe.net/data/looking-glass/data.json?preferred_version=2.1=2a0d:d740::/48
>>
>> Just to add to the list: there is yet another API-based Looking Glass
>> targetting OpenBGPD: https://github.com/cjeker/bgplgd
>>
>> A demo is here:
>> http://165.22.27.105/bgplgd/summary
>> http://165.22.27.105/bgplgd/rib?as=22512
>>
>> 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] BGP Looking Glass Capability

[Robert Raszuk]

Jakob,

> Several years ago Ignas pointed out that you can use this
> information to know whether to install a backup on your
> side for the route. Backup routes in the forwarding hardware
> are expensive, so it would be good to know if your peer
> is using your route before installing a backup for it.

Let's see if I understand what you wrote 

ASN1 ASN2 or ASN3 etc ...

R1.1  -- R2.1
   |
R1.2  -- R2.2 or R3.1 etc ..

Assume your prefix is 1.1.1.0/24 You are advertising it from R1.x to R2.x
and R3.x

Q1 - This is your prefix (or transit one) so are you describing the case
where different IBGP next hop is programmed (or not) into local FIB of R1.1
as backup ?

Q2 - R2.1's policy can change N times a day (hint PFR) ... how often are
you going to probe R2.1 if your route is installed ?

Q3 - Exposing someone's RIB or even bRIB may be indirectly revealing their
policy. Last time I checked some operators were rather careful not to
publish their eBGP policies to their peers.

Thx,
R.























On Tue, Apr 27, 2021 at 2:01 AM Jakob Heitz (jheitz)  wrote:

> Rayhaan wanted to know if the peer accepted his route.
> A looking glass is a different thing in many ways.
>
> Several years ago Ignas pointed out that you can use this
> information to know whether to install a backup on your
> side for the route. Backup routes in the forwarding hardware
> are expensive, so it would be good to know if your peer
> is using your route before installing a backup for it.
>
> BGP has a peer-to-peer only signaling mechanism: ORF.
> Can we invent an ORF for it?
>
> Rayhaan, please let me know if I'm on or off track
> for your use case.
>
> Regards,
> Jakob.
>
> -Original Message-
> From: GROW  On Behalf Of heasley
> Sent: Monday, April 26, 2021 4:23 PM
> To: Christopher Morrow 
> Cc: grow@ietf.org grow@ietf.org 
> Subject: Re: [GROW] BGP Looking Glass Capability
>
> Mon, Apr 26, 2021 at 06:25:44PM -0400, Christopher Morrow:
> > (as normal netizen)
> >
> > On Mon, Apr 26, 2021 at 3:33 PM Randy Bush  wrote:
> >
> > > > Place LG info in peeringdb.com & peeringdb's api.
> > >
> > > +1
> > >
> >
> > huh,I had thought this was already actually included in peeringdb?
> > 
> >Looking Glass URL http://route-server.ip.att.net
> > 
>
> afict, its just a string, which does not provide a standard way to
> represent location/geo.  i presume from earlier comments, that something
> more structured is desired.
>
> ___
> 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] BGP Looking Glass Capability

[Robert Raszuk]

Yes I mentioned this case in one of the subsequent emails - LG can be per
region etc ... You just register not one by many such looking glass server
addresses. Some may be independent .. some may be a pool of servers under
same IP.

Thx

On Mon, Apr 26, 2021 at 5:59 AM Alejandro Acosta <
alejandroacostaal...@gmail.com> wrote:

> Hello, I guess you have already mentioned this, however I have not found
> it yet. Please consider many AS have many different views. That's it.
>
> Alejandro,
>
> On Sun, Apr 25, 2021, 8:03 AM Robert Raszuk  wrote:
>
>>
>> > for example: 23456.lookingglass for AS 23456.
>>
>>
>> I was just about to propose to define a notion of well known URL for
>> looking glass.
>>
>>
>> Let's grab bgp.io domain (it seems available) and allow each domain to
>> submit their IP to well known name mapping. In fact looking glasses may be
>> just one of many such well known tools to help with operational aspects of
>> the Internet.
>>
>>
>> In such cases no signalling would be necessary at all and you can always
>> go to 23456.lookingglass.bgp.io with an obvious alias (23456.lg.bgp.io)
>> to see if your routes made it via peer's policy/best path etc ... In case
>> ASN has more then one LG in each region same thing ... you define a few
>> such addresses to indicate each server or LG server pool.
>>
>>
>> Thx,
>> R.
>>
>>
>> PS. However if we want to down the BGP inline signalling for this I
>> recommend we take a look at:
>> https://tools.ietf.org/html/draft-ietf-idr-operational-message-00  Seems
>> to me like defining new TLV there would be very good fit for what is being
>> proposed here.
>>
>>
>>
>> On Sun, Apr 25, 2021 at 7:55 AM Jakob Heitz (jheitz) > 40cisco@dmarc.ietf.org> wrote:
>>
>>> This is a great thing to do, but I would not use a BGP capability to do
>>> it.
>>>
>>> The capability is signaled only in the BGP OPEN message, at the start of
>>> the session.
>>>
>>> Changes cannot be signaled without bouncing the session.
>>>
>>> The BGP capability is only exchanged with neighbors.
>>>
>>> Perhaps we could do it with a new address family or
>>>
>>> standardize the form of the URL, say invent a new top level domain:
>>> .lookingglass
>>>
>>> and then the URL could be the ASN followed by the TLD, for example:
>>>
>>> 23456.lookingglass for AS 23456.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Jakob.
>>>
>>>
>>>
>>> *From:* GROW  *On Behalf Of * Rayhaan
>>> Jaufeerally (IETF)
>>> *Sent:* Saturday, April 24, 2021 6:38 AM
>>> *To:* grow@ietf.org
>>> *Subject:* [GROW] BGP Looking Glass Capability
>>>
>>>
>>>
>>> Dear GROW chairs and participants,
>>>
>>>
>>>
>>> I would like to propose draft-jaufeerally-bgp-lg-cap-00 (
>>> https://datatracker.ietf.org/doc/draft-jaufeerally-bgp-lg-cap/) as a
>>> mechanism for in-band dissemination of looking glass endpoints in BGP,
>>> using a new OPEN message capability.
>>>
>>>
>>>
>>> The rationale behind this is to facilitate automation around eBGP
>>> peering, for example  to make it possible to automatically detect if the
>>> peer has accepted some routes which are expected to be accepted.
>>>
>>>
>>>
>>> I'm aware that the underlying RFC8522 is an informational RFC and leaves
>>> some details unspecified for the response format (i.e. a schema for the
>>> queries/responses) but I believe that can be further refined in other works
>>> independent to this proposal.
>>>
>>>
>>>
>>> I would like to hear what the WG thinks, if this is a reasonable
>>> proposal which fits into the broader charter of GROW?
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Rayhaan
>>> ___
>>> 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] BGP Looking Glass Capability

[Robert Raszuk]

Hi Rayhaan,


> I guess a good starting point would be to reach out to IDR folks / authors
> of the operational message draft and get their input as to why it didn't
> progress further since that would be useful to guide any revival attempts.
>

Good idea. As I am co-author of this draft taking the liberty to do it
right here :)

A bit of history  - in min 2010 I wrote
https://tools.ietf.org/html/draft-raszuk-bgp-diagnostic-message-00.

Then we spoke about it, trimmed a bit and formed what we considered most
important operationally into
https://tools.ietf.org/html/draft-ietf-idr-operational-message-00

The draft was having good support during the IDR WG adoption and hence it
became WG doc.

Since then most of the authors left the vendor world and our influence to
implement it in significant commercial BGP code bases was no longer
sufficient. Yet vendors told we will implement it if customers ask for it.
So we are 9+ years and still I am not sure if anyone cares much about
switching phone and email channels between NOCs into more programmatic way.

Yet we do see from time to time a pop request to some form to tell peer
ascii strings like sms by BGP, pass some well known address, etc ...

I think this is the fundamental challenge in how we operate peering
relations. I have seen a lot of good automation happening in the IX world,
but when trying to establish BGP sessions today it seems still emails, xls,
word documents style ...

While it does not need to be all TLVs as listed in the
https://tools.ietf.org/html/draft-ietf-idr-operational-message-00 draft but
I think operational message is indeed needed.

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

Re: [GROW] BGP Looking Glass Capability

[Robert Raszuk]

Nick,

Would you allow to query yr router via such API to anyone in the world ? I
believe this is the real use case Rayhaan is bringing up ...

Thx,
R.


On Sun, Apr 25, 2021 at 4:07 PM Nick Hilliard  wrote:

> Rayhaan Jaufeerally (IETF) wrote on 24/04/2021 14:38:
> > I would like to propose draft-jaufeerally-bgp-lg-cap-00
> > (https://datatracker.ietf.org/doc/draft-jaufeerally-bgp-lg-cap/) as a
> > mechanism for in-band dissemination of looking glass endpoints in BGP,
> > using a new OPEN message capability.
>
> Hi Rayhaan,
>
> what we need from routers is a consistent API endpoint which serves RIB
> data, that can be consumed by client apps.
>
> I.e. this should be done using json/xml/etc; it should be available over
> over https; it should be accessible via a REST API; it should be aimed
> at having a front-end HTTP cache server to implement rate limiting /
> limited access control / etc (i.e. remove as much complication from the
> router as possible), and the data model should be flexible enough to
> handle a variety of different deployment configurations (e.g. ibgp /
> ebgp / l3vpn / l2vpn / evpn / ixp route server / etc).
>
> INEX has done this for BIRD (see github.com/inex/birdseye, which
> provides both the data model and the LG), but the data model is designed
> around constructs which are only available in BIRD, so this isn't really
> portable to other BGP stacks.  But the principle works, and works well.
>
> Nick
>
> ___
> 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] BGP Looking Glass Capability

[Robert Raszuk]

, could be useful to relay
> back information that a particular prefix has been dropped for $reason.
>
> If the new AF is something that others see promise in I would be happy to
> start drafting some thoughts on how it could work, and rework this
> particular draft to use that mechanism.
>
> Have a great Sunday,
> Rayhaan
>
> On Sun, Apr 25, 2021 at 2:03 PM Robert Raszuk  wrote:
>
>>
>> > for example: 23456.lookingglass for AS 23456.
>>
>>
>> I was just about to propose to define a notion of well known URL for
>> looking glass.
>>
>>
>> Let's grab bgp.io domain (it seems available) and allow each domain to
>> submit their IP to well known name mapping. In fact looking glasses may be
>> just one of many such well known tools to help with operational aspects of
>> the Internet.
>>
>>
>> In such cases no signalling would be necessary at all and you can always
>> go to 23456.lookingglass.bgp.io with an obvious alias (23456.lg.bgp.io)
>> to see if your routes made it via peer's policy/best path etc ... In case
>> ASN has more then one LG in each region same thing ... you define a few
>> such addresses to indicate each server or LG server pool.
>>
>>
>> Thx,
>> R.
>>
>>
>> PS. However if we want to down the BGP inline signalling for this I
>> recommend we take a look at:
>> https://tools.ietf.org/html/draft-ietf-idr-operational-message-00  Seems
>> to me like defining new TLV there would be very good fit for what is being
>> proposed here.
>>
>>
>>
>> On Sun, Apr 25, 2021 at 7:55 AM Jakob Heitz (jheitz) > 40cisco@dmarc.ietf.org> wrote:
>>
>>> This is a great thing to do, but I would not use a BGP capability to do
>>> it.
>>>
>>> The capability is signaled only in the BGP OPEN message, at the start of
>>> the session.
>>>
>>> Changes cannot be signaled without bouncing the session.
>>>
>>> The BGP capability is only exchanged with neighbors.
>>>
>>> Perhaps we could do it with a new address family or
>>>
>>> standardize the form of the URL, say invent a new top level domain:
>>> .lookingglass
>>>
>>> and then the URL could be the ASN followed by the TLD, for example:
>>>
>>> 23456.lookingglass for AS 23456.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Jakob.
>>>
>>>
>>>
>>> *From:* GROW  *On Behalf Of * Rayhaan
>>> Jaufeerally (IETF)
>>> *Sent:* Saturday, April 24, 2021 6:38 AM
>>> *To:* grow@ietf.org
>>> *Subject:* [GROW] BGP Looking Glass Capability
>>>
>>>
>>>
>>> Dear GROW chairs and participants,
>>>
>>>
>>>
>>> I would like to propose draft-jaufeerally-bgp-lg-cap-00 (
>>> https://datatracker.ietf.org/doc/draft-jaufeerally-bgp-lg-cap/) as a
>>> mechanism for in-band dissemination of looking glass endpoints in BGP,
>>> using a new OPEN message capability.
>>>
>>>
>>>
>>> The rationale behind this is to facilitate automation around eBGP
>>> peering, for example  to make it possible to automatically detect if the
>>> peer has accepted some routes which are expected to be accepted.
>>>
>>>
>>>
>>> I'm aware that the underlying RFC8522 is an informational RFC and leaves
>>> some details unspecified for the response format (i.e. a schema for the
>>> queries/responses) but I believe that can be further refined in other works
>>> independent to this proposal.
>>>
>>>
>>>
>>> I would like to hear what the WG thinks, if this is a reasonable
>>> proposal which fits into the broader charter of GROW?
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Rayhaan
>>> ___
>>> 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] BGP Looking Glass Capability

[Robert Raszuk]

> for example: 23456.lookingglass for AS 23456.


I was just about to propose to define a notion of well known URL for
looking glass.


Let's grab bgp.io domain (it seems available) and allow each domain to
submit their IP to well known name mapping. In fact looking glasses may be
just one of many such well known tools to help with operational aspects of
the Internet.


In such cases no signalling would be necessary at all and you can always go
to 23456.lookingglass.bgp.io with an obvious alias (23456.lg.bgp.io) to see
if your routes made it via peer's policy/best path etc ... In case ASN has
more then one LG in each region same thing ... you define a few such
addresses to indicate each server or LG server pool.


Thx,
R.


PS. However if we want to down the BGP inline signalling for this I
recommend we take a look at:
https://tools.ietf.org/html/draft-ietf-idr-operational-message-00  Seems to
me like defining new TLV there would be very good fit for what is being
proposed here.



On Sun, Apr 25, 2021 at 7:55 AM Jakob Heitz (jheitz)  wrote:

> This is a great thing to do, but I would not use a BGP capability to do it.
>
> The capability is signaled only in the BGP OPEN message, at the start of
> the session.
>
> Changes cannot be signaled without bouncing the session.
>
> The BGP capability is only exchanged with neighbors.
>
> Perhaps we could do it with a new address family or
>
> standardize the form of the URL, say invent a new top level domain:
> .lookingglass
>
> and then the URL could be the ASN followed by the TLD, for example:
>
> 23456.lookingglass for AS 23456.
>
>
>
> Regards,
>
> Jakob.
>
>
>
> *From:* GROW  *On Behalf Of * Rayhaan Jaufeerally
> (IETF)
> *Sent:* Saturday, April 24, 2021 6:38 AM
> *To:* grow@ietf.org
> *Subject:* [GROW] BGP Looking Glass Capability
>
>
>
> Dear GROW chairs and participants,
>
>
>
> I would like to propose draft-jaufeerally-bgp-lg-cap-00 (
> https://datatracker.ietf.org/doc/draft-jaufeerally-bgp-lg-cap/) as a
> mechanism for in-band dissemination of looking glass endpoints in BGP,
> using a new OPEN message capability.
>
>
>
> The rationale behind this is to facilitate automation around eBGP peering,
> for example  to make it possible to automatically detect if the peer has
> accepted some routes which are expected to be accepted.
>
>
>
> I'm aware that the underlying RFC8522 is an informational RFC and leaves
> some details unspecified for the response format (i.e. a schema for the
> queries/responses) but I believe that can be further refined in other works
> independent to this proposal.
>
>
>
> I would like to hear what the WG thinks, if this is a reasonable proposal
> which fits into the broader charter of GROW?
>
>
>
> Thanks,
>
> Rayhaan
> ___
> 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] is TCP the right layer for BMP session resumption?

[Robert Raszuk]

I second John's comment with a bit more optimism.

As gRPC over QUIC is becoming a reality and de-facto messaging standard
there is going to be hardly any choice for any router's vendor to resist to
implement it.

Best,
R.


On Tue, Mar 9, 2021 at 9:57 PM John Kristoff  wrote:

> On Tue, 9 Mar 2021 20:44:18 +
> "Jakob Heitz \(jheitz\)"  wrote:
>
> > I've seen this session resumption technique in the '90s.
> > BMP is a one-way protocol. The BMP server sends nothing.
>
> I kind of wish my BMP router monitor was able to transport data over UDP
> to the listening station like syslog and flow data.  I would have
> especially liked this after that time a blocked TCP port and the
> inability to opena TCP connection once caused my BMP monitor router
> doing the active open to crash (known and now fixed bug).
>
> > Thus adding this is a significant rework of BMP.
>
> I assume my desire for UDP above will never happen as a result.  Oh
> well.
>
> John
>
> ___
> 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] AS_Path prepend BCP

[Robert Raszuk]

Hi Jakob,

The situation in reality is much more complex then your illustration.

Imagine that in your picture what you call "content" is coming from all
over the world and not one network location. And all of that is coming to
same  /24.

Imagine customer already advertises few /24s (some with short some with
long AS-PATH) so at this point IMHO solution 1 is very good and till we
have a better one becomes IMO best one.

The fact that for backup he will instead of /24s with long AS-PATH
advertise /22 will not make any one's FIB bigger ...

Best,
R.

PS. Of course if someone advertises /22 and we ask to advertise in addition
to this /24s that would be growing RIBs and FIBs everywhere. But that is
not the current situation in many networks.


On Thu, Aug 6, 2020 at 5:50 AM Jakob Heitz (jheitz)  wrote:

> Consider a common problem
>
>
>
> [image: An Ink Drawing]
>
> Tier1-B sets local-preference for its customer to 120
>
> and for its peer to 100.
>
>
>
>
>
> How does Customer cause Tier1-B to prefer the path:
>
> Content -> Tier1-B -> Tier1-A -> Regular-Provider -> Customer
>
> instead of its default path:
>
> Content -> Tier1-B -> Backup-Provider -> Customer
>
> ?
>
>
>
> Solution 1
>
> --
>
> Customer advertises split prefixes to Regular-Provider.
>
> Eg., 10.0.2.0/24 and 10.0.3/24 rather than 10.0.2/23.
>
> This works, but causes bigger FIBs for everybody.
>
>
>
> Solution 2
>
> --
>
> Customer advertises its routes with communities published by
>
> Tier1-B to lower its local-preference to Backup-Provider.
>
> This requires Backup-Provider to pass communities through
>
> and for Customer to know what Backup-Provider's upstreams are.
>
> It is operationally cumbersome.
>
>
>
> Solution 3
>
> --
>
> Tier1-B implements a route-policy like:
>
> if as-path length ge 15 then
>
>   set local-preference 80
>
> endif
>
> Then Customer can add lots of AS prepends that will actually work!!
>
>
>
> Regards,
>
> Jakob.
>
>
> ___
> 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] AS_Path prepend BCP

[Robert Raszuk]

Thank you Greg,

I think that clarifies it very well. And I actually fully agree with all
you just said below.

Kind regards,
R.

On Thu, Aug 6, 2020 at 3:46 AM Greg Skinner  wrote:

> Hi Robert,
>
> On Aug 2, 2020, at 3:22 AM, Robert Raszuk  wrote:
>
> Hi Greg,
>
>
>> > Have anyone tried to document that instead of doing AS-PATH prepend
>> across set of upstreams (for whatever valid reason that may be) the
>> preferred entrance should advertise the paths with IGP or EGP origin while
>> the other ASBRs (which would otherwise prepend N times) with INCOMPLETE ?
>> BGP best path should automatically across most implementations do the right
>> path selection.
>>
>> Offhand, I don’t know of anyone who has tried to document this.  But why
>> EGP origin?  EGP is a Historic protocol that is rarely if ever used.  IMO,
>> although this technique could work, it is misleading.
>>
>
> I thought it is not used too but looking at the BGP table it is there:
>
> cto-asr1x-ny1#sh ip bgp detail | count .*EGP.*external, best.*
> Number of lines which match regexp = 826
>
> cto-asr1x-ny1#sh ip bgp detail |  count .*EGP.*
> Number of lines which match regexp = 2345
>
>
> Actually, I meant that EGP protocol speakers (implemented according to RFC
> 904 <https://www.rfc-editor.org/rfc/rfc904.html>) are rarely if ever used
> anymore.  I’m sorry if I was unclear.
>
> Then looking at some vendor's docs I see that they apply it if the
> advertised route was learned via different ASN (many folks run more then
> one AS globally)  bit of surprise as RFC4271 never mentioned such use case.
>
> origin egp—(Optional) BGP origin attribute that indicates that the path
> information originated in another AS.
>
> So one could argue that it is misleading already today :)
>
>
> Agreed.
>
> > If not maybe we should think about a new attribute along the lines of
>> cost community to be more widely used in a transitive manner and to have
>> single meaning to allow to deprefer a prefix originated by given AS across
>> number of ISP uplinks with a numeric value (just like MED or Local Pref are
>> used locally).
>>
>> IMO, this is a better idea.
>
>
> Well sure, but you know the time we take to define it, the time vendors
> take to implement it, the time it takes to deploy it then the time it takes
> for folks to actually start using it we are talking years ...
>
> Sure if we never start we will never get there but in the mean
> time perhaps we could use what's deployed everywhere to trim size of
> AS-PATHs yet get all the benefits of AS-PATH prepends ?
>
>
> Perhaps a better way for me to express my concern is (ideally), any
> mention of "origin egp" in future RFCs should not recommend its use unless
> the Historic EGP protocol is used.  I hope that is more clear.  That would
> at least be consistent with the original, intended use of “origin egp”.
>
> Clearly I am here just trying to probe the WG list on three questions ...
>
> Is it worth to try it - ie. do we have a problem,
> Is this a good idea - ie. do we break anything,
> Should this option be added to draft-mcbride-grow-as-path-prepend as
> something to consider instead of doing N times AS-PATH prepend (often N > 5
> or N> 10 )
>
> See at the end of the day the best thing about this is that anyone can try
> to advertise his paths with different origin even today and it should just
> work - without anyone else doing anything configuration wise in the
> upstream ASNs.
>
> Thx,
> R.
>
>
> I’m thinking along the lines that (excessive) prepending is used because
> there isn’t an alternative that more clearly expresses the intent of the
> operator.  If specifying a new attribute would facilitate that, I would be
> in favor of it.
>
> Regards, Greg
>
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] AS_Path prepend BCP

[Robert Raszuk]

Hi Greg,


> > Have anyone tried to document that instead of doing AS-PATH prepend
> across set of upstreams (for whatever valid reason that may be) the
> preferred entrance should advertise the paths with IGP or EGP origin while
> the other ASBRs (which would otherwise prepend N times) with INCOMPLETE ?
> BGP best path should automatically across most implementations do the right
> path selection.
>
> Offhand, I don’t know of anyone who has tried to document this.  But why
> EGP origin?  EGP is a Historic protocol that is rarely if ever used.  IMO,
> although this technique could work, it is misleading.
>

I thought it is not used too but looking at the BGP table it is there:

cto-asr1x-ny1#sh ip bgp detail | count .*EGP.*external, best.*
Number of lines which match regexp = 826

cto-asr1x-ny1#sh ip bgp detail |  count .*EGP.*
Number of lines which match regexp = 2345

Then looking at some vendor's docs I see that they apply it if the
advertised route was learned via different ASN (many folks run more then
one AS globally)  bit of surprise as RFC4271 never mentioned such use case.

origin egp—(Optional) BGP origin attribute that indicates that the path
information originated in another AS.

So one could argue that it is misleading already today :)

> If not maybe we should think about a new attribute along the lines of
> cost community to be more widely used in a transitive manner and to have
> single meaning to allow to deprefer a prefix originated by given AS across
> number of ISP uplinks with a numeric value (just like MED or Local Pref are
> used locally).
>
> IMO, this is a better idea.


Well sure, but you know the time we take to define it, the time vendors
take to implement it, the time it takes to deploy it then the time it takes
for folks to actually start using it we are talking years ...

Sure if we never start we will never get there but in the mean time perhaps
we could use what's deployed everywhere to trim size of AS-PATHs yet get
all the benefits of AS-PATH prepends ?

Clearly I am here just trying to probe the WG list on three questions ...

Is it worth to try it - ie. do we have a problem,
Is this a good idea - ie. do we break anything,
Should this option be added to draft-mcbride-grow-as-path-prepend as
something to consider instead of doing N times AS-PATH prepend (often N > 5
or N> 10 )

See at the end of the day the best thing about this is that anyone can try
to advertise his paths with different origin even today and it should just
work - without anyone else doing anything configuration wise in the
upstream ASNs.

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

Re: [GROW] [WG ADOPTION]: draft-mcbride-grow-as-path-prepend-01 - ENDS 08/12/2020 (Aug 12)

[Robert Raszuk]

Support

Thx,
r.

On Wed, Jul 29, 2020 at 7:17 PM Christopher Morrow <
christopher.mor...@gmail.com> wrote:

> Howdy WG Folks!
> There's been significant chatter on-list about:
>   draft-mcbride-grow-as-path-prepend-01
>
> Abstract:
>   "AS_Path prepending provides a tool to manipulate the BGP AS_Path
>attribute through prepending multiple entries of an AS.  AS_Path
>prepend is used to deprioritize a route or alternate path.  By
>prepending the local ASN multiple times, ASes can make advertised AS
>paths appear artificially longer.  Excessive AS_Path prepending has
>caused routing issues in the internet.  This document provides
>guidance,to the internet community, with how best to utilize AS_Path
>prepend in order to avoid negatively affecting the internet."
>
> This work seems directly in the GROW wheelhouse, and it appears folk
> on-list agree. Let's decide with a WG Adoption call for this document
> and see if we should continue this work officially/etc.
>
> Please give it a read, and comment on adoption ideals here-in.
>
> thanks!
> -chris
> co-chair-persona
>
> ___
> 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] The automatic policy exchange by draft-ietf-idr-rpd-05.txt can be used for draft-ietf-rtgwg-net2cloud-gap-analysis

[Robert Raszuk]

If people still think of adding p2p config push to the protocol which
allows all of us to function - by all means the answer to your question is
YES.

Thx,
R.

On Mon, Jul 27, 2020 at 2:21 AM Linda Dunbar 
wrote:

> Robert,
>
>
>
> Thank you very much for the explanation.
>
> “new BGP Transport Instance with new separate port and separate process”,
> very interesting perspective.
>
>
>
> But draft-raszuk-ti-bgp-01 was written 10 years ago. Is it still valid and
> worth pursuing?
>
>
>
> Thank you
>
> Linda
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Sunday, July 26, 2020 5:23 PM
> *To:* Linda Dunbar 
> *Cc:* Lizhenbin ; Jakob Heitz (jheitz) <
> jhe...@cisco.com>; i...@ietf.org; grow@ietf.org grow@ietf.org <
> grow@ietf.org>; rt...@ietf.org
> *Subject:* Re: The automatic policy exchange by draft-ietf-idr-rpd-05.txt
> can be used for draft-ietf-rtgwg-net2cloud-gap-analysis
>
>
>
> Hi Linda,
>
>
>
> So are you suggesting that this new SAFI is to be sent on EBGP too ?? Whow
> ... Note BGP is not too secure transport ! I would never allow any peer to
> push me policy via eBGP to my ASBRs regardless how much I would trust it.
>
>
>
> That aside I think no one is questioning that overall this is nice to have
> BGP policy distributed in a dynamic way. We are however concerned in
> three planes ...
>
>
>
> Aspect #1 - BGP is p2mp and information and encoding (NLRI) here clearly
> make this proposal p2p. And no Robin p2p is not a special case of p2mp :)
>
>
>
> Aspect #2 - This proposal adds additional burden to IP Routing BGP
> subsystem and its clear that if approved there will be more and more
> extensions to new MATCH and SET sub-TLVs coming. While it is easy to write
> a draft that at the end requires a serious commitment from any vendor to
> now turn BGP into configuration channel. That means overall more cycles
> spend and more burden on BGP dev teams.
>
>
>
> Aspect #3 - The proposal has lots of technical issues (as described) which
> can not just be swapped under the carpet.
>
>
>
> My recommendations (in order of preference):
>
>
>
> *1*
>
>
>
> Turn proposed sub-TLVs into JSON and use HTTPS PUT, GET & DELETE along
> with real time response status codes to send required policy over targeted
> TCP sessions just using curl to remote ASBRs. Note all vendors today
> support RESTful commands or httpd on the routers. Some already even support
> JSON based BGP configuration for some time now (ex: NX-OS).
>
>
>
> *2*
>
>
>
> At least decouple it from routing BGP - support new BGP Transport Instance
> with new separate port and separate process. Whenever we need to use such
> protocol (call it Configuration Transport Protocol "CTP") for loop free
> information dissemination such isolation could deliver what you are really
> after with no impact to stability of IP routing.
>
> Ref: https://tools.ietf.org/html/draft-raszuk-ti-bgp-01
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-raszuk-ti-bgp-01=02%7C01%7Clinda.dunbar%40futurewei.com%7Cfc692e6f8ad641dd5b9908d831b27afd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637313989929483251=t6YI2%2BYcngtpCMJ3d%2BSFAkuffeGFW236zvXIZsd7cA8%3D=0>
>
>
>
>
> Thx,
>
> R.
>
>
>
>
>
> On Sun, Jul 26, 2020 at 11:53 PM Linda Dunbar 
> wrote:
>
> Robert, Jakob, etc.
>
>
>
> Thank you very much for detailed explanation of the issues.
>
> One of the points you all raised is that p2p policies should be
> administrated by controller via NETCONF.
>
>
>
> https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-gap-analysis/
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-rtgwg-net2cloud-gap-analysis%2F=02%7C01%7Clinda.dunbar%40futurewei.com%7Cfc692e6f8ad641dd5b9908d831b27afd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637313989929483251=ESJ%2BqmxEnlpAq32P3H3WxrkWzFIN863%2F7bKtucFdTrg%3D=0>
> describes a scenario of one vCPE in cloud DC reachable by multiple PEs.
> Depending on the nature of the applications or/and network conditions, some
> applications may need to egress or ingress from PE1, others may need to
> egress or ingress from PE2.
>
>
>
> Today’s Cloud DC configuration can use the AS Path metric to influence the
> preferred path to/from a specific PEs. But requires manual configuration.
>
> After reading through the draft-ietf-idr-rpd-05, I think the automatic
> approach can make the change on demand. The policy change can be ephemeral.
>
> Therefore, if one side doesn’t implement the feature, the “spray” doesn’t
> have an

Re: [GROW] The automatic policy exchange by draft-ietf-idr-rpd-05.txt can be used for draft-ietf-rtgwg-net2cloud-gap-analysis

[Robert Raszuk]

Hi Linda,

So are you suggesting that this new SAFI is to be sent on EBGP too ?? Whow
 Note BGP is not too secure transport ! I would never allow any peer to
push me policy via eBGP to my ASBRs regardless how much I would trust it.

That aside I think no one is questioning that overall this is nice to have
BGP policy distributed in a dynamic way. We are however concerned in
three planes ...

Aspect #1 - BGP is p2mp and information and encoding (NLRI) here clearly
make this proposal p2p. And no Robin p2p is not a special case of p2mp :)

Aspect #2 - This proposal adds additional burden to IP Routing BGP
subsystem and its clear that if approved there will be more and more
extensions to new MATCH and SET sub-TLVs coming. While it is easy to write
a draft that at the end requires a serious commitment from any vendor to
now turn BGP into configuration channel. That means overall more cycles
spend and more burden on BGP dev teams.

Aspect #3 - The proposal has lots of technical issues (as described) which
can not just be swapped under the carpet.

My recommendations (in order of preference):

*1*

Turn proposed sub-TLVs into JSON and use HTTPS PUT, GET & DELETE along with
real time response status codes to send required policy over targeted TCP
sessions just using curl to remote ASBRs. Note all vendors today support
RESTful commands or httpd on the routers. Some already even support JSON
based BGP configuration for some time now (ex: NX-OS).

*2*

At least decouple it from routing BGP - support new BGP Transport Instance
with new separate port and separate process. Whenever we need to use such
protocol (call it Configuration Transport Protocol "CTP") for loop free
information dissemination such isolation could deliver what you are really
after with no impact to stability of IP routing.
Ref: https://tools.ietf.org/html/draft-raszuk-ti-bgp-01

Thx,
R.


On Sun, Jul 26, 2020 at 11:53 PM Linda Dunbar 
wrote:

> Robert, Jakob, etc.
>
> Thank you very much for detailed explanation of the issues.
> One of the points you all raised is that p2p policies should be
> administrated by controller via NETCONF.
>
> *https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-gap-analysis/*
> <https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-gap-analysis/>
> describes a scenario of one vCPE in cloud DC reachable by multiple PEs. 
> Depending
> on the nature of the applications or/and network conditions, some
> applications may need to egress or ingress from PE1, others may need to
> egress or ingress from PE2.
>
> Today’s Cloud DC configuration can use the AS Path metric to influence the
> preferred path to/from a specific PEs. But requires manual configuration.
> After reading through the draft-ietf-idr-rpd-05, I think the automatic
> approach can make the change on demand. The policy change can be ephemeral.
> Therefore, if one side doesn’t implement the feature, the “spray” doesn’t
> have any impact. The traffic egress or ingress to the peer network would
> just go with the configuration. If the “spray” is answered, then the
> performance can be improved.
>
>
>
>
>
>
> If not using the automatic method proposed by draft-ietf-idr-rpd, do you
> have other suggestions?
>
> Thank you very much.
>
> Linda Dunbar
> *From:* Robert Raszuk 
> *Sent:* Friday, July 24, 2020 2:50 PM
> *To:* Linda Dunbar ; Lizhenbin <
> lizhen...@huawei.com>
> *Cc:* Jakob Heitz (jheitz) ; i...@ietf.org; grow@ietf.org
> grow@ietf.org 
> *Subject:* Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to
> 7/29/2020)
>
> Linda,
>
> It seems that authors of this document are strongly pushing to pass the
> last call irrespective of observations made by WG.
>
> As said before and as reiterated by Jakob and Ketan BGP is not the right
> tool for p2p config push. We must stop adding such extensions to BGP like
> this one or BGP-LS or SR Policies if we really want to keep routing at some
> proper stability levels.
>
> But even if you would convince everyone in IDR that this is all great the
> draft itself is so immature that I can't imagine why are we discussing last
> call at this time.
>
> * Please observe that BGP state is ephemeral. When BGP sessions resets all
> state previously distributed is gone (modulo GR ...) Is the
> expectation here that state distributed by this new SAFI will persists ? If
> so for how long ? If not have you even considered the initial churn ?
>
> * We have hooks to make sure LDP and IGP play in concert with BGP
> reachability. Would we need to now add to also wait for BGP policy to be
> received from controllers ?
>
> * We have spent fair amount of time to make sure GR works well. Do you
> expect to now GR to recognize all policy parameters and sync deltas locally
> upon BGP sessions 

Re: [GROW] AS_Path prepend BCP

[Robert Raszuk]

All,

Happy to see this draft ! Have been struggling with explaining some of
those issues and lack of such BCPs was sort of implicit prove that it is
all fine to prepend at will.

Said this it seems clear that putting aside cases of unnecessary use or use
by errors AS-PATH prepends we are still facing no Internet wide path
de-prefernecing in BGP being commonly used other then mangling AS-PATH.

The point is that multihoming is common and if someone needs at least to
try to influence entrance to his domain AS-PATH prepend comes as low
hanging fruit.

Longer prefix will not work when on both ASBRs a /24 is injected.

So let me ask a question here ...

Have anyone tried to document that instead of doing AS-PATH prepend across
set of upstreams (for whatever valid reason that may be) the
preferred entrance should advertise the paths with IGP or EGP origin while
the other ASBRs (which would otherwise prepend N times) with INCOMPLETE ?
BGP best path should automatically across most implementations do the
right path selection.

Anyone see any issue with that ? If that works we could actually start to
strongly discourage use of AS-PATH prepending.

If not maybe we should think about a new attribute along the lines of cost
community to be more widely used in a transitive manner and to have single
meaning to allow to deprefer a prefix originated by given AS across number
of ISP uplinks with a numeric value (just like MED or Local Pref are used
locally).

Another question the draft talks about AS-PATH prepends by actual sources
 well suffice to just take a look at Internet tables in few places to
see that even some transit operators prepend themselves to the original
paths (also already prepended). And yes I do have captures of those.

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

Re: [GROW] [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

[Robert Raszuk]

Linda,

It seems that authors of this document are strongly pushing to pass the
last call irrespective of observations made by WG.

As said before and as reiterated by Jakob and Ketan BGP is not the right
tool for p2p config push. We must stop adding such extensions to BGP like
this one or BGP-LS or SR Policies if we really want to keep routing at some
proper stability levels.

But even if you would convince everyone in IDR that this is all great the
draft itself is so immature that I can't imagine why are we discussing last
call at this time.

* Please observe that BGP state is ephemeral. When BGP sessions resets all
state previously distributed is gone (modulo GR ...) Is the
expectation here that state distributed by this new SAFI will persists ? If
so for how long ? If not have you even considered the initial churn ?

* We have hooks to make sure LDP and IGP play in concert with BGP
reachability. Would we need to now add to also wait for BGP policy to be
received from controllers ?

* We have spent fair amount of time to make sure GR works well. Do you
expect to now GR to recognize all policy parameters and sync deltas locally
upon BGP sessions restarts ?

* Do you expect BGP implementations to now get busy with understanding all
BGP policies syntax and semantics not in current terms how they are send or
received in BGP UPDATEs but how they are applied implementation by
implementation ...

* What happens when some implementation does not allow some policy defined
in the draft ... for example flexible AS_PATH creation as defined in
AS-Path Change sub-TLV ? Note that this section alone is catastrophic for
BGP protocol to allow insertion of more then your own ASN into AS-PATH.
Just looking at this alone should be enough to reject this draft.

And there are many many more real issues with this proposal  

See when document has low adoption bar it does not mean that it will also
have the same low bar to progress it :)

Kind regards,
R.

PS. Let me cc GROW WG here as I think more operational review and comments
would be highly valuable at this point.



On Fri, Jul 24, 2020 at 6:28 PM Linda Dunbar 
wrote:

> Jakob,
>
>
>
> Comparing Netconf with BGP  is not apple to apple comparison.
>
> I remember a few years ago that  Netconf advocators have claimed that
> Netconf can replace PCE, replace BGP, replace xx, …
>
>
>
> After many years debate,  many of the Netconf  limitations have been
> acknowledged,  that is why PCE still exists, so does BGP.
>
>
>
> Other comments are inserted below:
>
>
>
> *From:* Jakob Heitz (jheitz) 
> *Sent:* Thursday, July 23, 2020 5:37 PM
> *To:* Linda Dunbar ; i...@ietf.org
> *Subject:* RE: WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)
>
>
>
> Netconf provides needed features that BGP does not have:
>
> - Atomic Transactions:
>
>   If one configuration item fails, they all fail.
>
>   They all either succeed or all fail. There is no partial success.
>
>   Multiple configurations in one transaction are applied at the same time..
>
>. This avoids non-deterministic transient behavior between application
> of the first policy and the last.
>
> [Linda] Just like Routes Advertisement, receivers can improperly install
> the routes into their RIB/FIB.  BGP has been running for over 3 decades.
> Those who don’t implement correctly eventually fix their bugs.
>
>  If the Policies sent to peers are not enforced  as the RPD is asking for,
>  traffic might be sent to non-preferred links, just like a BGP receiver
> incorrectly processes the BGP route updates.
>
>
>
> - Feedback:
>
>   BGP is "spray and pray".
>
>   Netconf provides an acknowledgement that the config either failed or was
> applied,
>
>   which then allows the controller to take the next steps with
>
>   reliable information about what configuration exists in the network.
>
>
>
> [Linda]  BGP UPDATE is over reliable TCP transport and BGP protocol itself
> can guarantee the proper distribution of the UDPATE. Therefore, its “spray
> and pray” nature has its advantage of optimized processing. BGP  Route
> Update doesn’t expect confirmation from  the receivers.
>
>
>
> - Persistence:
>
>   If the BGP session were to go down, all the configuration it sent will
> be implicitly withdrawn.
>
>
>
> If another AS would not allow a foreign AS to configure it with netconf,
>
> it would not allow it with RPD either.
>
> [Linda] That is very true. The originator can only “Pray” as BGP is
> intended for.
>
>
>
> There are already ways in BGP for an AS to signal preference across AS
> boundaries:
>
> Med, AS-path length, communities.
>
>
>
> [Linda] All those methods you have mentioned require heavy duty
> configurations, which is difficult to change on the fly. The proposed
> method is a flexible method which allows policies to be changed on the fly
> (depending on real time traffic conditions).
>
>
>
>
>
> Ketan and Robert added other objections.
>
> [Linda] I have been studying their reasons for the objections.
>
>
>
> Thank 

Re: [GROW] IETF 107, virtual hackathon, BGP Monitoring Protocol

[Robert Raszuk]

Hi,

Pretty cool ! Thx for sharing.

Along the same lines are there some other recommended packages to be used
not so much for collection itself, but for building custom periodic queries
for collected BGP or RPKI data ?

Just curious what GROW folks use to actually run some useful
measurements once BGP data flows in :)

Is everyone is just using their own DB insertion schema and run custom home
made queries ?

I know OpenBMP. Any more interesting pointers ?

Cheers,
Robert.


On Mon, Apr 20, 2020 at 2:08 PM  wrote:

> Dear GROW WG,
>
>
>
> Since the IETF 107 hackathon was officially canceled, the BMP group
> decided to do a virtual hackathon instead and continued to work on
> improving BMP running code.
>
>
>
> Attached you will find an overview about our improved lab environment, on
> what we were working on and plans for the IETF 108 hackathon. Feedback very
> welcome.
>
>
>
> Work on BMP data collection has been fed into the open source project
> pmacct and is accessible on github (https://github.com/pmacct/pmacct/).
>
>
>
> Best Wishes
>
> Thomas Graf
> ___
> 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] Playing with origin validation

[Robert Raszuk]

Thank you Job & Nick for your comments. They pretty much do confirm what I
was suspecting that the ROA may be incorrect.

I am looking at this topic from the perspective of stub enterprise AS not a
transit operator. So with that being said in such cases of INVALID ASN I
could potentially drop it from entering my DMZ routing. Currently just
playing with lowering a bit local pref. And I am getting those prefixes
like this one from multiple peers.

In fact I found this one 45.227.254.0/24 and many others which drew my
attention by adding an automated correlation of invalid ROAs to my TCP
analyzer watching 100% of my Internet in/out traffic.

Most prefixes marked as INVALID are actually turning up as covering sources
of TCP attacks !  But not all. So I digged a bit more and found that those
which are legitimate INVALID are INVALID LENGTH not INVALID ASN.

Pretty bad that routers have no options to distinguish one vs the other
state when performing origin validation.

Of course as a workaround I could feed them with only INVALID ASN ROAs
validated on the server, but I do not recall anyone so far recommended such
practice. Those who drop INVALID would by default drop both ASN or LENGTH
isn't it ?

See another point here is that if I am at the DMZ and if I am seeing quite
a nice correlation of attacks with INVALID ASN it is tempted to apply those
prefixes as src drop ACLs shielding my servers or other DMZ infra from the
attacks. Of course cluster of inline IPS are supposed to filter those just
by learning traffic patterns on a /32 or /128 basis, but with Nx10G of
traffic they get pretty busy anyway.

Last on the part of INVALID LENGTH  ... Imagine I owe /19 of IPv4 and I am
allocating /24s in many of my global DMZs. If I do not sign my /19
aggregate I have no problem as it will be globally not found. But the
moment I sign it I must also sign all /24s I advertise as otherwise they
will become INVALID - right ? So now each time any engineering group
globally injects new /24 they also must also sign it ... Can you imagine
the operational burden here in a global company when the RPKI operation is
usually centralized ? No wonder that RIPE Validator shows 1700+ INVALID
LENGTH prefixes.

And at least in IOS XE as mentioned above I do not see a way to only
validate against INVALID ASN.

To the point Randy shared - I am afraid if prefix is leased from some
operator who is RPKI aware to the one which is not which could likely be
the root cause on the example I provided I am not sure there is process in
place to make sure the obsolete data is erased. If this is just up to
humans it is pretty much guaranteed it is going to be wrong.

Many thx all,
R.

On Sun, Apr 12, 2020 at 9:51 PM Job Snijders  wrote:

> On Sun, Apr 12, 2020 at 08:39:58PM +0200, Robert Raszuk wrote:
> > Would anyone be able to explain the below phenomenon?
> >
> > RPKI Origin validation marks net 45.227.254.0/24 as INVALID as it
> expects
> > it to be originated by ASN: 395978
>
> If you look at https://stat.ripe.net/45.227.254.0%2F24#tabId=routing you
> can see that the prefix is only seen by 72% of the RIPE RIS collectors,
> this is a very low score, I'd consider this a problematic network
> outage. If you'd have internet access users serviced out of the block it
> probably would mean many websites don't work, or don't work well.
>
> In the 'Routing History' widget we can see:
>
> May 2018 - Jul 2018 - AS 395978
>Aug 2018 - AS 62088
> Oct 2018 - Mar 2019 - AS 42260
> Feb 2019 - Mar 2020 - AS 51852
>
> I guess early someone deemed AS 395978 deemed to be the right origin ASN
> and create RPKI ROAs, but subsequently didn't update these RPKI ROAs to
> the new ASNs as the space moved from lessee to lessee. I suspect IP
> address leasing is in play because the announcement periods don't seem
> to overlap, suggesting there might have been coordination between
> previous and next Origin ASN.
>
> Since the ROA still exists, whoever created the ROA (to authorize
> 395978) still is in authority, so from an operational perspective it is
> incumbent on that entity to correct the RPKI information. If the space
> had been transferred from one LIR to another LIR the 'offending' ROA
> would've been deleted in that transfer process.
>
> > But it comes from  51852 which according to ipinfo or bgpview is
> > legitimate ASN:
> >
> > https://ipinfo.io/AS51852/45.227.254.0/24
> > https://bgpview.io/prefix/45.227.254.0/24
>
> I am not sure in what way you are reading the data, the information
> displayed here doesn't weigh in on legitimacy. Both websites are
> frontends to public whois data, they shows the prefix is suballocated to
> 'Xwin universal ltd', but the originating ASN is 'Private Layer INC'.
>
> > As I see similar discrepancies in many global networks I would like to
>

[GROW] Playing with origin validation

[Robert Raszuk]

Hi,

Would anyone be able to explain the below phenomenon?

RPKI Origin validation marks net 45.227.254.0/24 as INVALID as it expects
it to be originated by ASN: 395978

c1001-08-10#sh ip bgp 45.227.254.0/24
BGP routing table entry for 45.227.254.0/24, version 221816327
Paths: (1 available, no best path)
  Not advertised to any peer
  Refresh Epoch 1
  6461 3257 42624 *51852*
128.177.133.177 from 128.177.133.177 (64.125.0.193)
  Origin IGP, metric 100, localpref 90, valid, external
  Community: 423434093
  path 7F76F542CF58 *RPKI State invalid*
  rx pathid: 0, tx pathid: 0

c1001-08-10#show ip bgp rpki table | inclu 45.227.254.0
45.227.254.0/24  24  395978 0   10.250.80.18/8082
45.227.254.0/24  24  395978 0   10.250.80.18/8323
c1001-08-10#

But it comes from  51852 which according to ipinfo or bgpview is legitimate
ASN:

https://ipinfo.io/AS51852/45.227.254.0/24
https://bgpview.io/prefix/45.227.254.0/24

As I see similar discrepancies in many global networks I would like to ask
who to trust ? If RPKI data is not valid then I think we have a real
problem.

The particular net is a bit interesting ...

cleantalk.org reports it is coming from Swiss:
https://cleantalk.org/whois/45.227.254.0 but in the same time when searched
..240/32 is suddenly reported coming from germany and is marked as spam:
https://cleantalk.org/whois/45.227.254.240

Many thx,
Robert.
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Question about BGP Large Communities

[Robert Raszuk]

Just to clarify one subtle point.

In wide communities types are either operator assigned or IANA driven - no
new code from vendor is required in contrast to extended community. That
along with variable length is what makes wide communities universal.

Sure that some vendors or individuals are scared about policy aspect of
wide communities processing - but implementing policy handling any
arbitrary types (irrespective of IANA or local assignment) is optional.

- - -

To the topic of using Large Communities - I do recommend whichever encoding
is chosen to always be able to insert and carry originator's ASN. All zeros
are meaningless read: anonymous.

Thx,
R.


On Wed, Feb 5, 2020 at 2:45 AM Brian Dickson 
wrote:

> 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
>>
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Question about BGP Large Communities

[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

[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] [Idr] Question about BGP Large Communities

[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] BGP Auto Discovery and BGP Auto Session Setup

[Robert Raszuk]

Hello Alejandro,

Many thx for your comments.

To respond to your question there is no preference to the best path
selection process based on the method BGP session is established.

Of course one could you this method just as a validation of manual mesh
correctness or rather completeness, but if so while routers could keep list
of autodiscover peers we would not necessarily establish actual BGP
sessions to those if NMS or manual sessions are already present.

Said all of this if you and others think there is need to work more on your
point I am open to hear the actual justification.

Many thanks,
Robert


On Thu, Dec 12, 2019 at 3:47 AM Alejandro Acosta <
alejandroacostaal...@gmail.com> wrote:

> Hello Robert,
>
>  I just read the first document, I guess for most people could be
> "interesting" too see BGP Auto Discovery, I'm not sure yet if I'm in favor
> or against.
>
>  Hope this is not a crazy comment. Well, in the document you (and other
> co-authors) do not mention much about -any possible- impact this mechanism
> could have in bgp route selection algorithm (which anyhow is by default
> managed by vendors and modified by administrators). As far as I could
> understand from your doc, routers can identify which prefixes were learnt
> by auto-discovered devices and which were learnt by the "traditional" BGP
> operation. Am I right? which one would you trust more?, new administrative
> distance or something like that?.
>
>
> Thanks,
>
>
> Alejandro,
>
>
> On 12/11/19 3:24 PM, Robert Raszuk wrote:
>
> Dear WG,
>
> We have seen formation of BGP Autodiscovery WG followed by total silence.
> Well maybe group is
> live just not everyone got onto its private list :)
>
> Regardless of this I refreshed and resubmitted two proposals in this very
> space.
>
> 1. BGP Auto Discovery
>
> https://tools.ietf.org/html/draft-raszuk-idr-bgp-auto-discovery-06
>
> and
>
>  2. BGP Automated Session Setup
>
> https://tools.ietf.org/html/draft-raszuk-idr-bgp-auto-session-setup-01
>
>  *Ad 1:*
>
>  First document is focused on WAN and IX scenario where establishing full 
> mesh of IBGP or
>
> selected eBGP peering can automate the operational management tasks or if run 
> in informational
>
> mode could validate NMS session setup correctness.
>
>  Original proposal was presented many years ago in Vienna and at that point 
> suggested extension to
>
> IGPs to flood discovery information for IBGP auto mesh. Later based on the 
> input and discussions with
>
> Pedro the proposal got simplified to use classic Route Reflector as bootstrap 
> node (info broker).
>
>  Last input from Jon and Warren added the ability to also automate setup of 
> eBGP sessions in selected
>
> scenarios.
>
>  Since then the document was shelved for some time waiting for IDR WG turn to 
> deal with discovery topic.
>
>  So here we are.
>
>  *Ad 2: *
>
>  The second document first published in July 2018 provides a very trivial to 
> implement mechanism (without
>
> even changing BGP state machine) to automatically establish common LAN or p2p 
> interfaces BGP sessions.
>
>  Typical use case would be Clos DC fabrics, customer PE-CE LANs, TORs to 
> Compute Nodes etc ...
>
>  Comments, questions, feedback on both proposals all very welcome.
>
>  Kind regards,
>
> Robert.
>
>
> ___
> GROW mailing listGROW@ietf.orghttps://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

[GROW] BGP Auto Discovery and BGP Auto Session Setup

[Robert Raszuk]

Dear WG,

We have seen formation of BGP Autodiscovery WG followed by total silence.
Well maybe group is
live just not everyone got onto its private list :)

Regardless of this I refreshed and resubmitted two proposals in this very
space.

1. BGP Auto Discovery

https://tools.ietf.org/html/draft-raszuk-idr-bgp-auto-discovery-06

and


2. BGP Automated Session Setup

https://tools.ietf.org/html/draft-raszuk-idr-bgp-auto-session-setup-01


*Ad 1:*


First document is focused on WAN and IX scenario where establishing
full mesh of IBGP or

selected eBGP peering can automate the operational management tasks or
if run in informational

mode could validate NMS session setup correctness.


Original proposal was presented many years ago in Vienna and at that
point suggested extension to

IGPs to flood discovery information for IBGP auto mesh. Later based on
the input and discussions with

Pedro the proposal got simplified to use classic Route Reflector as
bootstrap node (info broker).


Last input from Jon and Warren added the ability to also automate
setup of eBGP sessions in selected

scenarios.


Since then the document was shelved for some time waiting for IDR WG
turn to deal with discovery topic.


So here we are.


*Ad 2: *


The second document first published in July 2018 provides a very
trivial to implement mechanism (without

even changing BGP state machine) to automatically establish common LAN
or p2p interfaces BGP sessions.


Typical use case would be Clos DC fabrics, customer PE-CE LANs, TORs
to Compute Nodes etc ...


Comments, questions, feedback on both proposals all very welcome.


Kind regards,

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

Re: [GROW] Information model for BGP Communities (Was: Proposed updates to GROW charter)

[Robert Raszuk]

All,

I think the common description is a good thing and not so hard to build.

What I think would be a bit more challenging is to create a protocol
extension where each AS (adjucent or not) would be able to signal set of
communities it honors and supports in an automated way.

Today it is all manual web based thing ... I think sooner or later we need
to depart from it.

Cheers,
R.

On Fri, Nov 22, 2019 at 12:18 PM Jeffrey Haas  wrote:

> Having gone through a flavor of this issue as part of the wide communities
> work, I think you’ll find it a bit more constrained than you might think.
>
> For purposes of a yang model, the main short term question is whether you
> wish to collapse some of the actions to common ones that might be modeled
> as Yang identities.
>
> Examples of this would include prepend N times. Set local preference. Set
> or adjust MED. Etc.
>
> Once the catalog is built, standardization is no longer the hard part.
>
> Jeff
>
> > On Nov 22, 2019, at 12:07, Job Snijders  wrote:
> >
> > Forking this thread.
> >
> >> On Fri, Nov 22, 2019 at 03:44:26AM +, thomas.g...@swisscom.com
> wrote:
> >> Very good input regarding „Devise a BGP Community Description System
> >> to IESG.
> >>
> >> I think a YANG informational BGP community modell might be the right
> >> thing to do. I would volunteer to support such an approach.
> >>
> >> I think it is good to keep the charter generic. I like your proposal.
> >>
> >> I would be interested to know if others on the mailing list share my
> >> opinion on using YANG information model.
> >
> > I would suggest to talk technology specifics in a new thread, and would
> > also like to suggest we first get a better handle on the goal and
> > problem space definition. This probably is a quite large project.
> >
> > 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] BGP deaggregation

[Robert Raszuk]

Hi Brian,

Well your idea of not sending more specifics downstream would be really a
cool one if all Tier 1s would fully mesh with each other and exchange those
more specifics. Then indeed yes there would be no reason to send those
downstream.

But I am afraid this is not yet the reality we face.

Thx,
R.

On Wed, Nov 20, 2019 at 3:49 AM Brian Dickson 
wrote:

>
>
> On Mon, Nov 4, 2019 at 6:43 AM Christopher Morrow <
> christopher.mor...@gmail.com> wrote:
>
>> Where does it no longer make sense to deaggregate? Isn't that a bunch
>> related to what problem the initial announcement is trying to solve?
>>
>>
> I just realized this question might not have had an answer, or not the
> following answer at least:
>
> Deaggregates should only go "upstream", to transit providers (and their
> transit providers).
>
> It might be possible to apply restrictions to achieve this goal, using
> mechanisms made available when the "route leaks mitigation" draft gets
> adopted (and deployed).
>
> I believe it should be possible to tag the deaggregates differently than
> the aggregate itself, to differentially propagate/filter them (and prevent
> the deaggregates from going to peers or customers).
>
> Or, it might be something that requires an additional community, maybe add
> to the mitigation draft once adopted.
>
> Brian (co-author on the mitigations draft)
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] BGP deaggregation

[Robert Raszuk]

> I’m sure someone else will take up the slots almost immediately.

Hehe and what stops that someone to inject those more specifics today
before you take back yours :) ? Last time I looked at BGP UPDATE I did not
notice any TDM like slots there :)

If BGP announcements would be having free quota per allocation size from
given Originating AS we would have very different Internet table size
today.

For good or for bad we would also have a very well developed hierarchical
routing in the Internet as opposed to mainly flat model.

R.




On Mon, Nov 4, 2019 at 3:29 PM Jared Mauch  wrote:

>
>
> > On Nov 3, 2019, at 5:42 PM, Christopher Morrow <
> christopher.mor...@gmail.com> wrote:
> >
> > Where does it no longer make sense to deaggregate? Isn't that a bunch
> related to what problem the initial announcement is trying to solve?
>
> I’m looking to get rid of some of our more specifics in 2020 which should
> help reduce the table size, but I’m sure someone else will take up the
> slots almost immediately.
>
> - Jared
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] BGP deaggregation

[Robert Raszuk]

Hi Christopher,

Where does it no longer make sense to deaggregate? Isn't that a bunch
> related to what problem the initial announcement is trying to solve?
>

My answer is - If routing path to destination by more specific would be
identical to the path covered by less specific prefix.

Based on some work on this in the past I do believe such "sweet spots" can
be identified especially with average AS_PATH length being less then 4.

Of course PA space is much easier then PI but both are possible to be
aggregated.

Would it cover all cases - perhaps no. Would it cover a lot of cases -
likely yes.

But before we spend more time on this let's answer one question which was
asked before - do we have a problem ? Of course 1 mln routes is easier to
be handled then 5 mln, but then you may stop upgrading hardware :) Not a
colorful future for those who need to invest in their software ...

Hi Job,

>   We need to document the cases where the business intentions and the
reality of what happens in the internet routing system don’t match up.

Fully agree and volunteer to help. Also in many cases we may indeed find
that deaggregation is purely accidental ... however those who cause it just
have no control to aggregate it or suppress announcements N AS hops away.
So we could start picking low hanging fruits like Tony's
draft-ietf-idr-as-pathlimit-03.

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

[GROW] BGP deaggregation

[Robert Raszuk]

Folks,

Allow me to express a bit of a different view - this time from enterprise
perspective.

Actually announcing more specifics of the block one owns has real service
advantages. So in itself it is actually a good thing !

What is bad for Internet is propagating those more specific routes beyond
the point that they make any difference any longer.

There was proposal to aggregate those at dynamic points where sending them
no longer brings any service/routing advantages, but apparently at that
time no one cared much:

https://www.ietf.org/archive/id/draft-marques-idr-aggregate-00.txt

- - -

See assume I own /19 for a global network. I can't possibly announce that
block via all of my 20 ISP peerings globally as top requirement is not to
keep the Internet BGP table tiny, but rather to offer best service to
customers.

Further more imagine I offer various services based on geo location. For
customers in Japan I want them to go to Japan DMZ and not float to any
other location just because his ISP is one AS hop away from NY and two AS
hops away from Osaka or Tokyo ISPs I peer with. So if I would attract such
service to US I would need to carry it back to Tokyo over global WAN -
disaster.

See even /24 is a very coarse limit one has to deal with. I may have few
gateways for a given service per site not 255. And each service has
completely different service requirements from the network characteristic.
If I have 8 ISPs there

It is very clear (at least to some) that basic BGP best path routing is
suboptimal. For years folks have been using SLA based routing to steer
packets over non necessarily BGP best path between Internet endpoints. The
more fine are the announcements the better egress path selection can be
achieved. So the Internet is no longer used to reach A & B. It is used to
reach A & B in most optimal way for a given application.

Let's therefore keep those points in mind while blindly bashing
"deaggregation" and calling names those who do it :). I bet no one is doing
that just for fun.

Enterprises are doing it to provide the best level of service. ISPs do it
to serve the needs of their customers. It is feasible to enhance BGP to
aggregate when it no longer makes sense to carry more specific prefixes -
let's rethink this.

Thx,
R.


On Sun, Nov 3, 2019 at 8:41 PM Nick Hilliard  wrote:

> Gert Doering wrote on 03/11/2019 19:15:
> > On Sun, Nov 03, 2019 at 03:10:29PM +, Martijn Schmidt wrote:
> >>> Maybe "BGP Deaggregation Slopping" as a working title?
> >> Or "Scenic BGP Deaggregation", or "BGP Globetrotting", or "BGP
> >> Castaways". If anything a connotation with the sea and/or submarine
> >> cables would be appropriate, I think!
> >
> > "BGP vandalism"
>
> "Noxious Routing"?
>
> Nick
>
> ___
> 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] Proposed updates to GROW charter

[Robert Raszuk]

Hi Job,

As others pointed out I think the goals would benefit from being more
precise.

As example I see third goal very generic which could include everything for
next years to come ;)

On the other hand if it is not explicit it may be harder for GROW to go via
IESG with some work.

Examples which I would suggest to get added:

* work on ops practices of performance based routing

* work on ops practices of sdwan deployments using bgp

* work on ops aspects of internet te

etc..

Many thx
R.



On Mon, Oct 28, 2019, 15:21 Job Snijders  wrote:

> Dear working group, AD,
>
> Warren asked us as chairs to assess whether revising the GROW charter
> was warrented, and if so propose an update. We've come up with the
> below.
>
> It is entirely possible we've overlooked something, we'd love your
> feedback on the below charter, goals & milestones. Please share on-list
> or off-list with grow-cha...@ietf.org
>
> Kind regards,
>
> Job & Chris
> GROW chairs
>
>
> Charter for GROW Working Group
> ===
>
> The Border Gateway Protocol (BGP) is fundamental to the operation of the
> Internet. In recent years, occurrences of BGP related operational issues
> have increased, and while overall understanding of the default-free
> routing system has improved, there is still a long and growing list of
> concerns. Among these are routing table growth rates, interaction of
> interior and exterior routing protocols, dynamic properties of the
> routing system, and the effects of routing policy on both the size and
> dynamic nature of the routing table. In addition, new and innovative
> uses of BGP, such as the use of BGP as a signaling protocol for some
> types of Virtual Private Networks, have created new and unexpected
> operational issues.
>
> The purpose of the GROW is to consider the operational problems
> associated with the IPv4 and IPv6 global routing systems, including but
> not limited to routing table growth, the effects of the interactions
> between interior and exterior routing protocols, and the effect of
> address allocation policies and practices on the global routing system.
> Finally, where appropriate, the GROW documents the operational aspects
> of measurement, monitoring, policy, security, and VPN infrastructures,
> and safe default behavior of implementations.
>
> GROW will also advise various working groups, specifically the IDR and
> SIDROPS working groups, with respect to whether it is addressing the
> relevant operational and routing security needs of networks, and where
> appropriate, suggest course corrections or intervene. Finally,
> operational requirements developed in GROW can also be used by any new
> working group charged with standardizing a next generation inter-domain
> routing protocol.
>
> Goals
> =
>
> * Provide stewardship and maintenance for the BGP Monitoring Protocol
>   (BMP)
> * Document Best Current Practises for operations of the Internet routing
>   system.
> * Analyze aspects of supporting new applications, including extending
>   existing routing protocols and creating new ones. This includes risk,
>   interference and application fit.
> * Document the operational aspects of securing the Internet routing
>   system, and provide recommendations to other WGs.
> * Provide documentation to assist in avoiding clear malpractice in the
>   global routing system.
>
> Milestones
> ==
>
> Jan 2020 - "Support for Local RIB in BGP Monitoring Protocol (BMP)" to IESG
> Feb 2020 - "BMP Peer Up Message Namespace" to IESG
> Apr 2020 - "Revision to Registration Procedures for Multiple BMP
> Registries" to IESG.
> Jul 2020 - “Document negative consequences of de-aggregating received
> routes for traffic engineering purposes” - to IESG
> Nov 2020 - "TLV support for BMP Route Monitoring and Peer Down Messages"
> to IESG.
> Jan 2021 - “A BCP on using IRR and RPKI data to improve filtering of BGP
> peering sessions” to IESG or via “Evolving Documents”
>
> ___
> 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] Request WG Adoption for draft-sa-grow-maxprefix

[Robert Raszuk]

> If closer to the time of publication of this draft there is another
standard that may impact decisions here, yes that would be prudent to
consider.

IMHO even if such standard appears *after* publication  of this draft
having that in apriori would be a pure plus :)

Cheers,
R.


On Fri, Jul 26, 2019 at 7:58 PM Job Snijders  wrote:

> On Fri, Jul 26, 2019 at 13:54 Robert Raszuk  wrote:
>
>> Hello Job,
>>
>> You'll
>>> notice from the draft that once the limit is reached a CEASE
>>> Notification is sent; so I am not sure if the priority truly matters in
>>> context of tearing down the session.
>>>
>>
>> And I am not sure if CEASE matters in the context of BGP Persistence
>> efforts :)
>>
>
> Good feedback. I’ll have to rely on the GROW and IDR WGs to help
> understand how we view CEASE in this context and what must be done.
>
>
>> If you have specific suggestions what text and considerations should be
>>> added to the draft I would welcome that.
>>>
>>
>> I would suggest to just add a sentence that the actual number of prefixes
>> sent
>> without warning or error (session drop) should be a smallest number of
>> prefixes
>> either which were locally configured or pushed from the peer.
>>
>
>
> If closer to the time of publication of this draft there is another
> standard that may impact decisions here, yes that would be prudent to
> consider.
>
> Kind regards,
>
> Job
>
>>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Request WG Adoption for draft-sa-grow-maxprefix

[Robert Raszuk]

Hello Job,

You'll
> notice from the draft that once the limit is reached a CEASE
> Notification is sent; so I am not sure if the priority truly matters in
> context of tearing down the session.
>

And I am not sure if CEASE matters in the context of BGP Persistence
efforts :)

If you have specific suggestions what text and considerations should be
> added to the draft I would welcome that.
>

I would suggest to just add a sentence that the actual number of prefixes
sent
without warning or error (session drop) should be a smallest number of
prefixes
either which were locally configured or pushed from the peer.

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

Re: [GROW] Request WG Adoption for draft-sa-grow-maxprefix

[Robert Raszuk]

All,

I would like to raise three points in respect to this draft:

Point 1:

The topic of outbound prefix limit is not new :) It has been discussed
number of times within vendors and between vendors. But one requirement
when we are talking about outbound prefix limit is which prefixes should be
sent first - which are more important then others - so prefix
prioritization in update generation and update scheduling comes up. Are we
sure that this is not going to happen here ? Sure not in this draft, but
once you build the road emergency vehicles and regular vehicles will try to
use it. And while outbound prefix limit looks innocent the moment we start
to ask for prioritizing prefixes some bgp implementations may have a bit of
hard time.

Point 2:

The draft is still silent on the question I posted to the list regarding
this idea in respect to decision which limit is more important ? Locally
configured outbound limit or pushed by prefix limit ORF peers inbound limit
? What should be the action of the sender when those two numbers are not
equal ? I think this must be precisely spelled out here.

Point 3:

For inbound prefix limit the position if this should be pre or post policy
should be IMHO a local configuration decision. See if I decide to keep full
table in my Adj_RIB_In maybe just for BMP use no spec should prevent that.
Maybe it would be worth to add this explicitly to the draft in addition to
listing those two measurement insertion locations :)

Many thx
Robert



On Thu, Jul 25, 2019 at 2:00 PM Melchior Aelmans 
wrote:

> Hi WG,
>
> We would like to request WG adoption for
> https://datatracker.ietf.org/doc/draft-sa-grow-maxprefix/
>
> Thanks,
> Melchior
> ___
> 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] Prefix limit ORF: add grace time

[Robert Raszuk]

Hi,

Prefix-limit is a feature which was originally invented to save BGP table
size in the cases of L3VPN such that any VPN site with dynamic routing
protocol could not overflow control plane capacity of PE it is attached to.

A bit later it has been extended to cover also BGP sessions not related to
VPNs/VRFs.

As such the prefix limit behavior is an independent vendor choice on how to
implement it. For example there can be a knob not to reset the session at
all but just log warning. There can be a knob to auto restart the session
etc  To the best of my knowledge there is no spec defining what prefix
limit inbound or outbound (if we ever get there) should do.

Job had a presentation during last GROW meeting on that.

Here the draft from Keyur only defines the ORF mechanism on how to
communicate such limit between peers. It really does not define how the
prefix limit should be handled by either side.

Maybe we need new document to specify it provided vendor would agree to
adjust their current zoo of implementations 

Kind regards,
R.

On Tue, Apr 2, 2019 at 11:21 AM Maria Matějka  wrote:

> Thank you for clarifying this. Therefore it has no sense to make it more
> complicated in this way.
>
> Anyway, I'd like to have there at least a note saying that if the prefix
> limit is too tight, you may get an unwanted bgp session drop simply due
> to temporary conditions. Is this reasonable?
>
> Thanks
> Maria
>
> On 4/1/19 7:54 PM, Robert Raszuk wrote:
> > Well you still need to indicate to prefix limit check when it should
> > start x2 multiplication and when the specific upgrade which requires it
> > is over.
> >
> > Note that vast majority of customers use prefix limit as a safety fuse
> > normally allowing x2 or even x5 under normal operation.
> >
> > Best,
> > R.
> >
> > On Mon, Apr 1, 2019, 19:50 Maria Matějka  > <mailto:jan.mate...@nic.cz>> wrote:
> >
> > Oops, I forgot to write there that during the grace period the limit
> > should be only temporarily raised by a factor of 2 to allow complete
> > route exchange, not lifted at all.
> >
> > I think this would be much simpler for the users than fiddling with
> > the limit more times.
> >
> > Thx
> > Mariais
> >
> > On April 1, 2019 6:30:45 PM GMT+02:00, Robert Raszuk
> > mailto:rob...@raszuk.net>> wrote:
> >
> > Hi Maria,
> >
> > So your suggestion is not to apply this limit at all (ie. have
> > unlimited transient) - don't you think that in such a case your
> > weakest network elements may just crash if say they expect 10
> > and will get 700K prefixes ?
> >
> > I think what you are asking for can be easily achieved today
> > during described migration if you adjust the prefix limit to
> > some controlled higher value before your planned policy change
> > then simply revert it back. Seems like very safe and problem
> > free operation.
> >
> > Many thx,
> > R.
> >
> > On Mon, Apr 1, 2019 at 5:29 PM Maria Matějka  > <mailto:jan.mate...@nic.cz>> wrote:
> >
> > Hello!
> >
> > I'd like to suggest adding a grace time to the Prefix Limit
> > ORF-Type.
> > Its purpose is to allow temporary overrun of the limit while
> > reloading
> > the routes after a policy is changed.
> >
> > Why: If the peer exports e.g. 2001:db8:0/48 through
> > 2001:db8:7/48 and
> > it wants to substitute them for 2001:db8:0/45, it first has
> > to add the
> > less specific prefix and then drop the more specific
> > prefixes. Doing this
> > on large scale may override the limits temporarily which
> > would lead to
> > unneeded BGP session drop.
> >
> > Here are the changes to be done to the RFC text:
> >
> > * append to section 3:
> > The "Grace-Time" is a two-byte unsigned integer. It
> > indicates
> > the number of seconds for which the Prefix-Limit can
> > be exceeded.
> >
> > * append to section 4 the Grace-Time directly after the
> > Prefix-Limit
> >
> > * insert to section 6.1.1 after 2nd paragraph:
> > The sending speaker MUST wait for the Grace-Time
> > period before
> >  

Re: [GROW] Prefix limit ORF: add grace time

[Robert Raszuk]

Well you still need to indicate to prefix limit check when it should start
x2 multiplication and when the specific upgrade which requires it is over.

Note that vast majority of customers use prefix limit as a safety fuse
normally allowing x2 or even x5 under normal operation.

Best,
R.

On Mon, Apr 1, 2019, 19:50 Maria Matějka  wrote:

> Oops, I forgot to write there that during the grace period the limit
> should be only temporarily raised by a factor of 2 to allow complete route
> exchange, not lifted at all.
>
> I think this would be much simpler for the users than fiddling with the
> limit more times.
>
> Thx
> Maria
>
> On April 1, 2019 6:30:45 PM GMT+02:00, Robert Raszuk 
> wrote:
>>
>> Hi Maria,
>>
>> So your suggestion is not to apply this limit at all (ie. have unlimited
>> transient) - don't you think that in such a case your weakest network
>> elements may just crash if say they expect 10 and will get 700K prefixes ?
>>
>> I think what you are asking for can be easily achieved today during
>> described migration if you adjust the prefix limit to some controlled
>> higher value before your planned policy change then simply revert it back.
>> Seems like very safe and problem free operation.
>>
>> Many thx,
>> R.
>>
>> On Mon, Apr 1, 2019 at 5:29 PM Maria Matějka  wrote:
>>
>>> Hello!
>>>
>>> I'd like to suggest adding a grace time to the Prefix Limit ORF-Type.
>>> Its purpose is to allow temporary overrun of the limit while reloading
>>> the routes after a policy is changed.
>>>
>>> Why: If the peer exports e.g. 2001:db8:0/48 through 2001:db8:7/48 and
>>> it wants to substitute them for 2001:db8:0/45, it first has to add the
>>> less specific prefix and then drop the more specific prefixes. Doing this
>>> on large scale may override the limits temporarily which would lead to
>>> unneeded BGP session drop.
>>>
>>> Here are the changes to be done to the RFC text:
>>>
>>> * append to section 3:
>>> The "Grace-Time" is a two-byte unsigned integer. It indicates
>>> the number of seconds for which the Prefix-Limit can be exceeded.
>>>
>>> * append to section 4 the Grace-Time directly after the Prefix-Limit
>>>
>>> * insert to section 6.1.1 after 2nd paragraph:
>>> The sending speaker MUST wait for the Grace-Time period before
>>> taking corrective action. If the peer gets from the Prefix-Limit
>>> violation during the Grace-Time period, no corrective action is
>>> taken.
>>> The Grace-Time period is reset every time the violation is gone..
>>>
>>> Thank you for cnnsidering my suggestion
>>> Maria
>>>
>>> ___
>>> GROW mailing list
>>> GROW@ietf.org
>>> https://www.ietf.org/mailman/listinfo/grow
>>>
>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Prefix limit ORF: add grace time

[Robert Raszuk]

Hi Maria,

So your suggestion is not to apply this limit at all (ie. have unlimited
transient) - don't you think that in such a case your weakest network
elements may just crash if say they expect 10 and will get 700K prefixes ?

I think what you are asking for can be easily achieved today during
described migration if you adjust the prefix limit to some controlled
higher value before your planned policy change then simply revert it back.
Seems like very safe and problem free operation.

Many thx,
R.

On Mon, Apr 1, 2019 at 5:29 PM Maria Matějka  wrote:

> Hello!
>
> I'd like to suggest adding a grace time to the Prefix Limit ORF-Type.
> Its purpose is to allow temporary overrun of the limit while reloading
> the routes after a policy is changed.
>
> Why: If the peer exports e.g. 2001:db8:0/48 through 2001:db8:7/48 and
> it wants to substitute them for 2001:db8:0/45, it first has to add the
> less specific prefix and then drop the more specific prefixes. Doing this
> on large scale may override the limits temporarily which would lead to
> unneeded BGP session drop.
>
> Here are the changes to be done to the RFC text:
>
> * append to section 3:
> The "Grace-Time" is a two-byte unsigned integer. It indicates
> the number of seconds for which the Prefix-Limit can be exceeded.
>
> * append to section 4 the Grace-Time directly after the Prefix-Limit
>
> * insert to section 6.1.1 after 2nd paragraph:
> The sending speaker MUST wait for the Grace-Time period before
> taking corrective action. If the peer gets from the Prefix-Limit
> violation during the Grace-Time period, no corrective action is
> taken.
> The Grace-Time period is reset every time the violation is gone.
>
> Thank you for cnnsidering my suggestion
> Maria
>
> ___
> 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] Prefix limit ORF

[Robert Raszuk]

And with this in mind the draft needs to define expected behaviour when
locally configured outbound prefix limit is different from ORF pushed one
(someone's inbound).

Lowest wins, static wins, latest wins etc ... otherwise each implementation
may choose differently ;)

thx
R.

On Tue, Mar 26, 2019, 16:59 John Scudder 
wrote:

> Apropos Job’s talk just now —
>
> draft-keyur-idr-bgp-prefix-limit-orf-03
> https://tools.ietf.org/html/draft-keyur-idr-bgp-prefix-limit-orf-03
>
> —John
> ___
> 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] I-D Action: draft-chen-grow-enhanced-as-loop-detection-00.txt

[Robert Raszuk]

*> In the BGP Update received from the eBGP peer, the eBGP peer has already
placed the local AS number in the *
*> AS-PATH. Thus, the device needs to analyze if the local AS is placed
improperly in the AS-PATH when it receives *
*> the Update.*

How is this different from basic AS-PATH loop detection done by any real
BGP speaker today ?

*>  this Update is not allowed to be advertised to this downstream AS. We
propose to do an outbound check *
*> enhancement for such advertisement failure.*

That is default behavior already in number of shipping BGP implementations.
In some other it depends on the update/peer group configuration.

r.


On Mon, Mar 18, 2019 at 10:22 AM Guyunan (Yunan Gu, IP Technology Research
Dept. NW)  wrote:

> *Hi Robert,*
>
>
>
> *Please see inline.*
>
>
>
>
>
> *From:* Robert Raszuk [mailto:rob...@raszuk.net]
> *Sent:* Saturday, March 16, 2019 7:38 AM
> *To:* Guyunan (Yunan Gu, IP Technology Research Dept. NW) <
> guyu...@huawei.com>
> *Cc:* grow@ietf.org; Brian Dickson 
> *Subject:* Re: [GROW] I-D Action:
> draft-chen-grow-enhanced-as-loop-detection-00.txt
>
>
>
> *> It’s capable of detecting the cases where the local AS is placed in the
> incorrect place of the AS-PATH*
>
>
>
> Such feature has been build into all BGP stacks for ages ... it is called
> "enforce-first-as".
>
>
>
> *Yunan: The BGP “enforce-first-as” is used to check if the incoming
> updates received from eBGP peers have their AS number as the first segment
> in the AS_PATH attribute. It’s not used to check the local AS placement.*
>
>
>
> Moreover there are BGP policies explicitly allowing you to place your
> local AS anywhere in the AS-PATH.
>
>
>
> See RPL knob: "replace as-path {[as-number-list] [parameter] | private-as}"
>
>
>
> *Yunan:  Yes, prepending the local AS by the local device in specific
> places of the AS-PATH is allowed. But here we are discussing the local AS
> placement by other devices: *
>
> *In the BGP Update received from the eBGP peer, the eBGP peer has already
> placed the local AS number in the AS-PATH. Thus, the device needs to
> analyze if the local AS is placed improperly in the AS-PATH when it
> receives the Update.*
>
> *This is the inbound check enhancement we propose in the draft. *
>
>
>
> So I am not sure what really does your draft is attempting to
> innovate/propose.
>
>
>
> *Yunan:  We also proposed the outbound check enhancement: Due to
> misconfiguration or attack in the local device or upstream BGP speaker
> mistake/hijack, the neighboring downstream AS is already placed in the
> AS-PATH. Thus with the Split-Horizon enabled, this Update is not allowed to
> be advertised to this downstream AS. We propose to do an outbound check
> enhancement for such advertisement failure. *
>
>
>
>
>
>
>
> Best,
>
> R.
>
>
>
>
>
>
>
> r.
>
>
>
> On Fri, Mar 15, 2019 at 11:03 AM Guyunan (Yunan Gu, IP Technology Research
> Dept. NW)  wrote:
>
> *Hi Robert,*
>
>
>
> *As stated in this draft, we only check the peering relationship between
> the local AS and it left/right AS as listed in the AS-PATH. Such peering
> relationship is maintained at the local database in whatever form. It’s
> capable of detecting the cases where the local AS is placed in the
> incorrect place of the AS-PATH, however it’s not capable of detecting other
> types of forged AS-PATHs (e.g., an extra AS1000 is inserted into the path).
> Although it only covers limited cases, it doesn’t require third-party
> information or inference. *
>
>
>
> *Agree that with a public and accurate database for a comprehensive check
> of the whole AS path, more cases can be detected. However, the building of
> such database still requires non-trivial work.  *
>
>
>
>
>
> *Yunan*
>
>
>
> *From:* GROW [mailto:grow-boun...@ietf.org] *On Behalf Of *Robert Raszuk
> *Sent:* Thursday, March 14, 2019 5:31 PM
> *To:* Brian Dickson 
> *Cc:* grow@ietf.org
> *Subject:* Re: [GROW] I-D Action:
> draft-chen-grow-enhanced-as-loop-detection-00.txt
>
>
>
> Hi Brian,
>
>
>
> Yes CAIDA has been an excellent source of data and tools for anyone
> concerned about Internet topology or BGP operation.
>
>
>
> It can also accurately detect a lot of anomalies and report them based on
> the comparison of historical data vs real time data (for example ARTEMIS)..
>
>
>
> But the proposed here mechanism compares in real time BGP updates to an
> oracle database for AS-PATH content accuracy. So any data which is based on
> AS-PATHs itself (to create the relations) I am afraid can not be used as
&g

Re: [GROW] I-D Action: draft-chen-grow-enhanced-as-loop-detection-00.txt

[Robert Raszuk]

*> It’s capable of detecting the cases where the local AS is placed in the
incorrect place of the AS-PATH*

Such feature has been build into all BGP stacks for ages ... it is called
"enforce-first-as".

Moreover there are BGP policies explicitly allowing you to place your local
AS anywhere in the AS-PATH.

See RPL knob: "replace as-path {[as-number-list] [parameter] | private-as}"

So I am not sure what really does your draft is attempting to
innovate/propose.

Best,
R.



r.

On Fri, Mar 15, 2019 at 11:03 AM Guyunan (Yunan Gu, IP Technology Research
Dept. NW)  wrote:

> *Hi Robert,*
>
>
>
> *As stated in this draft, we only check the peering relationship between
> the local AS and it left/right AS as listed in the AS-PATH. Such peering
> relationship is maintained at the local database in whatever form. It’s
> capable of detecting the cases where the local AS is placed in the
> incorrect place of the AS-PATH, however it’s not capable of detecting other
> types of forged AS-PATHs (e.g., an extra AS1000 is inserted into the path).
> Although it only covers limited cases, it doesn’t require third-party
> information or inference. *
>
>
>
> *Agree that with a public and accurate database for a comprehensive check
> of the whole AS path, more cases can be detected. However, the building of
> such database still requires non-trivial work.  *
>
>
>
>
>
> *Yunan*
>
>
>
> *From:* GROW [mailto:grow-boun...@ietf.org] *On Behalf Of *Robert Raszuk
> *Sent:* Thursday, March 14, 2019 5:31 PM
> *To:* Brian Dickson 
> *Cc:* grow@ietf.org
> *Subject:* Re: [GROW] I-D Action:
> draft-chen-grow-enhanced-as-loop-detection-00.txt
>
>
>
> Hi Brian,
>
>
>
> Yes CAIDA has been an excellent source of data and tools for anyone
> concerned about Internet topology or BGP operation.
>
>
>
> It can also accurately detect a lot of anomalies and report them based on
> the comparison of historical data vs real time data (for example ARTEMIS)..
>
>
>
> But the proposed here mechanism compares in real time BGP updates to an
> oracle database for AS-PATH content accuracy. So any data which is based on
> AS-PATHs itself (to create the relations) I am afraid can not be used as
> such baseline src to validate AS-PATHs correctness.
>
>
>
> Thx a lot,
> R.
>
>
>
>
>
>
>
> On Thu, Mar 14, 2019 at 1:20 AM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
> CAIDA has lots of data sets, tools, etc.
>
>
>
> Here's one of the README files I grabbed, with some URLs that would help
> you find the specifics, and reference materials (papers) on what/why/how
> they are able to infer these relationships.
>
>
>
> Brian
>
>
>
> The 'serial-2' directory contains AS relationships that combine the
>
> 'serial-1' AS relationships (inferred using the method described in
>
> "AS Relationships, Customer Cones, and Validation" published in
>
> IMC 2013, http://www.caida.org/publications/papers/2013/asrank/),
>
> with AS relationships inferred from Ark traceroutes, and from
>
> multilateral peering
>
> (
> http://www.caida.org/publications/papers/2013/inferring_multilateral_peering/
> ).
>
>
>
> To do this we first infer which AS owns each router independent of the
>
> interface addresses observed at that router. The ownership inferences
>
> are based on IP-to-AS mapping derived from public BGP data, list of
>
> peering prefixes from PeeringDB, and the previously inferred business AS
>
> relationships. Then we convert the observed IP path into an AS path
>
> using the router ownership information (rather than mapping each
>
> observed IP to AS directly) and retain the first AS link in the
>
> resulting path for the AS graph.
>
>
>
> The as-rel files contain p2p and p2c relationships.  The format is:
>
> ||-1
>
> ||0|
>
>
>
> 
>
> Acceptable Use Agreement
>
> 
>
>
>
> The AUA that you accepted when you were given access to these datas is
> included
>
> in pdf format as a separate file in the same directory as this README file.
>
> When referencing this data (as required by the AUA), please use:
>
>
>
> The CAIDA AS Relationships Dataset, 
>
> http://www.caida.org/data/active/as-relationships/
>
>
>
> Also, please, report your publication to CAIDA
>
> (http://www.caida.org/data/publications/report-publication.xml).
>
>
>
> On Mon, Mar 11, 2019 at 4:48 PM Robert Raszuk  wrote:
>
> Dear authors of draft-chen-grow-enhanced-as-loop-detection,
>
>
>
> The draft says:
>
>
>
>   &

Re: [GROW] I-D Action: draft-chen-grow-enhanced-as-loop-detection-00.txt

[Robert Raszuk]

Hi Brian,

Yes CAIDA has been an excellent source of data and tools for anyone
concerned about Internet topology or BGP operation.

It can also accurately detect a lot of anomalies and report them based on
the comparison of historical data vs real time data (for example ARTEMIS).

But the proposed here mechanism compares in real time BGP updates to an
oracle database for AS-PATH content accuracy. So any data which is based on
AS-PATHs itself (to create the relations) I am afraid can not be used as
such baseline src to validate AS-PATHs correctness.

Thx a lot,
R.



On Thu, Mar 14, 2019 at 1:20 AM Brian Dickson 
wrote:

> CAIDA has lots of data sets, tools, etc.
>
> Here's one of the README files I grabbed, with some URLs that would help
> you find the specifics, and reference materials (papers) on what/why/how
> they are able to infer these relationships.
>
> Brian
>
> The 'serial-2' directory contains AS relationships that combine the
>>
>> 'serial-1' AS relationships (inferred using the method described in
>>
>> "AS Relationships, Customer Cones, and Validation" published in
>>
>> IMC 2013, http://www.caida.org/publications/papers/2013/asrank/),
>>
>> with AS relationships inferred from Ark traceroutes, and from
>>
>> multilateral peering
>>
>> (
>> http://www.caida.org/publications/papers/2013/inferring_multilateral_peering/
>> ).
>>
>>
>>
>> To do this we first infer which AS owns each router independent of the
>>
>> interface addresses observed at that router. The ownership inferences
>>
>> are based on IP-to-AS mapping derived from public BGP data, list of
>>
>> peering prefixes from PeeringDB, and the previously inferred business AS
>>
>> relationships. Then we convert the observed IP path into an AS path
>>
>> using the router ownership information (rather than mapping each
>>
>> observed IP to AS directly) and retain the first AS link in the
>>
>> resulting path for the AS graph.
>>
>>
>>
>> The as-rel files contain p2p and p2c relationships.  The format is:
>>
>> ||-1
>>
>> ||0|
>>
>>
>> 
>>
>> Acceptable Use Agreement
>>
>> 
>>
>>
>>
>> The AUA that you accepted when you were given access to these datas is
>> included
>>
>> in pdf format as a separate file in the same directory as this README
>> file.
>>
>> When referencing this data (as required by the AUA), please use:
>>
>>
>>
>> The CAIDA AS Relationships Dataset, 
>>
>> http://www.caida.org/data/active/as-relationships/
>>
>>
>>
>> Also, please, report your publication to CAIDA
>>
>> (http://www.caida.org/data/publications/report-publication.xml).
>>
>
> On Mon, Mar 11, 2019 at 4:48 PM Robert Raszuk  wrote:
>
>> Dear authors of draft-chen-grow-enhanced-as-loop-detection,
>>
>> The draft says:
>>
>>   " At this point, AS 200 *can lookup the local resource database* and
>>check whether there is a real AS relationship between the local AS
>>and the left AS and the right AS"
>>
>> Can you please share a pointer to any database or accurate public oracle
>> where anyone could check if peering relation found in the AS-PATH is valid
>> or invalid ?
>>
>> Just over the last few months I connected my AS to number of Tier1 ISPs
>> in few of my experimental POPs, but never reported that peering
>> establishment to anyone. Then I have a question - how any (public) database
>> would accurately reflect any global BGP peering relation to be used
>> anywhere for filtering of BGP updates ?
>>
>> Kind regards,
>> RR.
>>
>> On Tue, Mar 12, 2019 at 12:27 AM  wrote:
>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>>
>>>
>>> Title   : Enhanced AS-Loop Detection for BGP
>>> Authors : Huanan Chen
>>>   Yunan Gu
>>>   Shunwan Zhuang
>>>   Haibo Wang
>>> Filename:
>>> draft-chen-grow-enhanced-as-loop-detection-00.txt
>>> Pages   : 9
>>> Date: 2019-03-11
>>>
>>> Abstract:
>>>This document proposes to enhance AS-Loop Detection for BGP Inbound/
>>>Outbound Route Processing.
>>>
>>>
>>>
>>> The

Re: [GROW] I-D Action: draft-chen-grow-enhanced-as-loop-detection-00.txt

[Robert Raszuk]

Ahh no - I should have said first hop ISP for eBGP connected end customers.

I was not talking about validating Comcast uplinks  - for those indeed
origin validation and when it ever get's seriously implemented BGP path
validation may be rigth solutions.

This draft to the best of my understanding proposes to check anywhere in
the EBGP transit if listed AS-PATH sequences of ASes are valid ie possible
based on real peering data.

Cool idea ! There is only one little problem I asked authors about ...
there is no such data to validate it against :)


On Wed, Mar 13, 2019 at 6:24 PM heasley  wrote:

> Wed, Mar 13, 2019 at 04:30:08PM +0100, Robert Raszuk:
> > In general of course.
> >
> > I was just describing the *local ISP customer's* inbound peering policy.
> > Sorry if that wasn't clear.
>
> by "local ISP", do you mean Comcast? :)  For a very small provider,
> existing policy language could be sufficient; we're all making due with
> what we have, but it really depends upon how pedantic they wish to be
> about A route's attributes and the volume.  the more pedantic they wish to
> be, the larger the policy; the config becomes large and their devices may
> not have resources to handle it.  That assumes that they have the
> information
> to be pedantic; see efforts of many to improve (speed, accuracy, etc) IRR
> data or utilize sidr data in other ways.
>
> More programability is needed, imo.  IOS XR has made improvements here with
> parameterized RPL, for eg.
>
> as for the draft itself, isnt the origin case handled by sidr?  and the
> transit case by proposed path validation?
>
> > Or do you see that even that has some limitations which may require extra
> > solutions ? If so pls elaborate on what those limitations are.
> >
> > Thx.
> > R.
> >
> >
> >
> > On Wed, Mar 13, 2019 at 4:26 PM heasley  wrote:
> >
> > > Wed, Mar 13, 2019 at 02:30:14PM +0100, Robert Raszuk:
> > > > Each decently managed AS today has strong EBGP ingress policy
> permitting
> > > > only specific prefixes with specific AS-PATH which is applied in
> ingress
> > > to
> > > > ISP network. No more enhancement to this policy is required.
> > >
> > > I'm NOT speaking in support of this draft, I have not even read it.
> But,
> > > want to tell you that there are limitations to what filtering can be
> > > imposed inbound and not just when the peer is very large.  effective
> > > solutions should be welcomed.
> > >
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] I-D Action: draft-chen-grow-enhanced-as-loop-detection-00.txt

[Robert Raszuk]

In general of course.

I was just describing the *local ISP customer's* inbound peering policy.
Sorry if that wasn't clear.

Or do you see that even that has some limitations which may require extra
solutions ? If so pls elaborate on what those limitations are.

Thx.
R.



On Wed, Mar 13, 2019 at 4:26 PM heasley  wrote:

> Wed, Mar 13, 2019 at 02:30:14PM +0100, Robert Raszuk:
> > Each decently managed AS today has strong EBGP ingress policy permitting
> > only specific prefixes with specific AS-PATH which is applied in ingress
> to
> > ISP network. No more enhancement to this policy is required.
>
> I'm NOT speaking in support of this draft, I have not even read it.  But,
> want to tell you that there are limitations to what filtering can be
> imposed inbound and not just when the peer is very large.  effective
> solutions should be welcomed.
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] I-D Action: draft-chen-grow-enhanced-as-loop-detection-00.txt

[Robert Raszuk]

Policy filtering I described happens on inbound so impact for update
generation is null.

Thx,
R.



On Wed, Mar 13, 2019 at 3:28 PM Yu Tianpeng 
wrote:

> Hi authors,
> I am wondering what is the impact on update peer groups of use outbound
> processing?
> Thanks in advance
> Regards,
> Tim
>
> On Wed, 13 Mar 2019, 13:30 Robert Raszuk,  wrote:
>
>> Hi,
>>
>> > But what we refer here to those ASs that have a connection with the
>> local AS.
>>
>> Each decently managed AS today has strong EBGP ingress policy permitting
>> only specific prefixes with specific AS-PATH which is applied in ingress to
>> ISP network. No more enhancement to this policy is required.
>>
>> What you are proposing is actually much weaker model as compared to what
>> is in place already today by those which care. And those which do not care
>> would not apply this scheme anyway.
>>
>> Many thx,
>> R.
>>
>>
>>
>>
>>
>>
>> On Wed, Mar 13, 2019 at 11:13 AM Zhuangshunwan 
>> wrote:
>>
>>> Hi Robert,
>>>
>>>
>>>
>>> Thanks a lot for the comment!
>>>
>>>
>>>
>>> Please find reply inlines with [Shunwan].
>>>
>>>
>>>
>>> Best Regards,
>>>
>>> Shunwan
>>>
>>>
>>>
>>>
>>>
>>> *From:* GROW [mailto:grow-boun...@ietf.org] *On Behalf Of *Robert Raszuk
>>> *Sent:* Tuesday, March 12, 2019 7:48 AM
>>> *To:* grow@ietf.org
>>> *Subject:* Re: [GROW] I-D Action:
>>> draft-chen-grow-enhanced-as-loop-detection-00.txt
>>>
>>>
>>>
>>> Dear authors of draft-chen-grow-enhanced-as-loop-detection,
>>>
>>>
>>>
>>> The draft says:
>>>
>>>
>>>
>>>   " At this point, AS 200 *can lookup the local resource database* and
>>>
>>>check whether there is a real AS relationship between the local AS
>>>
>>>and the left AS and the right AS"
>>>
>>>
>>>
>>> Can you please share a pointer to any database or accurate public oracle
>>> where anyone could check if peering relation found in the AS-PATH is valid
>>> or invalid ?
>>>
>>> [Shunwan] Sorry, I can't.  But what we refer here to those ASs that have
>>> a connection with the local AS.
>>>
>>> From the perspective of the local AS, it can manage/hold the
>>> AS-relationship database between the local AS and each of those ASs (such
>>> as C2P, P2P, P2C, etc.).
>>>
>>>
>>>
>>> Just over the last few months I connected my AS to number of Tier1 ISPs
>>> in few of my experimental POPs, but never reported that peering
>>> establishment to anyone. Then I have a question - how any (public) database
>>> would accurately reflect any global BGP peering relation to be used
>>> anywhere for filtering of BGP updates ?
>>>
>>> [Shunwan] This is indeed a difficult problem to be solved, and we also
>>> want to know how to solve it.
>>>
>>> Thanks again!
>>>
>>>
>>>
>>> Kind regards,
>>>
>>> RR.
>>>
>>>
>>>
>>> On Tue, Mar 12, 2019 at 12:27 AM  wrote:
>>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>>
>>>
>>> Title   : Enhanced AS-Loop Detection for BGP
>>> Authors : Huanan Chen
>>>   Yunan Gu
>>>   Shunwan Zhuang
>>>   Haibo Wang
>>> Filename:
>>> draft-chen-grow-enhanced-as-loop-detection-00.txt
>>> Pages   : 9
>>> Date: 2019-03-11
>>>
>>> Abstract:
>>>This document proposes to enhance AS-Loop Detection for BGP Inbound/
>>>Outbound Route Processing.
>>>
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>>
>>> https://datatracker.ietf..org/doc/draft-chen-grow-enhanced-as-loop-detection/
>>> <https://datatracker.ietf.org/doc/draft-chen-grow-enhanced-as-loop-detection/>
>>>
>>> There are also htmlized versions available at:
>>> https://tools.ietf.org/html/draft-chen-grow-enhanced-as-loop-detection-00
>>>
>>> https://datatracker.ietf.org/doc/html/draft-chen-grow-enhanced-as-loop-detection-00
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of
>>> submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp..ietf.org/internet-drafts/
>>> <ftp://ftp.ietf.org/internet-drafts/>
>>>
>>> ___
>>> I-D-Announce mailing list
>>> i-d-annou...@ietf.org
>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>> Internet-Draft directories: http://www.ietf.org/shadow.html
>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>
>>> ___
>> 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] I-D Action: draft-chen-grow-enhanced-as-loop-detection-00.txt

[Robert Raszuk]

Hi,

> But what we refer here to those ASs that have a connection with the local
AS.

Each decently managed AS today has strong EBGP ingress policy permitting
only specific prefixes with specific AS-PATH which is applied in ingress to
ISP network. No more enhancement to this policy is required.

What you are proposing is actually much weaker model as compared to what is
in place already today by those which care. And those which do not care
would not apply this scheme anyway.

Many thx,
R.






On Wed, Mar 13, 2019 at 11:13 AM Zhuangshunwan 
wrote:

> Hi Robert,
>
>
>
> Thanks a lot for the comment!
>
>
>
> Please find reply inlines with [Shunwan].
>
>
>
> Best Regards,
>
> Shunwan
>
>
>
>
>
> *From:* GROW [mailto:grow-boun...@ietf.org] *On Behalf Of *Robert Raszuk
> *Sent:* Tuesday, March 12, 2019 7:48 AM
> *To:* grow@ietf.org
> *Subject:* Re: [GROW] I-D Action:
> draft-chen-grow-enhanced-as-loop-detection-00.txt
>
>
>
> Dear authors of draft-chen-grow-enhanced-as-loop-detection,
>
>
>
> The draft says:
>
>
>
>   " At this point, AS 200 *can lookup the local resource database* and
>
>check whether there is a real AS relationship between the local AS
>
>and the left AS and the right AS"
>
>
>
> Can you please share a pointer to any database or accurate public oracle
> where anyone could check if peering relation found in the AS-PATH is valid
> or invalid ?
>
> [Shunwan] Sorry, I can't.  But what we refer here to those ASs that have a
> connection with the local AS.
>
> From the perspective of the local AS, it can manage/hold the
> AS-relationship database between the local AS and each of those ASs (such
> as C2P, P2P, P2C, etc.).
>
>
>
> Just over the last few months I connected my AS to number of Tier1 ISPs in
> few of my experimental POPs, but never reported that peering establishment
> to anyone. Then I have a question - how any (public) database would
> accurately reflect any global BGP peering relation to be used anywhere for
> filtering of BGP updates ?
>
> [Shunwan] This is indeed a difficult problem to be solved, and we also
> want to know how to solve it.
>
> Thanks again!
>
>
>
> Kind regards,
>
> RR.
>
>
>
> On Tue, Mar 12, 2019 at 12:27 AM  wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> Title   : Enhanced AS-Loop Detection for BGP
> Authors : Huanan Chen
>   Yunan Gu
>   Shunwan Zhuang
>   Haibo Wang
> Filename: draft-chen-grow-enhanced-as-loop-detection-00.txt
> Pages   : 9
> Date: 2019-03-11
>
> Abstract:
>This document proposes to enhance AS-Loop Detection for BGP Inbound/
>Outbound Route Processing.
>
>
>
> The IETF datatracker status page for this draft is:
>
> https://datatracker.ietf..org/doc/draft-chen-grow-enhanced-as-loop-detection/
> <https://datatracker.ietf.org/doc/draft-chen-grow-enhanced-as-loop-detection/>
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-chen-grow-enhanced-as-loop-detection-00
>
> https://datatracker.ietf.org/doc/html/draft-chen-grow-enhanced-as-loop-detection-00
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] I-D Action: draft-chen-grow-enhanced-as-loop-detection-00.txt

[Robert Raszuk]

Dear authors of draft-chen-grow-enhanced-as-loop-detection,

The draft says:

  " At this point, AS 200 *can lookup the local resource database* and
   check whether there is a real AS relationship between the local AS
   and the left AS and the right AS"

Can you please share a pointer to any database or accurate public oracle
where anyone could check if peering relation found in the AS-PATH is valid
or invalid ?

Just over the last few months I connected my AS to number of Tier1 ISPs in
few of my experimental POPs, but never reported that peering establishment
to anyone. Then I have a question - how any (public) database would
accurately reflect any global BGP peering relation to be used anywhere for
filtering of BGP updates ?

Kind regards,
RR.

On Tue, Mar 12, 2019 at 12:27 AM  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> Title   : Enhanced AS-Loop Detection for BGP
> Authors : Huanan Chen
>   Yunan Gu
>   Shunwan Zhuang
>   Haibo Wang
> Filename: draft-chen-grow-enhanced-as-loop-detection-00.txt
> Pages   : 9
> Date: 2019-03-11
>
> Abstract:
>This document proposes to enhance AS-Loop Detection for BGP Inbound/
>Outbound Route Processing.
>
>
>
> The IETF datatracker status page for this draft is:
>
> https://datatracker.ietf.org/doc/draft-chen-grow-enhanced-as-loop-detection/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-chen-grow-enhanced-as-loop-detection-00
>
> https://datatracker.ietf.org/doc/html/draft-chen-grow-enhanced-as-loop-detection-00
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Review request for draft-szarecki-grow-abstract-nh-scaleout-peering-00

[Robert Raszuk]

Hi Ron,

Let's go via your points ...

*> Rapid deactivation of all routes that resolve through an ANH when the
ANH is withdrawn*

I was providing real config samples indicating that the above is possible
to be done today in shipping implementations. So I think while encouraging
community for using next hop indirection is not a bad thing in a form of
BCP calling it as "abstract next hop" vs "virtual next hop" or basically
"loopback next hop" is debatable.

In other words at min document should more focus on the concept of logical
next hop along with options available to invalidate it as opposed to
endorse any particular flavor of its implementation.

*> Reduction in churn when one or more (but not all) of the BGP sessions
that map to an ANH terminates*

I don't think this is really accomplished or guaranteed in general. BGP
advertises entire paths not just NLRIs and next hops and any changes in the
best path advertised will result in churn when such best path goes away.

Only in the case when all path attributes are identical such churn can be
avoided, but it will also avoided today with vanilla nhs on ASBR. I do not
see any extra magic ANH brings to this reduction of churn.

*> Reduction the number of routes advertised to the RR*

Not sure how this is reduced. By default with nhs you advertise best paths
only from any ASBR. Same with ANH. If you use add-paths you may advertise
more then best. So I do not see how ANH reduces RR control plane load nor I
see that such reduction is really so much necessary for control plane
reflector.

Bottom line is that other then the above the proposed document imposes new
terminology for well known best common practices of BGP deployments.

Many thx,
RR.





On Fri, Mar 8, 2019 at 10:59 PM Ron Bonica  wrote:

> Robert, Rafal,
>
>
>
> Can we summarize this thread by saying that abstract-nh has the following
>  goals (listed in order of importance) :
>
>
>
>1. Rapid deactivation of all routes that resolve through an ANH when
>the ANH is withdrawn
>2. Reduction in churn when one or more (but not all) of the BGP
>sessions that map to an ANH terminates
>3. Reduction the number of routes advertised to the RR
>
>
>
> These benefits are not without cost. Because fewer routes are advertised
> to the RR, some information is lost.
>
>
>
> Do I have this much right?
>
>
>
> If Rafal points out this issue in the draft, might network operators be
> able to make informed decisions regarding whether the costs outweigh the
> benefits in their network?
>
>
>
>   Ron
>
>
>
> *From:* GROW  *On Behalf Of * Robert Raszuk
> *Sent:* Monday, March 4, 2019 4:19 PM
> *To:* Rafal Jan Szarecki 
> *Cc:* grow@ietf.org; Natrajan Venkataraman 
> *Subject:* Re: [GROW] Review request for
> draft-szarecki-grow-abstract-nh-scaleout-peering-00
>
>
>
>
>
> [RJS] What if eBGP goes down while BFD stays up, for whatever reason? IMO
> tracking BGP session state is correct think to do.
>
>
>
> Not a problem :)  Add as many as you like additional tracking rules.
>
>
>
> Example:
>
>
>
> event syslog pattern “.*%BGP-5-ADJCHANGE:neighbor x.x.x.x DOWN”
>
>
>
> [RJS] It is matter of opinion. I see drawback of “READ_ONLY” – it delays
> propagation of (potentially) large data set à make entire BGP convergence
> slower. W/ technique described in draft I propagate large data set ASAP but
> prevent other speaker from use it, until ANH become active in IGP.
>
>
>
> The main point of READ_ONLY mode is to reduce control plane churn when
> paths learned first would not keep the "best path" status upon other peers
> coming up and bringing better paths on the given ASBR.
>
>
>
> Besides it matters only during the initial session bring-up.. As you have
> many peers giving you similar set of routes anyway it really does not
> affect your reachability at all.
>
>
>
> Thx,
>
> R.
>
>
>
>
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Review request for draft-szarecki-grow-abstract-nh-scaleout-peering-00

[Robert Raszuk]

> [RJS] What if eBGP goes down while BFD stays up, for whatever reason? IMO
> tracking BGP session state is correct think to do.
>

Not a problem :)  Add as many as you like additional tracking rules.

Example:

event syslog pattern “.*%BGP-5-ADJCHANGE:neighbor x.x.x.x DOWN”

[RJS] It is matter of opinion. I see drawback of “READ_ONLY” – it delays
> propagation of (potentially) large data set à make entire BGP convergence
> slower. W/ technique described in draft I propagate large data set ASAP but
> prevent other speaker from use it, until ANH become active in IGP.
>

The main point of READ_ONLY mode is to reduce control plane churn when
paths learned first would not keep the "best path" status upon other peers
coming up and bringing better paths on the given ASBR.

Besides it matters only during the initial session bring-up. As you have
many peers giving you similar set of routes anyway it really does not
affect your reachability at all.

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

Re: [GROW] Review request for draft-szarecki-grow-abstract-nh-scaleout-peering-00

[Robert Raszuk]

Hey Rafał,

*> To exercise this BGP NG may not be ASBR loopback as it stays in IGP as
long as ASBR is UP.*

Completely not true if you properly configure your ASBRs :).

Imagine next hop self is using loopback 100 and I redistribute it to IGP.

Further observe that interface in a shutdown state is not advertised into
IGP. So all what is needed is to run BFD session to peer which in turn will
remove the connected subnets from global RIB and therefor trigger a
shutdown of your loopback 100.

Very simple and effective :) And if your peer does not like BFD you can
monitor it's interfaces reachability with help of a lot of different
protocols from just your ASBR side. You can set different reaction timers
to UP vs DOWN events, you can configure thresholds if you have a lot of
peers etc ...

Simple example:

/* Tracking your peer’s subnets */

track 1 ip route [peer1_net_address] [peer1_subnet_mask] reachability
track 2 ip route [peer2_net_address] [peer2_subnet_mask] reachability
…

/* Triggering action only when both go down */

track 100 list boolean and
object 1
object 2

!
/* Action DOWN and removal from IGP */

event manager applet LO100-DOWN
event track 100 state down
action 1 cli command "conf t"
action 2 cli command "interface loopback100"
action 2 cli command "shut"
action 3 cli command "end"
action 4 syslog priority errors msg "eBGP peers unreachable; shutting down
lo100"
!
!
/* Action UP and advertising it in IGP */

event manager applet LO100-UP
event track 100 state up
action 1 cli command "conf t"
action 2 cli command "interface loopback100"
action 2 cli command "no shut"
action 3 cli command "end"
action 4 syslog priority errors msg "eBGP peers reachable; activating lo100"
!

*> In draft we track state and EoR of set of sessions. So if session is
ESTABLISHED but *
*> still in initial learning, ANH is not in IGP. This is to prevent:*

When BGP sessions come up and are still in learning mode BGP is (or well
should be) in "READ_ONLY" mode and should not advertise anything to any
peer till EoR is received or timeout happens. Perhaps this is
implementation thing, but I hope all good BGP implementations do support
BGP READ_ONLY mode.

Using lack of Abstract Next Hop to suppress advertised BGP paths somewhere
in the network is a pretty bad idea. Note that it also does not work if
your ANH is AS_WIDE and is common across more then one ASBR.

- -

Bottom line is that solution to all what you are describing has been
shipping commercially in some implementations for years without any 20 page
IETF draft. Moreover your document is really not even describing a BCP, but
how one vendor solved it - rather in a bit suboptimal way (EoR point) or
with much less control (BGP based ANH removal).

IMO it is perfect text to become such vendor’s white paper, but not really
a fit to be an IETF document regardless if it would be of Informational or
BCP character.

Cheers,
R.

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

Re: [GROW] Review request for draft-szarecki-grow-abstract-nh-scaleout-peering-00

[Robert Raszuk]

Hey Rafał,

Just do not set BGP NH to ANH in export policy.
>

In your Junos cfg example (slide 28) ANH is applied to EBGP peers so I am
not sure how I can send something different to any IBGP peer:

[edit protocols bgp group PeerAS2]
type external;
egress-te {
install-address 1.1.1.2;
rib {
inet.0;
}
}
peer-as 2;
neighbor 11.1.1.1;
neighbor 11.1.1.5;


[RJS] I agree. Memory footprint at RR is not an issue. Convergence at scale
> is.
>

Convergence is not a problem .. in fact no one should be counting on
protocol *convergence* for fast connectivity restoration at any event of
failure these days.


Let assume at site 1 I have 4 ASBRS connected to AS_2 each with 1 sessions,
> and this ASBR learns 300k prefixes form AS_2 and all of then are best from
> each ASBR POV. So 300k path per ASBR, 300k pfx per ASBR, 1 path per prefix
> per ASBR.
>
> The RR gets 4 x 300k pfx with BGP NH set to ASBR1-2-3-4 loopbacks. And
> send it w/ ADD-PAT to on-site CR
>
> When eBGP session of one of ASBR (say ASBR1) fails, it has to withdraw
> 300k path from RR, and RR need to withdraw 300k path form CR. Untill this
> is done CR will keep sending ¼ oftraffic to ASBR1, and BGP NH == loopback
> is reachable.
>
> Now if ANH is used, CR sees 4 path per prefix with BGP NH == ANH1-2-3-4
> respectively. When eBGP session of one of ASBR (say ASBR1) fails, it
> removes ANH1 form IGP and start to withdraw 300k path from RR, and RR need
> to withdraw 300k path form CR. As soon as CR sees IGP update (ANH1
> unreachable) it can mark all 300k path that have BGP NH == ANH1 unusable.
> And stop forwarding to ASBR1. If CR runs BGP PIC EDGE it could be
> sub-second.
>


All of this works fine today out of the box if you do not set next hop self
on your ASBRs (typical cfg in non MPLS networks :).
And if you do set nhp there as mentioned you can control when it is
redistributed into IGP (or removed from it) by tracking any object (or set
of objects) you define. Very simple.



>  The inter-site operation – advertising only one path w/ BGP NH
> representing “set of eBGP sessions from set of ASBRS” is just one more
> optimization. Let call this SP_ANH (Site-Peer ANH in contrast to above
> discussed ASBR-Peer ANH).
>
>
>- If RR advertise to other sites only one path and BGP NH is loopback
>of one of ASBRs (or ASBR-Peer ANH), then what is convergence in case of
>this ASBR failure?  RR has to send 300k path w/ new BGP NH. Until this is
>done, remote sites will send traffic somewhere elsw. Not best egress site.
>
> Advertise not one but two paths each coming from different ASBRs.


>
>-
>- If RR advertise to other sites only all 4  path and BGP NH is
>loopback of one of ASBRs (or ASBR-Peer ANH), then IGP update removing this
>address will allow for quick restoration (as other 3 path are available
>everywhere). But in multi-path scenario, we just sreated 2-3 level of ECMP
>structure on remote BGP speakers:
>prefixà (*list of 4* BGP NH) à each BGP NH à *list of IGP* ECMP
>neighbours. That costly to manage in S/W and in HW
>
>
If you advertise ANH per ASBR you will still have 4 different next hops so
exactly the case as above.

If you however proposing to advertise all paths from all ASBRs with the
same next hop (in your case AS-WIDE ANH) - brilliant - but how are you
assuring that all EBGP peers send you symmetric routes ? If you get some
EBGP sessions giving you partial BGP reachability for whatever reason - and
you are still using anycast ANH from all 4 ASBRs the packets which IGP
sends towards said ASBRs would be either dropped or looped between ASBRs
till TTL expires as next hop is still ANH so anycast.



>
>-
>- If RR advertise to other sites only one path and BGP NH is Site-Peer
>ANH as in this proposal, then Site-Peer ANH is not removed form IGP (as
>other ASBRs has session with Peer). Re,mote sites keep sending traffic
>using pre-failure data until BGP update from RR comes. End when it comes,
>it will have same BGP NH as pre-failure path. So there will be no need to
>update FIB. Also FIB structure will be simpler and less costly
>prefixà one  BGP NH à *list of *IGP ECMP neighbours.
>Some merchant chips have really limited ECMP capability…
>
> See above.

See when we worked on concept of virtual BGP paths we did a lot of analysis
of this and reached the conclusion that while possible the application of
given abstract or virtual next hop to consistent union of  prefixes
reachable over N EBGP sessions from single or multiple ASBRs must be
automated as you can not assure eBGP symmetry.

So even in your simplest case of ANH per ASBR per PeerAS there is zero
guarantee that you get identical paths from all peers. That means that
since you are going to keep the ANH in IGP till last session goes away you
are going to attract traffic to such ASBRs until BGP withdrawn all affected
non symmetrical paths. Trust me much faster would be not to set nh on ASBR
and just remove peer's