Subject: [Idr] [WARNING : A/V UNSCANNABLE] draft-lapukhov-bgp-opaque-signaling

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Sat, 12 Mar 2016 20:26:32 +0000

I read

http://www.ietf.org/id/draft-lapukhov-bgp-opaque-signaling-01.txt

Is this intended for any and multiple applications to use?
If so, how do independent applications guarantee no duplication in NLRI?
If not, what is the target application?

Thanks
Jakob.

---

From: Petr Lapukhov <[email-masked]>
Date: Sat, 12 Mar 2016 21:05:33 +0000

Hi Jakob,

There is an ongoing discussion around avoiding NLRI (key) collisions. For now, the plan is to externally generate unique key prefix per application, e.g. application name, or UUID or some other globally unique string. Ensuring the uniqueness of those prefixes is outside the scope of the proposal, though - it's more of a deployment consideration.

Regards,

Petr

________________________________
From: Idr [[email-masked]] on behalf of Jakob Heitz (jheitz) [[email-masked]]
Sent: Saturday, March 12, 2016 12:26 PM
To: [email-masked]
Subject: [Idr] [WARNING : A/V UNSCANNABLE] draft-lapukhov-bgp-opaque-signaling

I read

http://www.ietf.org/id/draft-lapukhov-bgp-opaque-signaling-01.txt<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ietf.org_id_draft-2Dlapukhov-2Dbgp-2Dopaque-2Dsignaling-2D01.txt&d=CwMFAg&c=5VD0RTtNlTh3ycd41b3MUw&r=LU_vJaM_EQu1Ssm35j2xlA&m=y8paWUSIMD4YG8hfWC8k0b55e7qWYVRgGAwsXJKLMD4&s=-jEO1Jw88BI6pWUJf9es7WC0Q8Sm0XfBIhYRrWQCBHg&e=>

Thanks
Jakob.

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Sat, 12 Mar 2016 21:11:32 +0000

Without this problem solved, the proposal is not useful.
Everybody using it must stick to the eventual solution to ensure interoperability.
Therefore, it should be inside the scope.

Actually, BGP already has a way to distinguish applicationd: AFI and SAFI.

Jakob.

From: Petr Lapukhov [mailto:[email-masked]]
Sent: Saturday, March 12, 2016 1:06 PM
To: Jakob Heitz (jheitz) <[email-masked]>; [email-masked]
Subject: RE: draft-lapukhov-bgp-opaque-signaling

Hi Jakob,

Regards,

Petr

I read

Thanks
Jakob.

---

From: Huaimo Chen <[email-masked]>
Date: Sat, 12 Mar 2016 22:05:40 +0000

I read draft-hares-idr-flowspec-combo-01.txt and support it. The work described in the draft is useful and well fit in BGP. Regarding to option 1 and option 2, in the current stage, I support working on both. In the long run, I think option 2 is better.

Best Regards,
Huaimo

> On 05 Mar 2016, at 23:48, Susan Hares <[email-masked]> wrote:
>
> The interim on 3/7/2016 will have a discussion of revisions to the BGP Flow specification (BGP-FS) to add more features.  There are two suggested options:
> 1)      A minimal features to existing BGP-FS (option 1)
> Add a few new match filters to the BGP-FS NLRI and few new actions to the BGP-FS actions (in Extended communities).  Actions would need to be done in a defined order. Each new actions would need to define conflicts with existing actions.
>
> Best use case:  DoS attack prevention
>
> 2)      Create a BGP-FS version 2 (option 2)
> Create a new BGP-FS NLRI (v2) with a field that indicates the ordering of the BGP NLRI.  Add new BGP-FS actions with an order field in the BGP Wide Communities.  Filters are done in the order defined in the filter.  Actions are done in the order defined in the actions.   Order numbers that tie are handled in a defined order.
>
> Best use case: SDN/NFV filter management
>
> A write-up on the issues and proposed solutions is contained in:
> draft-hares-idr-flowspec-combo-01.txt.  <https://datatracker.ietf.org/doc/draft-hares-idr-flowspec-combo/>   The WG can select both option 1 and option 2.  This is a WG work item call for input to the chairs on the scope of the WG item.  In you discussion of this topics, the chairs would appreciate if you would indicate if you would support IDR working on option 1, option 2 or both option 1 and 2.  This WG call items also includes a call for draft-hares-idr-flowspec-combo-01.txt as a write-up of the work-item options.  The WG may wish to split this draft into multiple drafts.
>
> The following drafts are being consider for either option:
> 1)      draft-eddy-idr-flowspec-packet-rate
> 2)      draft-hao-idr-flowspec-nv03
> 3)      draft-hao-idr-flowspec-label
> 4)      draft-liang-idr-bgp-flowspec-time
> 5)      draft-litowski-idr-flowspec-interfaceset
> 6)      draft-vandevelde-idr-flowspec-path-redirect
> 7)      draft-li-idr-flowspec-rpd-01.txt
> 8)      draft-wu-idr-flowspec-yang.cfg.
>
> If you wish to comment on any of these drafts, we will
>
> We will conclude the Call for WG opinions on 3/17/2016 so these authors can have a day to revise and submit their drafts before the draft deadline.
>
> Sue Hares and John Scudder
>
> PS:
> draft-li-idr-flowspec-rpd discusses limits on the distribution of the policy which has been recast in draft-hares-idr-flowspec-combo as a bgp-wide community of Container type 1 with an atom of BGP Flow Specification ordering. However,  this draft is included in the list to be able to update the mechanism from this draft into that context.
>
> The yang model for BGP Flow specification is also included in this work item as it will need to be modified based on the approaches.  The yang model is in draft-wu-idr-flowspec-yang-cfg.  In your comments, please indicate if you feel these drafts or other drafts.
>
> _______________________________________________
> Idr mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/idr

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Mon, 14 Mar 2016 04:37:45 +0000

I was thinking more of how a service provider would use this with different
customers that don't know about each other, like preventing ships in the night from
crashing into each other. However, it could work in private.

Without a route target, any data sent will go everywhere and be stored in every router.
You probably don't want that.
This new AFI should require a route target. That means an update message without an RT must be dropped.

BGP treats all updates the same.
Once the floodgates are open to generic data, you might want to invent a precedence attribute.

Thanks,
Jakob.

From: Idr [mailto:[email-masked]] On Behalf Of Jakob Heitz (jheitz)
Sent: Saturday, March 12, 2016 1:12 PM
To: Petr Lapukhov <[email-masked]>; [email-masked]
Subject: Re: [Idr] draft-lapukhov-bgp-opaque-signaling

Jakob.

Hi Jakob,

Regards,

Petr

I read

Thanks
Jakob.

---

From: Zhuangshunwan <[email-masked]>
Date: Mon, 14 Mar 2016 12:21:14 +0000

I also support working on both.

Regards,
Shunwan

发件人: Idr [mailto:[email-masked]] 代表 Huaimo Chen
发送时间: 2016年3月13日 6:06
收件人: [email-masked]
抄送: Susan Hares
主题: Re: [Idr] WG Work item call - Opinions on work items (3/5/2016 to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.txt

Best Regards,
Huaimo

> On 05 Mar 2016, at 23:48, Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:
>
> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 14 Mar 2016 10:06:52 -0400

> without an RT must be dropped.

​I do not think RTC is enough here.

The fact that you can filter messages by receiver (or have receiver push
those  filters to upstream peers) does not in any way assures that receiver
is authorized to receive such data which for generic distribution of any
content seems like a bit of a fundamental problem to me.

Besides to agree on inter-as RT schemas is an adventure on its own.

Thx,
r.​

> *From:* Idr [mailto:[email-masked]] *On Behalf Of *Jakob Heitz
> (jheitz)
> *Sent:* Saturday, March 12, 2016 1:12 PM
> *To:* Petr Lapukhov <[email-masked]>; [email-masked]
> *Subject:* Re: [Idr] draft-lapukhov-bgp-opaque-signaling
>
>
>
> *From:* Petr Lapukhov [mailto:[email-masked]]
> *Sent:* Saturday, March 12, 2016 1:06 PM
> *To:* Jakob Heitz (jheitz) <[email-masked]>; [email-masked]
> *Subject:* RE: draft-lapukhov-bgp-opaque-signaling
>
>
>
> Hi Jakob,
>
>
>
> There is an ongoing discussion around avoiding NLRI (key) collisions. For
> now, the plan is to externally generate unique key prefix per application,
> e.g. application name, or UUID or some other globally unique
> string. Ensuring the uniqueness of those prefixes is outside the scope of
> the proposal, though - it's more of a deployment consideration.
>
>
>
> Regards,
>
>
>
> Petr
>
>
> ------------------------------
>
> *From:* Idr [[email-masked]] on behalf of Jakob Heitz (jheitz) [
> [email-masked]]
> *Sent:* Saturday, March 12, 2016 12:26 PM
> *To:* [email-masked]
> *Subject:* [Idr] [WARNING : A/V UNSCANNABLE]
> draft-lapukhov-bgp-opaque-signaling
>
> I read
>
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ietf.org_id_draft-2Dlapukhov-2Dbgp-2Dopaque-2Dsignaling-2D01.txt&d=CwMFAg&c=5VD0RTtNlTh3ycd41b3MUw&r=LU_vJaM_EQu1Ssm35j2xlA&m=y8paWUSIMD4YG8hfWC8k0b55e7qWYVRgGAwsXJKLMD4&s=-jEO1Jw88BI6pWUJf9es7WC0Q8Sm0XfBIhYRrWQCBHg&e=>
>
>
>
> [email-masked]

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 14 Mar 2016 14:59:00 +0000

Support.

Linda Dunbar

发件人: Idr [mailto:[email-masked]] 代表 Huaimo Chen
发送时间: 2016年3月13日 6:06
收件人: [email-masked]<mailto:[email-masked]>
抄送: Susan Hares
主题: Re: [Idr] WG Work item call - Opinions on work items (3/5/2016 to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.txt

Best Regards,
Huaimo

---

From: Petr Lapukhov <[email-masked]>
Date: Tue, 15 Mar 2016 12:55:12 +0000

Jakob,

So I was hoping to make the minimal amount of requirements needed to get this working. Using new AFI/SAFI already creates some burden, though it's not that hard to enable in a datacenter, once code supports it (e.g. it could be deployed to just one pod).

A new transitive attribute with existing AFI (IPv4/IPv6) is another option, as Robert suggested, but I feel uneasy about mixing routing and non-routing data: even though this approach allows for transparent data tunneling over existing BGP clouds. Using new AFI/SAFI, on the other hand, allows for fixing the contiguous distribution topology only to devices that are willing to support it.

RTC or other extended communities are definitely a great option to constrain information flooding, but I decided to leave any filtering requirements up to the implementation - e.g. either automated RT filtering or ORF could be possibly used, depending on system capabilities. Simplest case, everything could be flooded everywhere, if the user wishes to.

Re: precedence. The proposal merge conflict resolution is to be done by using BGP best-path selection process. Therefore, to set precedences a user is required to manipulate the usual attributes (e.g. bumping local-preference). IGP cost, obviously, does not exist, but this haven't been a problem in the best for eBGP tie-breaking. AS_PATH still has topological meaning, exposing path to the data-source, which I find useful for debugging purposes.

Regards.

Petr

________________________________
From: Jakob Heitz (jheitz) [[email-masked]]
Sent: Sunday, March 13, 2016 9:37 PM
To: Petr Lapukhov; [email-masked]
Subject: RE: draft-lapukhov-bgp-opaque-signaling

Thanks,
Jakob.

Jakob.

Hi Jakob,

Regards,

Petr

I read

Thanks
Jakob.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 15 Mar 2016 10:04:02 -0400

Hi Petr,

> Simplest case, everything could be flooded everywhere, if the user wishes
to.

And if the user does not wish so how in your model sender may scope the
distribution ?

All tools (RTC, ORF etc) are rather receiver dependent.

Of course you may assume user is both sender and receiver and he can
control (or rather drop) unwanted data at the application layer, but is
this really the right design model for opaque (to routing) information
distribution architecture ?

Many thx,
R.

On Tue, Mar 15, 2016 at 8:55 AM, Petr Lapukhov <[email-masked]> wrote:

> Jakob,
>
> So I was hoping to make the minimal amount of requirements needed to get
> this working. Using new AFI/SAFI already creates some burden, though it's
> not that hard to enable in a datacenter, once code supports it (e.g. it
> could be deployed to just one pod).
>
> A new transitive attribute with existing AFI (IPv4/IPv6) is another
> option, as Robert suggested, but I feel uneasy about mixing routing and
> non-routing data: even though this approach allows for transparent data
> tunneling over existing BGP clouds. Using new AFI/SAFI, on the other hand,
> allows for fixing the contiguous distribution topology only to devices that
> are willing to support it.
>
> RTC or other extended communities are definitely a great option to
> constrain information flooding, but I decided to leave any filtering
> requirements up to the implementation - e.g. either automated RT filtering
> or ORF could be possibly used, depending on system capabilities. Simplest
> case, everything could be flooded everywhere, if the user wishes to.
>
> Re: precedence. The proposal merge conflict resolution is to be done by
> using BGP best-path selection process. Therefore, to set precedences a user
> is required to manipulate the usual attributes (e.g. bumping
> local-preference). IGP cost, obviously, does not exist, but this haven't
> been a problem in the best for eBGP tie-breaking. AS_PATH still has
> topological meaning, exposing path to the data-source, which I find useful
> for debugging purposes.
>
> Regards.
>
> Petr
>
> *From:* Jakob Heitz (jheitz) [[email-masked]]
> *Sent:* Sunday, March 13, 2016 9:37 PM
> *To:* Petr Lapukhov; [email-masked]