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

[Petr Lapukhov <[e-mail]>]

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) [[e-mail]]
Sent: Sunday, March 13, 2016 9:37 PM
To: Petr Lapukhov; [e-mail]
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:[e-mail]] On Behalf Of Jakob Heitz (jheitz)
Sent: Saturday, March 12, 2016 1:12 PM
To: Petr Lapukhov <[e-mail]>; [e-mail]
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:[e-mail]]
Sent: Saturday, March 12, 2016 1:06 PM
To: Jakob Heitz (jheitz) <[e-mail]>; [e-mail]
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 [[e-mail]] on behalf of Jakob Heitz (jheitz) [[e-mail]]
Sent: Saturday, March 12, 2016 12:26 PM
To: [e-mail]
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.