Subject: [Idr] draft-white-bgpbgp-00.txt

From: "Russ White" <[email-masked]>
Date: Thu, 3 Jul 2014 10:21:03 -0400

Y'all:

The intent for draft-white-bgpbgp-00.txt is to provide an alternative to the
various stuff we've been doing with address families to carry odds and ends
and bits of data in BGP... If anyone has comments, please push them to the
list. 

:-)

Russ

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 8 Jul 2014 10:26:04 -0400

> and bits of data in BGP... If anyone has comments, please push them to the

I'm replying here rather than hijacking Robert's thread.  He's covering
somewhat different discussion points than I had. :-)

These proposals keep coming to haunt us and I've done what I can to try to
keep them from IDR.  I suspect at some point I may have to declare defeat
and support one.  So, using your draft as a starting point, here's some
general issues I think that are unaddressed:

This sort of "BLOB over BGP" (as we'd called it internally) has an issue in
the sense that at some point you'll want to distribute something bigger than
a BGP PDU.  In your draft, you're providing for 64k messages, which will at
least handle the extension for bigger PDUs.  Eventually something will push
the BLOB case beyond that.  Please consider design (and the implications) of
fragments up front.  I think you may be considering sequence in this case,
but I'm also unclear if that's the use case in mind.

To give a specific use case, consider the distribution of BSR state in BGP
MVPN.  BSR messages may exceed a 4k PDU.  (Credit to Pavan Kurapati for the
discussion.)

The primary pain-point of fragments is consistency and slow-traveling BGP
messages.  When you transmit something that may be a fragment that's part of
new information, it's tricky to know that you have all fragments.  That
tends to lead to sequence / generation numbers along with fragment ID.
(Along with rollover issues in seq no, but we know from IGPs how we'd expect
that to work.)

A 2 octet type is probably too small.  Consider a bigger numbering space.
At some point, it may even be pressed to OID + vendor ID.

Your extended community header is probably intended to be a TLV, but it
looks like it's saying "there's one entry".  That's probably not what you
mean.

In your thread with Robert, you're basically saying "this isn't NLRI".  Part
of Robert's point that is not addressed in this draft is that a significant
part of the reason why people keep trying to throw stuff in BGP is that it
handles (arguably, not in the best way) inter-domain distribution -
including loop detection.  AS_PATHs, reflector cluster behavior, etc.  Those
things have been one of the motivators to simply overload Update.  You'll
need them in something like this.

Another general issue is in-line/side-band signaling.  BGP-LS handwaves the
issue away by strongly suggesting "don't use the same peering infrastructure
for BGP-LS and real routing".  This does the same hand waving, but has
significantly more likelihood for information that isn't useful in side-band
signaling to gum up the works.  Contrarily, your ROA use case (I knew that
would happen at some point) is something that in-line makes some sense.

This isn't an issue of protocol - I think we all know how that should work.
You're placing an operational stake in the ground saying "use Route-Targets
and RT-C to steer this".  I suspect we should do the same with BGP-LS.

-- Jeff

---

From: Jared Mauch <[email-masked]>
Date: Tue, 8 Jul 2014 10:34:59 -0400

> and RT-C to steer this".  I suspect we should do the same with BGP-LS.

I certainly share the concern that Jeff has enumerated in his email.  There are
a number of communicaitnns that people may want inter and intra-domain and BGP
is certainly seen as a means to communicate fully within that functional domain.

With larger integers and numbering space broadly available for each part of a
TLV set, perhaps it's time for something that takes into account these larger
spaces.  Router TCP stacks tend to be broken and the chances of this breaking
something that operators (such as myself) care about is increasing significantly.

While I continue to push on my vendors to fix their TCP bugs in 2014 (and beyond)
moving past 16-bit to 32-bit or similar messaging sizes likely is the right
path forward.

- Jared

---

From: "Russ White" <[email-masked]>
Date: Tue, 8 Jul 2014 12:39:25 -0400

> and support one.  So, using your draft as a starting point, here's some
general
> issues I think that are unaddressed:

Well, my goal is to stop the madness of adding ever more stuff that has
nothing to do with routing directly into the AFI/SAFI construction. It's
become just a dumping ground of all sorts of information. 

> This sort of "BLOB over BGP" (as we'd called it internally) has an issue
in the
> sense that at some point you'll want to distribute something bigger than a
> BGP PDU.  In your draft, you're providing for 64k messages, which will at
least
> handle the extension for bigger PDUs.  Eventually something will push the
> BLOB case beyond that.  Please consider design (and the implications) of

Fragments are an issue -- but, in general, if the originator uses the
sequence and identifier fields correctly, and keeps their tlv's under the
max size for BGP, this shouldn't be an issue. I'd rather not get into
fragmentation, but rather leave it to the originator of the information if
possible.

> At some point, it may even be pressed to OID + vendor ID.

A larger space is fine with me... It can easily be made larger, if there's
consensus around this point. 

mean.

Hmm... I don't know what would need to be changed here -- suggestions?

> In your thread with Robert, you're basically saying "this isn't NLRI".
Part of
> Robert's point that is not addressed in this draft is that a significant
part of
> the reason why people keep trying to throw stuff in BGP is that it handles
> (arguably, not in the best way) inter-domain distribution - including loop
> detection.  AS_PATHs, reflector cluster behavior, etc.  Those things have
> been one of the motivators to simply overload Update.  You'll need them in
> something like this.

We discussed the AS_PATH attribute, and decided that if we use the sequence
and identifier we don't need the AS_PATH to deduplicate/etc. The way the
forwarding rules are written, you should forward if you receive something
new, and discard if you receive something with the same id/seq as what you
already have. 

> would happen at some point) is something that in-line makes some sense.

I think it's most useful to let the operator and vendor decide... The way
this is put together, you can carry the information in the same BGP session
or a separate one -- just depends on what you're carrying. The one thing we
didn't do is allow you to choose which type of TLVs should be carried in
which session -- something that might be a useful addition. There's actually
no on the wire changes to do this, just the ability to filter, I think (?).

> and RT-C to steer this".  I suspect we should do the same with BGP-LS.

I would agree...

:-)

Russ

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 8 Jul 2014 09:54:28 -0700

Russ,

> become just a dumping ground of all sorts of information. 

Whether this is "madness" or not is a matter of *opinion*
(and each of us is entitled to have one).

What is a *fact*, is that as of today the BGP AFI/SAFI construction
is used for quite a few things that one may consider as "nothing
to do with routing" (e.g., Route Target Constraints, BGP VPLS, BGP
flow spec). Which provides an existence proof (means deployment
and operators) that the BGP AFI/SAFI construction is Good Enough
(tm) for what one may consider as "nothing to do with routing".

Yakov.

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 8 Jul 2014 12:58:28 -0400

On Jul 8, 2014, at 12:39 PM, Russ White <[email-masked]> wrote:

> The one thing we
> which session -- something that might be a useful addition.

I think it would be a necessary addition. If this (or something like it) were to take off, an inevitable consequence would be for it to be used to transport multiple data sets -- indeed, that's the whole point. Different data sets will have different characteristics and requirements in terms of their volume and requirements for timely delivery, and at some point somebody is going to be upset if data type foo, with payload size 10 bytes and message frequency 1/week but very low latency requirements, gets hung up waiting for data type bar, with payload size 1000 bytes and message frequency 1/second but very high latency tolerance.

(My hat is that of a WG participant. And I'm not necessarily endorsing the idea, just commenting on it.)

--John

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 8 Jul 2014 13:39:09 -0400

Russ,

> fragmentation, but rather leave it to the originator of the information if

My concern was from having worked through some of the headaches of what it
would take to use BLOB over BGP for BSR.  It does matter and I strongly
suggest that it be considered up front if you'd like this to be viable.

If the answer is "we're never handling fragments", some things that
otherwise fit the solution become non-viable and we're back to additional
hacks.

> Hmm... I don't know what would need to be changed here -- suggestions?

Minimally:
Length field: 2 octets  value divisible by 8.
Value: 0-N BGP extended communities.

Better:
TLVs for community like functions, because we also have ipv6 specific
communities.  Perhaps even wide communities. :-)

The intention of the field is obviously to allow coloring of the data.  If
you *only* ever intend to allow RTs in there, best to state that.  And also
allow for more than one RT.

> new, and discard if you receive something with the same id/seq as what you

That covers the potential of "flooding scope" and is good for loop
prevention/dups.  What's missing is the opportunity for policy outside of
that covered by communities.

> no on the wire changes to do this, just the ability to filter, I think (?).

We agree.  My point is that we've reached enough data that we should be
responsible and start recommending some operational practices.
(Everything and the kitchen sink, as the saying goes.)

-- Jeff

---

From: "Russ White" <[email-masked]>
Date: Tue, 8 Jul 2014 15:07:35 -0400

> Whether this is "madness" or not is a matter of *opinion* (and each of us
is
> entitled to have one).

Of course... I didn't mean to offend, just to say that we keep piling things
into the AFI/SAFI that have no specific relation to destination based
routing. "Stop the madness," is a saying, not a term of condemnation. :-)

> existence proof (means deployment and operators) that the BGP AFI/SAFI
> construction is Good Enough

Sure -- but I also see the protocol becoming more complex over time because
of this additional information. If there's a simpler way to carry this
information, one that allows us to either stream the information out of band
or in band, etc., then we should consider it, IMHO.

:-)

Russ

---

From: "Russ White" <[email-masked]>
Date: Tue, 8 Jul 2014 15:12:22 -0400

> My concern was from having worked through some of the headaches of
> what it would take to use BLOB over BGP for BSR.  It does matter and I
> strongly suggest that it be considered up front if you'd like this to be
viable.

Okay, will talk to Alvaro and Jakob about this.

> communities.  Perhaps even wide communities. :-)

I think it's best to treat communities like functions, or like any other TLV
-- the main point is we don't want anyone to be forced to rewrite the
community code to support the policies around coloring the data and other
sorts of policies.

> > We discussed the AS_PATH attribute, and decided that if we use the
> > sequence and identifier we don't need the AS_PATH to deduplicate/etc.
> > The way the forwarding rules are written, you should forward if you
> > receive something new, and discard if you receive something with the
> > same id/seq as what you already have.
> 
that
> covered by communities.

We could add an optional AS_PATH -- I don't know if we should force "blobs"
to always use an AS_PATH, though (?).

> (Everything and the kitchen sink, as the saying goes.)

Okay, we can add some operational points to the next version -- I'll add it
to the list.

:-)

Russ

---

From: "Russ White" <[email-masked]>
Date: Tue, 8 Jul 2014 15:12:54 -0400

> > The one thing we
> > didn't do is allow you to choose which type of TLVs should be carried
> > in which session -- something that might be a useful addition.
> 
> I think it would be a necessary addition. If this (or something like it)
were to
> take off, an inevitable consequence would be for it to be used to
transport
> multiple data sets -- indeed, that's the whole point. Different data sets
will
> have different characteristics and requirements in terms of their volume
and
> requirements for timely delivery, and at some point somebody is going to
be
> upset if data type foo, with payload size 10 bytes and message frequency
> 1/week but very low latency requirements, gets hung up waiting for data
> type bar, with payload size 1000 bytes and message frequency 1/second but
> very high latency tolerance.

Okay -- will add this to the list of things to add to the draft, as well.

:-)

Russ

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 8 Jul 2014 15:24:18 -0400

On Tue, Jul 08, 2014 at 03:12:22PM -0400, Russ White wrote:
[fragments]
> Okay, will talk to Alvaro and Jakob about this.

Thanks.  If you eventually say "too messy, not going to do it", that's at
least consideration.

> community code to support the policies around coloring the data and other

Agreed.  It's just that as listed in the draft, you get exactly one extended
community, no 1997 communities and no extension for other coloring.

> to always use an AS_PATH, though (?).

I totally agree with you - for many applications it's noise.  But in an
inter-as context, policy will happen.  The scoping AS in wide communities
was added partially for that reason.

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 8 Jul 2014 21:57:15 +0200

Hi Russ,

I think exploring new ideas is always great providing they bring real
value at right price.

So far you keep complaining that things which we carry in BGP have
nothing to do with destination based routing.

Then perhaps a better option is to issue a short one page draft
renaming Network Layer Reachability Information "NLRI" field to
"Database Key"  field - the advantages are that your concern will get
addressed yet multiple implementations, deployments and operational
practices will remain unchanged.

- - -

Meanwhile if we are at concerns regarding BGP I think we have two
serious problems in BGP today:

* dynamic capabilites
* multisessions

Both are either not supported even partially in most implementations
(dynamic capabilites) or supported in a way that they could be
improved (recall my discussion with John in Stockholm IETF regarding
use of TI vs multisession for improving BGP session robustness).

Thx
R.

On Tue, Jul 8, 2014 at 9:07 PM, Russ White <[email-masked]> wrote:
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 9 Jul 2014 08:08:35 +0000

As different kinds of information will be carried in BGP, it seems that some QoS mechanism may be needed on BGP sessions:)

Regards,
Jie

> -----Original Message-----
> From: Idr [mailto:[email-masked]] On Behalf Of John G. Scudder
> Sent: Wednesday, July 09, 2014 12:58 AM
> To: Russ White
> Cc: [email-masked]
> Subject: Re: [Idr] draft-white-bgpbgp-00.txt
> 
> I think it would be a necessary addition. If this (or something like it) were to take
> off, an inevitable consequence would be for it to be used to transport multiple
> data sets -- indeed, that's the whole point. Different data sets will have
> different characteristics and requirements in terms of their volume and
> requirements for timely delivery, and at some point somebody is going to be
> 1/week but very low latency requirements, gets hung up waiting for data type
> bar, with payload size 1000 bytes and message frequency 1/second but very
> high latency tolerance.
>

---

From: Randy Bush <[email-masked]>
Date: Wed, 09 Jul 2014 18:11:09 +0900

> As different kinds of information will be carried in BGP, it seems
> that some QoS mechanism may be needed on BGP sessions:)

possibly more important would be encryption, where you might take a look
at draft-dukhovni-opportunistic-security-01.txt

randy

---

From: Eric Rosen <[email-masked]>
Date: Wed, 09 Jul 2014 11:09:39 -0400

Robert> Then perhaps a better option is to issue a short one page draft
Robert> renaming Network Layer Reachability Information "NLRI" field to
Robert> "Database Key" field - the advantages are that your concern will get
Robert> addressed yet multiple implementations, deployments and operational
Robert> practices will remain unchanged.

Actually, a much better idea would be the following:

- Define a new AFI.

- Store the "bgpbgp" type value in the SAFI.

- Store the "bgpbgp" identifier value in the NLRI.

- Invent a new attribute to hold the "bgpbgp" data (as you have suggested)

Now just use "ordinary" BGP (no new message types needed), and presto,
problem solved.  Err, wait, what was the problem again?

The real question is: why is the proposal in the bgpbgp draft any better
than the proposal above?  The draft states several times that its proposal
is better, but neglects to offer any justification for that claim.  (I don't
regard "stop the madness!" as much of a justification.)

There are of course some real differences between the above and the "bgpbgp"
proposal.

For instance the "bgpbgp" proposal only allows filtering and distribution
control to be based on 8-octet extended communities, whereas ordinary BGP
allows filtering and distribution control to be based on arbitrary sets of
attributes (including IPv6-address-specific RTs, which the "bgpbgp" proposal
doesn't accommodate).  No need to mess with stuff like LOCAL_PREF, MED,
etc.  I guess it's supposed to be obvious that the general policy mechanisms
of BGP are not needed for generic transport.  Perhaps I'm the only one to
whom that is not obvious.

The draft does allow the "cost community" (an extended community) to be
carried, but I guess it will have no real effect, because the BGP decision
process is not used.  If you get two different messages with the same type,
identifier, and sequence number, there is no complicated decision process to
run through, you just install the first one you get. Well, what could
possibly go wrong?  I guess it's supposed to be obvious that if two messages
have the same type/identifier/sequence, they couldn't possibly have
different data, and there couldn't possibly be any reason to prefer one over
the other, or to force all the routers to make a consistent choice.

Bottom line: if there is one thing worse than using BGP to carry arbitrary
data, it's inventing a new BGP message type for which the updating rules are
completely different.  If your information distribution requirements cannot
be adapted to utilize the BGP mechanisms, you really should use something
else.  On the other hand, if the BGP mechanisms are well-suited to your
information distribution requirements, why would you want to use a
completely different mechanism inside BGP?

BTW, if the SAFI isn't big enough to hold the type, the type can be put into
the NLRI field.  That's how we got the notion of "typed NLRI" ;-)

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 9 Jul 2014 17:14:57 +0200

Excellent summary Eric !

And you are right that perhaps it would be helpfull to first see a problem
statement ... then worry how to solve it ;))

R.

---

From: "Russ White" <[email-masked]>
Date: Thu, 10 Jul 2014 08:48:38 -0400

> - Invent a new attribute to hold the "bgpbgp" data (as you have suggested)

I'm perfectly fine with this, actually. 

> problem solved.  Err, wait, what was the problem again?

The problem is that BGP is starting to be used to transport everything,
whether we like it or not. IMHO, it's better to define a solid way to do
this, rather than simply assuming one exists, and then creating 15 different
ways to do it, all slightly different, because we just assume everyone is
going to do it the same way. I guess, given the sarcasm on the list, that
everyone would prefer to have 15 different ways to do something, each of
them slightly different, because that's a much simpler solution than
creating one way and sticking to it across the board.

Russ

---

From: Thomas Mangin <[email-masked]>
Date: Thu, 10 Jul 2014 14:26:30 +0100

Hello Russ,

I have sympathy for your proposal.

I just refactored ExaBGP code recently and UPDATE parsing is really a Russian doll work, where each new RFC sub-define a new NLRI with different semantic (and sub-semantic).

At least  http://tools.ietf.org/html/draft-frs-bgp-operational-message-00 is proposing to use new message type as they need to pass more than NLRI information.
So I believe trying to provide a framework for it to not have multiple different format would make sense.

Thomas

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 10 Jul 2014 10:04:23 -0400

Russ,

> creating one way and sticking to it across the board.

I think part of what Eric's exercise showed is that we pretty much already
have plumbing to do this.  If we were to extend this one step further, the
type of BLOB you're transporting implies format.  If that format happens to
be a list of prefix-like things we're back to NLRI.

Where this proposal really differs is the idea that we may be transporting
more general data that isn't an NLRI.  In that case, a new message type may
help.  If you expect this stuff to be flooded without understanding using RR
and other BGP plumbing, then not requiring capability advertisement also
helps.

While I'm sympathetic to Thomas's issue, regardless of format, if it's data
to be understood there will always be that marshalling/demarshalling layer.
The only thing that's really changed over the years has been the conventions
permitting automation.  (XDR, ASN, JSON, protobufs, etc.)

-- Jeff

---

From: "Russ White" <[email-masked]>
Date: Thu, 10 Jul 2014 10:27:55 -0400

> and other BGP plumbing, then not requiring capability advertisement also

Sure -- but given the sense of the WG, there's no interest in doing anything
more or less than what we're doing today -- inventing new semantics for
everything that comes along, no matter whether or not it fits. So, I'm
inclined, at this point, to let the draft die, and forget presenting it in
Toronto.

It was an effort at making things simpler. The WG isn't interested in
simpler. So be it.

Russ

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 10 Jul 2014 16:35:11 +0200

Russ,

If you are claiming that the draft is simplifying something it would be
useful to compare it against current "complex way" side by side.

Perhaps then those of us who just either do not see what is so complex
today or do not see how your proposal makes it simpler could learn.

Rgs,
R.

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 10 Jul 2014 10:40:06 -0400

> It was an effort at making things simpler. The WG isn't interested in

Much of my own harassment is coming from a slightly different perspective:
I don't think we want it now.  I suspect we'll want it later.  Here's the
issues we need to solve for that time.

But for the time being, it's a bit academic.

-- Jeff

---

From: "Russ White" <[email-masked]>
Date: Thu, 10 Jul 2014 10:40:35 -0400

> If you are claiming that the draft is simplifying something it would be useful
> to compare it against current "complex way" side by side.

Complexity == a different afi/safi for each type of blob encoding, each with their own formatting, rules, pieces of the packet header to ignore, etc.

Simple == one format, based on TLVs, that has the flexibility to encode whatever is needed, without being forced to include pieces of the packet header that won't be used, etc.

But again, if your definition of "simple," is "we'll define a new AFI/SAFI type for any sort of blob of information that comes along, no matter whether the AS_PATH or any other attribute makes sense in the context of this blob, and we'll just stick it in BGP because that's a convenient way to carry random information throughout the Internet," then have at it. What I see is a lot of stuff accruing that we're eventually going to pay for in terms of implementation and deployment -- we're building huge buildings on foundations designed for something much smaller and different, and just expecting it all to work.

So, again, I'm going to drop this draft, and ask that the slot be removed in VanCouver. No point in even attempting to try and make a case for this sort of thing if there's no perception that BGP is becoming an overused kitchen sink.  

Russ

---

From: "Russ White" <[email-masked]>
Date: Thu, 10 Jul 2014 10:45:29 -0400

> I don't think we want it now.  I suspect we'll want it later.  Here's the
issues
> we need to solve for that time.

Then we'll just wait until all sorts of stuff is already stuffed into BGP,
and worry about sorting it out then, rather than seeing the trend now and
making a way (whether this is the right way or not) to provide transport for
things that don't fit. Each time we run into adding something new into BGP,
we always say, "well, we have these requirements now, and we don't have time
to deploy a new transport mechanism, or wait for IDR to design and build a
new transport mechanism within the BGP framework." So each time we add
something new, and then go back to, "we might need this later, but for now
we don't."

And hence we never do anything but keep adding more and more stuff in,
because we always find a way to release the pressure without solving the
root problem. At least that's the picture I see developing (perhaps
wrongly). So, again, I'm dropping the draft, and won't present in Toronto.
We can raise the issue again in a few months/years when someone suggests
adding some other new custom coding in the AFI/SAFI, and end up in the same
place yet again (we can stuff into this little corner over here, whether or
not it fits, we need the extension now, etc.).

:-)

Russ

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 10 Jul 2014 16:57:34 +0200

Russ,

I don't follow your bashing of adding new stuff to BGP as last time I read
your proposal it is also adding new stuff to BGP. The fact that this is new
message vs new AFI seems completely irrelevant.

As to what BGP was designed to do I will let Yakov answer it :)

All you are doing is just shifting the demux point from AFI/SAFI to message
type. Is this such an advantage ?

Moreover more and more information to be carried in networks should be sent
p2mp - what BGP transport really does. Putting on top of then a new layer
of RT based information scoping via use of RTC is very ugly patch.

We do need a new protocol which can be optimal in registering for
information needed via query/reply form. IF-MAP comes to mind as example.
Your proposal in no way solves this issue. In fact BGP-LS fits query/reply
model as example rather then sending entire LSDB all over the separate BGP
layer out of which depending on the application only a tiny subset of data
may be used.

That is IMHO a direction we should persue maybe in RTGWG maybe in OPS ...

Best,
R.

On Thu, Jul 10, 2014 at 4:40 PM, Russ White <[email-masked]> wrote:

> useful
> Complexity == a different afi/safi for each type of blob encoding, each
> with their own formatting, rules, pieces of the packet header to ignore,
> etc.
>
> Simple == one format, based on TLVs, that has the flexibility to encode
> whatever is needed, without being forced to include pieces of the packet
> header that won't be used, etc.
>
> But again, if your definition of "simple," is "we'll define a new AFI/SAFI
> type for any sort of blob of information that comes along, no matter
> whether the AS_PATH or any other attribute makes sense in the context of
> this blob, and we'll just stick it in BGP because that's a convenient way
> to carry random information throughout the Internet," then have at it. What
> I see is a lot of stuff accruing that we're eventually going to pay for in
> terms of implementation and deployment -- we're building huge buildings on
> foundations designed for something much smaller and different, and just
> expecting it all to work.
>
> So, again, I'm going to drop this draft, and ask that the slot be removed
> in VanCouver. No point in even attempting to try and make a case for this
> sort of thing if there's no perception that BGP is becoming an overused
> kitchen sink.
>
> Russ
>
>
>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 10 Jul 2014 16:58:42 +0200

sorry one typo ..

s/should be sent p2mp/should NOT be sent p2mp/

r.

On Thu, Jul 10, 2014 at 4:57 PM, Robert Raszuk <[email-masked]> wrote:

> All you are doing is just shifting the demux point from AFI/SAFI to
> message type. Is this such an advantage ?
>
> Moreover more and more information to be carried in networks should be
> sent p2mp - what BGP transport really does. Putting on top of then a new
> layer of RT based information scoping via use of RTC is very ugly patch.
>
>> But again, if your definition of "simple," is "we'll define a new
>> AFI/SAFI type for any sort of blob of information that comes along, no
>> matter whether the AS_PATH or any other attribute makes sense in the
>> context of this blob, and we'll just stick it in BGP because that's a
>> convenient way to carry random information throughout the Internet," then
>> have at it. What I see is a lot of stuff accruing that we're eventually
>> going to pay for in terms of implementation and deployment -- we're
>> building huge buildings on foundations designed for something much smaller
>> and different, and just expecting it all to work.
>>

---

From: "Russ White" <[email-masked]>
Date: Thu, 10 Jul 2014 11:00:39 -0400

> type. Is this such an advantage ?

Not really, but I'm not going to belabor the point, because it should be clear from the draft that's not all that's involved. When we get to the point that BGP falls over, we can all talk about what BGP was "meant to do," and then propose some real solution to the problem at hand. 

Sue -- please take this draft off the presentation list for Toronto.

Russ

---

From: Eric Rosen <[email-masked]>
Date: Thu, 10 Jul 2014 11:17:23 -0400

Jeff> Where this proposal really differs is the idea that we may be
Jeff> transporting more general data that isn't an NLRI.

I think the bgpbgp proposal is not really about the syntax or the semantics
of the data, it's about the updating procedures.  

In standard BGP updating, the AFI/SAFI/NLRI determines whether two routes
are comparable.  The decision process then chooses among comparable routes
using a set of procedures that is well-defined, policy-driven, and
guaranteed to converge.  The bgpbgp proposal introduces a new decision
process, based on sequence numbers, that is completely different than the
old one.  This is not so simple.  In the link state IGPs, updating is based
on sequence numbers, but there are elaborate mechanisms for synchronizing
and resynchronizing the sequence numbers.  These mechanisms seem to have been
omitted from the bgpbgp proposal.

>  The sequence field can be used by the application to indicate the
>  "freshness" of the information carried in the data field.  The most
>  obvious use of this field would be a monotonically increasing number
>  indicating a newer version of some information advertised previously.

I see quite a few problems embedded in this approach:

- There is no requirement that two messages with the same type/identifier
  originate from the same router.  So what sense does it even make to
  compare the sequence numbers?

- There is no statement about whether the sequence space wraps around, or
  clamps at the maximum value.  Each method has problems that would need to
  be addressed, but are not addressed in the draft.

- The draft first suggests that the use of the sequence numbers is left to
  the application, and then bases the entire application-independent
  updating procedure upon them.  

- Even if two messages with the same type/id originated at the same router,
  I don't see anything that ensures that the "newer" message has the
  "larger" sequence number.  The originating router may have rebooted
  between those messages, and there is no procedure to ensure that all the
  pre-reboot messages are eradicated before any of the post-reboot messages
  are received.  

Sequence number zero has the special meaning "flush", but it seems to me
that the flush messages could easily be seen at some router out of sequence
with respect to the non-zero messages. This would result in inconsistencies
around the network.  

To me, adding a sequence-number-based updating procedure to BGP is not a
simplification.  Anyone who's worked on the sequencing mechanisms of link
state routing will know how complicated it is to ensure convergence based on
sequence numbers.  Sure, someone could claim, "once we add a completely new
decision process to BGP, we'll have the ultimate one-size-fits-all solution,
and that will greatly simplify our lives in the future".  Well, I'm sure
we've all heard that one before.

Thomas> At least http://tools.ietf.org/html/draft-frs-operational-
Thomas> message-00 is proposing to use new message type as they need to pass
Thomas> more than NLRI information.

If I understand correctly, the messages in that draft are just passed from
one end of a session to the other.  The UPDATE message, on the other hand,
is a mechanism for distributing information around the entire network, in a
P2MP signaling paradigm.  The distribution requirements for Advisory
message, e.g., are very different than the distribution requirements for the
UPDATE message.  So it makes sense to have a different message type.  But I
think the bgpbgp proposal is focused on information that does need to be
distributed around the network, so it makes a lot less sense to have a
different message type.  Of course, it's also worth noting that the
operational-message draft is long expired.