Re: [Idr] draft-lapukhov-bgp-opaque-signaling

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 <petr@fb.com> 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) [jheitz@cisco.com]
> *Sent:* Sunday, March 13, 2016 9:37 PM
> *To:* Petr Lapukhov; idr@ietf.org
> *Subject:* RE: draft-lapukhov-bgp-opaque-signaling
>
> 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:idr-bounces@ietf.org] *On Behalf Of *Jakob Heitz
> (jheitz)
> *Sent:* Saturday, March 12, 2016 1:12 PM
> *To:* Petr Lapukhov <petr@fb.com>; idr@ietf.org
> *Subject:* Re: [Idr] draft-lapukhov-bgp-opaque-signaling
>
>
>
> 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:petr@fb.com]
> *Sent:* Saturday, March 12, 2016 1:06 PM
> *To:* Jakob Heitz (jheitz) <jheitz@cisco.com>; idr@ietf.org
> *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 [idr-bounces@ietf.org] on behalf of Jakob Heitz (jheitz) [
> jheitz@cisco.com]
> *Sent:* Saturday, March 12, 2016 12:26 PM
> *To:* idr@ietf.org
> *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=>
>
>
>
> 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.
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
>