Subject: [Idr] Discussion on draft-white-bgpbgp-00

From: Robert Raszuk <[email-masked]>
Date: Mon, 7 Jul 2014 21:52:35 +0200

Hi,

Carrying opaque information in networks today is a good problem to address.

/* In fact to go there I guess we should really step back and define
what is today's _network_ as by many it is no longer bunch of routers
running proprietary code. */

Historically I have been attempting to at least make a very simple
session level separation by proposing Transport Instance BGP:
http://tools.ietf.org/html/draft-raszuk-ti-bgp-01

You are proposing a new BGP message to be used for carrying "opaque
information" within routing information !!! That is IMHO big/huge
mistake.

* First - behavior of any given AFI/SAFI is highly defined by it's
UPDATE message semantics. Carrying opaque stuff around which is
unrelated to routing is just not fitting there. /* It's like attaching
pretty heavy backpack to a ski jumper without even recalculation of
the trajectory or adjusting ramp exit speed :-) */

* Error handling of already fragile routing SAFIs are becoming even
more fragile due to additional likehood for errors in the new message

* Additional information is likely to be not congruent with routing
information. Per message type separation on say route reflector
requires much more intelligence then say SAFI based filtering and SAFI
based split to peers.

* New message may require standard BGP attributes for filtering, for
policy etc ... so now we will be forced to duplicate attributes
between UPDATE message and Generic Transport Message.

* Attempts to define a generic attribute (to carry various opaque
information) aka "garbage can"  have failed in the past as it was
clearly stated that SAFI space is sufficiently large then for those
information which make sense there is always a room to define a new
SAFI. Now you are with GTM defining not a "garbage can", but "garbage
truck" ! How is this more efficient then having generic attribute ?

* Last but not least recent industry progress have pretty much proved
it that some overlays require subset of BGP information as well as
various other types of information to be distributed to non
traditional routers. It seems that perhaps using other transports (for
example: XMPP) while inheriting a lot of good peoperities of BGP for
loop free distribution may fit much broader range of requirements and
applications yet provide as simple as few lines of xml to define
messages as it seems fit.

The list is much much longer, but let's just start from here ...

Thx,
R.

---

From: "Russ White" <[email-masked]>
Date: Mon, 7 Jul 2014 18:01:04 -0400

> * First - behavior of any given AFI/SAFI is highly defined by it's UPDATE
> message semantics. Carrying opaque stuff around which is unrelated to
> routing is just not fitting there. /* It's like attaching pretty heavy backpack to
> a ski jumper without even recalculation of the trajectory or adjusting ramp
> exit speed :-) */

> * Error handling of already fragile routing SAFIs are becoming even more
> fragile due to additional likehood for errors in the new message

That's why this isn't attached to any AFI/SAFI, but rather just a new message type altogether. There's no routing information defined in this new message type.

> information. Per message type separation on say route reflector requires
> much more intelligence then say SAFI based filtering and SAFI based split to
> peers.

Since it's not an AFI/SAFI, and this isn't designed to carry routing information per se, it doesn't matter... :-)

> * New message may require standard BGP attributes for filtering, for policy
> etc ... so now we will be forced to duplicate attributes between UPDATE
> message and Generic Transport Message.

That's why the communities are included as is -- they may not all apply to the generic message type, but it's easier to reuse code rather than build new.

> information) aka "garbage can"  have failed in the past as it was clearly stated
> that SAFI space is sufficiently large then for those information which make
> sense there is always a room to define a new SAFI. Now you are with GTM
> defining not a "garbage can", but "garbage truck" ! How is this more efficient
> then having generic attribute ?

Wait -- you're arguing that we shouldn't carry this stuff in an AFI/SAFI (which the generic transport message doesn't), but then saying there's no demand for not carrying stuff in an AFI/SAFI. Huh? :-)

:-)

Russ

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 8 Jul 2014 00:12:30 +0200

Hi Russ ...

New message travels on an existing session. I used AFI/SAFI as
indicator of a session.

If so new malformed message may bring down the session with precious
routing information encoded along.

Please tell me how are you by proposing a new message making a session
more robust ?

Also are you going to define new advertisement rules say on RRs for
this new message ?

r.

---

From: "Russ White" <[email-masked]>
Date: Mon, 7 Jul 2014 18:21:13 -0400

> New message travels on an existing session. I used AFI/SAFI as indicator of a
> session.
> 

You can negotiate sending all messages, just standard AFI/SAFI messages, or just this new message type -- so the generic transport allows the implementer (both at the coding level and at the network design level) to decide what information should be carried where, trading that off against the various risks. Using a new session forces the designer to always use two different sessions, which might not be desirable.

> Also are you going to define new advertisement rules say on RRs for this new
> message ?

I assume it would be reflected like any other messages, but we've not spent a lot of time looking at reflection rules specifically. Since it's a new message type, it could easily be offloaded to a new set of reflectors.

:-)

Russ

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 8 Jul 2014 00:31:01 +0200

> You can negotiate sending all messages, just standard AFI/SAFI
> messages, or just this new message type -- so the generic transport
> allows the implementer (both at the coding level and at the network
> design level) to decide what information should be carried where,
> trading that off against the various risks. Using a new session
> forces the designer to always use two different sessions, which
> might not be desirable.

But this is precisely what definition of new AF can also do today. Why
not define a new AF and new attribute to carry the new opaque
information along with AF specific handling rules.

Note that new AF may mean either new AFI or new SAFI - pick your preference.

What is the advantage of defining a new message for your application ?

New message make sense when you are to exchange associated types of
information over given session (example: KEEPALIVE Message or BGP
Diagnostic Message etc ...)

So at the very minimum I would be interested to see a discussion in
this draft (maybe as new section) to compare pros and cons of new
message vs new AF with new attribute.

Thx,
R.

---

From: "Russ White" <[email-masked]>
Date: Mon, 7 Jul 2014 22:00:03 -0400

> > trading that off against the various risks. Using a new session forces
> > the designer to always use two different sessions, which might not be
> > desirable.
> 
> But this is precisely what definition of new AF can also do today. Why not
> define a new AF and new attribute to carry the new opaque information
> along with AF specific handling rules.

Except that using an address family to carry information that isn't an actual address (as in reachability information) is a little odd, to say the least -- and can be rather convoluted. It's simpler to have a message type that is specifically designed not for reachability information, or rather for information not designed for direct consumption in the BGP process itself, but is rather being carried opaquely through the protocol because it's a convenient and handy transport.

A couple of instances are noted in the draft.

:-)

Russ