Re: [GROW] WG Adoption call for: draft-snijders-grow-large-communities-usage - Dec 6 2016

[Randy Bush]

seems reasonable

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

Re: [GROW] WG Adoption call for: draft-snijders-grow-large-communities-usage - Dec 6 2016

[Zhuangshunwan]

Support.

- Shunwan
发件人：Christopher Morrow
收件人：grow-cha...@ietf.org,grow@ietf.org grow@ietf.org,
时间：2016-11-16 12:03:21
主题:[GROW] WG Adoption call for: draft-snijders-grow-large-communities-usage - 
Dec 6 2016

Howdy gentle folk,
Let's take a few minutes to discuss and digest whether or not the subject draft 
with abstract:
  Examples and inspiration for operators on how to use Large BGP
   Communities.

should be adopted as a WG draft in GROW. This call ends 12/6/2016 or December 
6, 2016.

thanks!
-chris
co-chair
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] WG Adoption call for: draft-snijders-grow-large-communities-usage - Dec 6 2016

[Sriram, Kotikalapudi (Fed)]

+1 support

Sriram


From: GROW  on behalf of Jeffrey Haas 
Sent: Wednesday, November 16, 2016 12:14 AM
To: grow@ietf.org
Subject: Re: [GROW] WG Adoption call for: 
draft-snijders-grow-large-communities-usage - Dec 6 2016

On Tue, Nov 15, 2016 at 07:03:02PM -0800, Christopher Morrow wrote:
> Howdy gentle folk,
> Let's take a few minutes to discuss and digest whether or not the subject
> draft with abstract:
>   Examples and inspiration for operators on how to use Large BGP
>Communities.
>
> should be adopted as a WG draft in GROW. This call ends 12/6/2016 or
> December 6, 2016.

I support adoption.

-- 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] WG Adoption call for: draft-snijders-grow-large-communities-usage - Dec 6 2016

[Jeffrey Haas]

On Tue, Nov 15, 2016 at 07:03:02PM -0800, Christopher Morrow wrote:
> Howdy gentle folk,
> Let's take a few minutes to discuss and digest whether or not the subject
> draft with abstract:
>   Examples and inspiration for operators on how to use Large BGP
>Communities.
> 
> should be adopted as a WG draft in GROW. This call ends 12/6/2016 or
> December 6, 2016.

I support adoption.

-- Jeff

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

Re: [GROW] WG Adoption call for: draft-snijders-grow-large-communities-usage - Dec 6 2016

[Jared Mauch]

I support adoption of this document.

> On Nov 15, 2016, at 10:03 PM, Christopher Morrow 
>  wrote:
> 
> Howdy gentle folk,
> Let's take a few minutes to discuss and digest whether or not the subject 
> draft with abstract:
>   Examples and inspiration for operators on how to use Large BGP
>Communities.
> 
> should be adopted as a WG draft in GROW. This call ends 12/6/2016 or December 
> 6, 2016.
> 
> thanks!
> -chris
> co-chair
> ___
> 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] WG Adoption call for: draft-snijders-grow-large-communities-usage - Dec 6 2016

[Christopher Morrow]

Howdy gentle folk,
Let's take a few minutes to discuss and digest whether or not the subject
draft with abstract:
  Examples and inspiration for operators on how to use Large BGP
   Communities.

should be adopted as a WG draft in GROW. This call ends 12/6/2016 or
December 6, 2016.

thanks!
-chris
co-chair
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] I-D Action: draft-ietf-grow-bgp-reject-02.txt

[Jon Mitchell]

On 31/10/16 02:24 -0700, internet-dra...@ietf.org wrote:
> Title   : Default IPv4 and IPv6 Unicast EBGP Route 
> Propagation Behavior Without Policies

To hopefully increase the speed to allow operators to ask for this
behavior from their vendors, starting the thread on one of the points
still open from the presentation today:

1.  Current draft - IPv4/IPv6 unicast AFI/SAFI EBGP only
2.  All AFI/SAFI - EBGP only
3.  All AFI/SAFI - IBGP/EBGP

I think #1 makes sense as it's limited to global Internet table
protection.  I also think it would be useful to protect our internal
networks from errors with #3.  However since internal networks often use
eBGP (see large-scale DC, seamless MPLS, inter-as Option-C), I think it
would be a bit odd to cover all AFI/SAFI for EBGP only as it now covers
some internal network applications as well (widening the requirements of
what the draft is trying to achieve) w/o fulfilling protecting them
fully by covering IBGP.

-Jon

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

Re: [GROW] ietf 97 agenda

[Jeffrey Haas]

Thomas,

On Tue, Nov 15, 2016 at 07:52:59AM +, Exa wrote:
> Thank you very much for this document which present ever eloquently one of 
> the issues with the current development process.
> 
> It is however not how I would propose to move forward. As a individual 
> developer, I do not have an IANA code and I am not sure I could get one.

As mentioned elsewhere in thread, PENs are easy to get hence suggesting that
managed code pode.  I tried to make sure that was clear in the [IANA-PEN]
link, but perhaps there's text I could add to make it more explicit?

> Also it changes the way features are coded and would require re-coding once 
> the format is stable and or the code is defined and not simply a code change 
> which is for me unwise and an overkill.

I have admittedly not taken a look at your implementation.  My expectation
for the bulk of BGP implementations based on my past experience is that the
code associated with parsing or encoding a given path attribute is mostly
separate on a per attribute basis.  There's obviously some shared
infrastructure to code the flags/code point/length of the standard path
attribute.

Since the inner container shouldn't need to move, it's mostly a matter of
abstracting out the contents (the feature data, in the draft) and permitting
them to be parsed or encoded in more than one code point.

Perhaps working through an example may be appropriate.

> I would rather see a much simpler solution: allocate some code point for 
> development and make them iBGP transitive only, (and give operators an option 
> to bypass this limit on selected eBGP links if they so wish...)

And how would you propose to deal with code point allocation for this?  For
example, we already have 255 available.

-- Jeff

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

Re: [GROW] Fw: New Version Notification for draft-sriram-opsec-urpf-improvements-00.txt

[Sriram, Kotikalapudi (Fed)]

Seems like you have the same question as Job:
Please see my response to him:
https://www.ietf.org/mail-archive/web/grow/current/msg03713.html

Sriram


From: Marco Marzetti 
Sent: Tuesday, November 15, 2016 7:17 AM
To: Sriram, Kotikalapudi (Fed)
Cc: Montgomery, Douglas (Fed); Nick Hilliard; grow@ietf.org
Subject: Re: [GROW] Fw: New Version Notification for 
draft-sriram-opsec-urpf-improvements-00.txt

Siriam,

I misunderstood. My apologize.
Now i get what you're suggesting.

How do you handle scenarios in which one ASn have two upstreams and
announces its prefixes to only one of them, but send packets through
both?

For instance what if AS1 sends announces its prefixes to AS2 only, but
sends packets to AS3?

+-+
| AS3 +---+
+--+--+   |
   |  |
+--+--++--+--+
| AS1 || AS4 |
+-++--+--+
   |  |
+--+--+   |
| AS2 +---+
+-+

Regards

On Tue, Nov 15, 2016 at 4:31 AM, Sriram, Kotikalapudi (Fed)
 wrote:
> Marco,
>
> My responses Marked with [Sriram] below:
>
> [Marco] But it also goes further and suggest to amend the usual behavior by
> advertising via BGP the source addresses of the traffic you want to
> drop so that the routers can null route and trigger uRPF.
> This is where i see problems.
>
> [Sriram] This is not at all what our proposed enhanced feasible path uRPF 
> does.
> To clarify, the proposal does not require/recommend making any BGP 
> advertisements.
> A good description of the proposal was just mentioned in a response to Nick,
> which is copied here:
>  The ISP's AS creates a union of all announced prefixes that have a common 
> origin AS.
>  Those announcements have potentially been received
>  on various customer/ peer/ provider interfaces.
>  Take that union of prefixes and include it in Reverse Path Filter (RPF) 
> tables
>  on all interfaces on which one or more of the prefixes in the union were 
> announced.
>
> [Sriram] We are adding prefixes in the RPF table (with some more additional
> intelligence built-in as compared to the current feasible-path uRPF),
> and source addresses belonging in these are prefixes are permitted (not null 
> routed).
>
> Sriram



--
Marco

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

Re: [GROW] Fw: New Version Notification for draft-sriram-opsec-urpf-improvements-00.txt

[Brian Dickson]

Suppose, in the same 4-AS scenario, the following policies:

AS1 receives AS4 prefixes via AS3 only.
AS1 sends a full table to AS3, and a partial table to AS2.
AS2 has a default route pointing to AS1.
AS2 sends its own prefixes to AS4, plus the partial table it receives from
AS1, to AS4.
AS2 DOES NOT HAVE A ROUTE TO AS4
AS2 uses default to reach AS4, via AS3.

AS4 sends traffic to the partial table, via AS2, to AS1.

This is legitimate traffic.

I do not believe FP uRPF, enhanced FP uRPF, or even the further generalized
FP uRPF would handle this.

This is also far from rare, even if it doesn't reach the level of "common
occurrence".

(In particular, it is something that happens A LOT wherever satellite links
are used, where symmetric traffic over the satellite path is actually the
worst possible scenario.)

Brian

On Tue, Nov 15, 2016 at 1:13 AM, Sriram, Kotikalapudi (Fed) <
kotikalapudi.sri...@nist.gov> wrote:

> I understand the scenario.
> That scenario is a problem for strict or feasible path uRPF, as well as
> the enhanced FP uRPF.
> If you add one further generalization to enhanced FP uRPF,
> namely, allow any prefix learned on any customer peering
> to be included in the RPF tables for *all* customer interfaces,
> then the enhanced FP uRPF still works for this scenario.
>
> Sriram
>
>
> 
> From: Job Snijders 
> Sent: Tuesday, November 15, 2016 3:26 AM
> To: Sriram, Kotikalapudi (Fed)
> Cc: Gert Doering; grow@ietf.org
> Subject: Re: [GROW] Fw: New Version Notification for
> draft-sriram-opsec-urpf-improvements-00.txt
>
> On Tue, Nov 15, 2016 at 05:38:57AM +, Sriram, Kotikalapudi (Fed) wrote:
> > > Does this technique make routers self-aware? What exactly is meant
> > > with the word 'intelligence' in this context?
> >
> > 'Logic' may be a better choice than 'intelligence' in this context?
> > For a brief description of the algorithm, please see:
> > https://www.ietf.org/mail-archive/web/grow/current/msg03699.html
>
> Thank you for the clarification.
>
> I have a second scenario that might be a challenge for Enhanced
> Feasible-Path uRPF.
>
> ASCII ART:
>
> +---+
>   +-+AS1+--+
>   | +---+  |
>   ||
>   ||
> +-+-++-+-+
> |AS2||AS3|
> +---+-+  +--++
>   | |
>   | |
> +-+-+   |
> |AS4+---+
> +---+
>
> AS4 is a customer of AS2 and AS3. AS4 ingests a full routing table from
> both AS2 and AS3 (and as such as two paths to AS4).
>
> A common traffic engineering practise visible in the Default-Free Zone
> is to block unbounded propagation of one's prefixes. For instance, AS4
> might use a BGP Community provided by AS2 to block propagation of the
> AS4 prefixes to AS1 via AS2. The equivalent would be that AS4 attaches
> NO_EXPORT on the announcements to AS2, but not on the announcement to
> AS3.
>
> AS1 will receive traffic sourced by the prefixes from AS4 via both
> AS2_AS4 and AS3_AS4.
>
> 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] Fw: New Version Notification for draft-sriram-opsec-urpf-improvements-00.txt

[Marco Marzetti]

Siriam,

I misunderstood. My apologize.
Now i get what you're suggesting.

How do you handle scenarios in which one ASn have two upstreams and
announces its prefixes to only one of them, but send packets through
both?

For instance what if AS1 sends announces its prefixes to AS2 only, but
sends packets to AS3?

+-+
| AS3 +---+
+--+--+   |
   |  |
+--+--++--+--+
| AS1 || AS4 |
+-++--+--+
   |  |
+--+--+   |
| AS2 +---+
+-+

Regards

On Tue, Nov 15, 2016 at 4:31 AM, Sriram, Kotikalapudi (Fed)
 wrote:
> Marco,
>
> My responses Marked with [Sriram] below:
>
> [Marco] But it also goes further and suggest to amend the usual behavior by
> advertising via BGP the source addresses of the traffic you want to
> drop so that the routers can null route and trigger uRPF.
> This is where i see problems.
>
> [Sriram] This is not at all what our proposed enhanced feasible path uRPF 
> does.
> To clarify, the proposal does not require/recommend making any BGP 
> advertisements.
> A good description of the proposal was just mentioned in a response to Nick,
> which is copied here:
>  The ISP's AS creates a union of all announced prefixes that have a common 
> origin AS.
>  Those announcements have potentially been received
>  on various customer/ peer/ provider interfaces.
>  Take that union of prefixes and include it in Reverse Path Filter (RPF) 
> tables
>  on all interfaces on which one or more of the prefixes in the union were 
> announced.
>
> [Sriram] We are adding prefixes in the RPF table (with some more additional
> intelligence built-in as compared to the current feasible-path uRPF),
> and source addresses belonging in these are prefixes are permitted (not null 
> routed).
>
> Sriram



-- 
Marco

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

Re: [GROW] Fw: New Version Notification for draft-sriram-opsec-urpf-improvements-00.txt

[Sriram, Kotikalapudi (Fed)]

I understand the scenario.
That scenario is a problem for strict or feasible path uRPF, as well as the 
enhanced FP uRPF.
If you add one further generalization to enhanced FP uRPF,
namely, allow any prefix learned on any customer peering
to be included in the RPF tables for *all* customer interfaces, 
then the enhanced FP uRPF still works for this scenario.

Sriram 



From: Job Snijders 
Sent: Tuesday, November 15, 2016 3:26 AM
To: Sriram, Kotikalapudi (Fed)
Cc: Gert Doering; grow@ietf.org
Subject: Re: [GROW] Fw: New Version Notification for 
draft-sriram-opsec-urpf-improvements-00.txt

On Tue, Nov 15, 2016 at 05:38:57AM +, Sriram, Kotikalapudi (Fed) wrote:
> > Does this technique make routers self-aware? What exactly is meant
> > with the word 'intelligence' in this context?
>
> 'Logic' may be a better choice than 'intelligence' in this context?
> For a brief description of the algorithm, please see:
> https://www.ietf.org/mail-archive/web/grow/current/msg03699.html

Thank you for the clarification.

I have a second scenario that might be a challenge for Enhanced
Feasible-Path uRPF.

ASCII ART:

+---+
  +-+AS1+--+
  | +---+  |
  ||
  ||
+-+-++-+-+
|AS2||AS3|
+---+-+  +--++
  | |
  | |
+-+-+   |
|AS4+---+
+---+

AS4 is a customer of AS2 and AS3. AS4 ingests a full routing table from
both AS2 and AS3 (and as such as two paths to AS4).

A common traffic engineering practise visible in the Default-Free Zone
is to block unbounded propagation of one's prefixes. For instance, AS4
might use a BGP Community provided by AS2 to block propagation of the
AS4 prefixes to AS1 via AS2. The equivalent would be that AS4 attaches
NO_EXPORT on the announcements to AS2, but not on the announcement to
AS3.

AS1 will receive traffic sourced by the prefixes from AS4 via both
AS2_AS4 and AS3_AS4.

Kind regards,

Job

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

Re: [GROW] Fw: New Version Notification for draft-sriram-opsec-urpf-improvements-00.txt

[Job Snijders]

On Tue, Nov 15, 2016 at 05:38:57AM +, Sriram, Kotikalapudi (Fed) wrote:
> > Does this technique make routers self-aware? What exactly is meant
> > with the word 'intelligence' in this context?
> 
> 'Logic' may be a better choice than 'intelligence' in this context?
> For a brief description of the algorithm, please see:
> https://www.ietf.org/mail-archive/web/grow/current/msg03699.html 

Thank you for the clarification.

I have a second scenario that might be a challenge for Enhanced
Feasible-Path uRPF.

ASCII ART:

+---+
  +-+AS1+--+
  | +---+  |
  ||
  ||
+-+-++-+-+
|AS2||AS3|
+---+-+  +--++
  | |
  | |
+-+-+   |
|AS4+---+
+---+

AS4 is a customer of AS2 and AS3. AS4 ingests a full routing table from
both AS2 and AS3 (and as such as two paths to AS4).

A common traffic engineering practise visible in the Default-Free Zone
is to block unbounded propagation of one's prefixes. For instance, AS4
might use a BGP Community provided by AS2 to block propagation of the
AS4 prefixes to AS1 via AS2. The equivalent would be that AS4 attaches
NO_EXPORT on the announcements to AS2, but not on the announcement to
AS3.

AS1 will receive traffic sourced by the prefixes from AS4 via both
AS2_AS4 and AS3_AS4.

Kind regards,

Job

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

Re: [GROW] ietf 97 agenda

[John Heasley]

Am 14.11.2016 um 23:52 schrieb Exa :
> 
> Hello Jeff,
> 
> Thank you very much for this document which present ever eloquently one of 
> the issues with the current development process.
> 
> It is however not how I would propose to move forward. As a individual 
> developer, I do not have an IANA code and I am not sure I could get one.

Have you tried?
 
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] ietf 97 agenda

[Job Snijders]

Hi Thomas,

On Tue, Nov 15, 2016 at 07:52:59AM +, Exa wrote:
> Thank you very much for this document which present ever eloquently
> one of the issues with the current development process.
> 
> It is however not how I would propose to move forward. As a individual
> developer, I do not have an IANA code and I am not sure I could get
> one.

It's very simple, just fill in this form: 
http://pen.iana.org/pen/PenApplication.page
and as "Organization Name: " you can fill in your personal name. I don't
recall whether the PEN number is issued immediately or whether it takes
a few hours.

I have one, on 
https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers
search for 'Job Snijders'

Kind regards,

Job

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