Re: [GROW] New Version Notification for draft-hilliard-grow-no-export-via-rs-00.txt

[Job Snijders]

Hi nick,

Have you considered just updating RFC 7947 to resolve the described
ambiguity by stating that a route server SHOULD pass the NO_EXPORT
community unaltered, rather than interpret it or block it?

The advance of this approach would be that a portion of deployed route
servers are already compliant, as where using a new NO_EXPORT_VIA_RS
community would require every route server to be updated.

>From the route server client perspective it may also be simpler if there is
just one “no export function” community instead of multiple.

Why is there no consensus amongst route server operators on what the
correct behavior is? Can you provide a citation?

Kind regards,

Job

On Mon, 9 Oct 2017 at 16:02, Nick Hilliard  wrote:

> New ID submission, as below.  This is to solve a real world problem.
>
> Comments welcome.
>
> Nick
>
> internet-dra...@ietf.org wrote:
> > A new version of I-D, draft-hilliard-grow-no-export-via-rs-00.txt
> > has been successfully submitted by Nick Hilliard and posted to the
> > IETF repository.
> >
> > Name: draft-hilliard-grow-no-export-via-rs
> > Revision: 00
> > Title:The BGP NO_EXPORT_VIA_RS Community for Route
> Servers
> > Document date:2017-10-08
> > Group:Individual Submission
> > Pages:5
> > URL:
> https://www.ietf.org/internet-drafts/draft-hilliard-grow-no-export-via-rs-00.txt
> > Status:
> https://datatracker.ietf.org/doc/draft-hilliard-grow-no-export-via-rs/
> > Htmlized:
> https://tools.ietf.org/html/draft-hilliard-grow-no-export-via-rs-00
> > Htmlized:
> https://datatracker.ietf.org/doc/html/draft-hilliard-grow-no-export-via-rs-00
> >
> >
> > Abstract:
> >This document describes a BGP Well-known Community called
> >NO_EXPORT_VIA_RS.  This community allows BGP route server clients to
> >instruct an Internet Exchange BGP Route Server to tag prefixes
> >destined for other route server clients with the NO_EXPORT Well-Known
> >Community.  This mechanism allows route server clients to
> >transitively control distribution of their prefixes in other
> >Autonomous Systems connected to the Internet Exchange Route Server.
> >
> >
> >
> >
> >
> > 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.
> >
> > The IETF Secretariat
> >
>
> ___
> 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] Genart last call review of draft-ietf-grow-bgp-gshut-11

[Matthew Miller]

Reviewer: Matthew Miller
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-grow-bgp-gshut-11
Reviewer: Matthew A. Miller
Review Date: 2017-10-09
IETF LC End Date: 2017-10-11
IESG Telechat date: N/A

Summary:

This document is ready to be published as an Informational document, but
there is one issue that I think clarification would help.

Major issues:

NONE

Minor issues:

In Section 4. "EBGP graceful shutdown procedure", it states that 0 can
used in all cases except where the AS already has a special meaning for
0. It seems to me more ought to be said, but I admit I'm not well-versed
on (I) BGP and might be seeing dragons where only windmills are present.


Nits/editorial comments:

* I suggest using RFC 8174 and its terminology boiler plate to help
  disambiguate "may" versus "MAY".

* A number of acronyms are used throughout without being spelled out (e.g.,
  RR, IBGP, FIB, EBGP, AS), but some (e.g., ASBR) are spelled out.  I would
  find it helpful to be consistent here, preferably by spelling them out on
  first use.

* In Section 1. "Introduction", second paragraph, the word "operation"
  seems to be missing from the first sentence:

  """
  This document discusses operational procedures to be applied in order
  to reduce or eliminate loss of packets during a maintenance.
  """

* Throughout the Appendices, there are some inconsistent uses of some terms,
  especially when compared to the rest of the document:

  - "Local-Pref" versus "LOCAL_PREF"
  - "nexhop" versus "NEXT_HOP"

* In Appendix A. "Alternative techniques with limited applicability", the
  phrase "describe them" ought to be "describes them".


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

Re: [GROW] New Version Notification for draft-hilliard-grow-no-export-via-rs-00.txt

[Christopher Morrow]

Do you all want to chat about this in singapore? or just keep discussing
on-list?
do you seek WG Adoption of the draft 'now' or would you like to chat about
it a bit more first?

On Mon, Oct 9, 2017 at 5:52 PM, Nick Hilliard  wrote:

> Wolfgang Tremmel wrote:
> > just reading your draft, a few remarks, speaking as a private internet
> citizen:
> >
> > "If a route server client announces a prefix tagged with both the
> >   NO_EXPORT and NO_EXPORT_VIA_RS communities to a route server, the
> >   route server MUST ignore the NO_EXPORT community,"
> >
> > --> that means that NO_EXPORT_VIA_RS is "stronger" then NO_EXPORT and
> > actually changes the meaning of NO_EXPORT.
> >
> > I know that users make stupid mistakes and this should perhaps cover
> > the mistake of setting both, but IMHO with NO_EXPORT being much older
> > and really well understood and used, I think NO_EXPORT should take
> > precedence.
> >
> > (IMHO NO_EXPORT should be interpreted, and never passed through,
> > independent of a router or a route server is used)
>
> According to rfc7947, it is a matter of local policy whether NO_EXPORT
> is interpreted or passed through.  This has always been the case in the
> IXP world: some IXP route servers interpret NO_EXPORT and some pass it
> through. So it's not correct to say that the behaviour of NO_EXPORT is
> well-understood when it comes to route servers - this topic has been the
> subject of a good deal of debate in the IXP community over the years,
> with no resolution.
>
> The approach we're taking with NO_EXPORT_VIA_RS is to effectively say:
> "we recommend not using NO_EXPORT because you don't know what it's going
> to do.  However, if you choose to use it in combination with
> NO_EXPORT_VIA_RS, it's clear what your intention is, and the lack of
> ambiguity with NO_EXPORT_VIA_RS when announced to a RS means that it
> should override NO_EXPORT, in this and only this situation".
>
> > My first idea when reading this was why not make it general, why
> > limit the community to route servers and not have a "SET_NO_EXPORT"
> > community which directs the next hop AS to set NO_EXPORT?
>
> > ( I already sent this email to Nick and his answer that its limited
> > to RS because otherwise some kind of TTL needs to be implemented
> > makes sense)
>
> Limiting the community to route servers is necessary because otherwise
> you'd need to implement a bgp-path TTL in order to limit the radius of
> interpretation.  I don't think you could safely use the as-path for
> determining how far the prefix should propagate.  Also there would be
> other problems with prefix distribution which would be hard to solve,
> e.g. what would happen in situations where an ASN's routing kit wasn't
> updated to interpret this correctly?  The prefix would be propagated
> across asn boundaries according to standard policy, but the NO_EXPORT
> interpretation might hit a couple of ASNs away, in an unexpected place.
>  I don't see how it would be possible to stop this from happening.
>
> At least if there is a requirement that this is only interpreted on
> route servers and then religiously deleted on export, the scope for
> creating problems is a good deal smaller.
>
> 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] New Version Notification for draft-hilliard-grow-no-export-via-rs-00.txt

[Nick Hilliard]

Wolfgang Tremmel wrote:
> just reading your draft, a few remarks, speaking as a private internet 
> citizen:
> 
> "If a route server client announces a prefix tagged with both the
>   NO_EXPORT and NO_EXPORT_VIA_RS communities to a route server, the
>   route server MUST ignore the NO_EXPORT community,"
> 
> --> that means that NO_EXPORT_VIA_RS is "stronger" then NO_EXPORT and
> actually changes the meaning of NO_EXPORT.
> 
> I know that users make stupid mistakes and this should perhaps cover
> the mistake of setting both, but IMHO with NO_EXPORT being much older
> and really well understood and used, I think NO_EXPORT should take
> precedence.
> 
> (IMHO NO_EXPORT should be interpreted, and never passed through,
> independent of a router or a route server is used)

According to rfc7947, it is a matter of local policy whether NO_EXPORT
is interpreted or passed through.  This has always been the case in the
IXP world: some IXP route servers interpret NO_EXPORT and some pass it
through. So it's not correct to say that the behaviour of NO_EXPORT is
well-understood when it comes to route servers - this topic has been the
subject of a good deal of debate in the IXP community over the years,
with no resolution.

The approach we're taking with NO_EXPORT_VIA_RS is to effectively say:
"we recommend not using NO_EXPORT because you don't know what it's going
to do.  However, if you choose to use it in combination with
NO_EXPORT_VIA_RS, it's clear what your intention is, and the lack of
ambiguity with NO_EXPORT_VIA_RS when announced to a RS means that it
should override NO_EXPORT, in this and only this situation".

> My first idea when reading this was why not make it general, why
> limit the community to route servers and not have a "SET_NO_EXPORT"
> community which directs the next hop AS to set NO_EXPORT?

> ( I already sent this email to Nick and his answer that its limited
> to RS because otherwise some kind of TTL needs to be implemented
> makes sense)

Limiting the community to route servers is necessary because otherwise
you'd need to implement a bgp-path TTL in order to limit the radius of
interpretation.  I don't think you could safely use the as-path for
determining how far the prefix should propagate.  Also there would be
other problems with prefix distribution which would be hard to solve,
e.g. what would happen in situations where an ASN's routing kit wasn't
updated to interpret this correctly?  The prefix would be propagated
across asn boundaries according to standard policy, but the NO_EXPORT
interpretation might hit a couple of ASNs away, in an unexpected place.
 I don't see how it would be possible to stop this from happening.

At least if there is a requirement that this is only interpreted on
route servers and then religiously deleted on export, the scope for
creating problems is a good deal smaller.

Nick

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

Re: [GROW] New Version Notification for draft-hilliard-grow-no-export-via-rs-00.txt

[Wolfgang Tremmel]

Hi,

just reading your draft, a few remarks, speaking as a private internet citizen:

"If a route server client announces a prefix tagged with both the
  NO_EXPORT and NO_EXPORT_VIA_RS communities to a route server, the
  route server MUST ignore the NO_EXPORT community,"

--> that means that NO_EXPORT_VIA_RS is "stronger" then NO_EXPORT and actually 
changes the meaning of NO_EXPORT.
I know that users make stupid mistakes and this should perhaps cover the 
mistake of setting both, but IMHO with NO_EXPORT being much older and really 
well understood and used, I think NO_EXPORT should take precedence.

(IMHO NO_EXPORT should be interpreted, and never passed through, independent of 
a router or a route server is used)

My first idea when reading this was why not make it general, why limit the 
community to route servers and not have a "SET_NO_EXPORT" community which 
directs the next hop AS to set NO_EXPORT?
( I already sent this email to Nick and his answer that its limited to RS 
because otherwise some kind of TTL needs to be implemented makes sense)

cheers,
Wolfgang


> On 9. Oct 2017, at 16:02, Nick Hilliard  wrote:
> 
> New ID submission, as below.  This is to solve a real world problem.
> 
> Comments welcome.
> 
> Nick
> 
> internet-dra...@ietf.org wrote:
>> A new version of I-D, draft-hilliard-grow-no-export-via-rs-00.txt
>> has been successfully submitted by Nick Hilliard and posted to the
>> IETF repository.
>> 
>> Name:draft-hilliard-grow-no-export-via-rs
-- 
Wolfgang Tremmel 

Phone +49 69 1730902 26 | Fax +49 69 4056 2716 | Mobile +49 171 8600 816 | 
wolfgang.trem...@de-cix.net
Geschaeftsfuehrer Harald A. Summa | Registergericht AG Köln HRB 51135
DE-CIX Management GmbH | Lindleystrasse 12 | 60314 Frankfurt am Main | Germany 
| www.de-cix.net


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

Re: [GROW] New Version Notification for draft-hilliard-grow-no-export-via-rs-00.txt

[Nick Hilliard]

New ID submission, as below.  This is to solve a real world problem.

Comments welcome.

Nick

internet-dra...@ietf.org wrote:
> A new version of I-D, draft-hilliard-grow-no-export-via-rs-00.txt
> has been successfully submitted by Nick Hilliard and posted to the
> IETF repository.
> 
> Name: draft-hilliard-grow-no-export-via-rs
> Revision: 00
> Title:The BGP NO_EXPORT_VIA_RS Community for Route Servers
> Document date:2017-10-08
> Group:Individual Submission
> Pages:5
> URL:
> https://www.ietf.org/internet-drafts/draft-hilliard-grow-no-export-via-rs-00.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-hilliard-grow-no-export-via-rs/
> Htmlized:   
> https://tools.ietf.org/html/draft-hilliard-grow-no-export-via-rs-00
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-hilliard-grow-no-export-via-rs-00
> 
> 
> Abstract:
>This document describes a BGP Well-known Community called
>NO_EXPORT_VIA_RS.  This community allows BGP route server clients to
>instruct an Internet Exchange BGP Route Server to tag prefixes
>destined for other route server clients with the NO_EXPORT Well-Known
>Community.  This mechanism allows route server clients to
>transitively control distribution of their prefixes in other
>Autonomous Systems connected to the Internet Exchange Route Server.
> 
> 
>   
> 
> 
> 
> 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.
> 
> The IETF Secretariat
> 

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