Subject: Re: 4096 octet message limit?
From: Bradley Reynolds <[email-masked]>
To: Ben Black <[email-masked]>
Cc: [email-masked]
Date: Wed, 4 Aug 1999 19:11:25 -0400 (EDT)

increasing it would mean you could pack more prefixes
into an update.

so, on average, how many prefixes get packed into an 
update (assuming code working)

61256 network entries (153450/307506 paths) using 17130680 bytes of memory
23124 BGP path attribute entries using 3124016 bytes of memory      

3 is the answer.  

for a given update, lets assume average fixed header size
of 255.  giving us 3841 for packing prefix data.  assuming
5 bytes for each prefix, we get 768 prefixes per update.
scanning the path hashes, i couldn't find any greater than 768.  

so, you are going to be improving the situation for a small amount
of paths (scanning the hash table, maybe 100 paths given the path
attribute size varying a bit).  where improving == sending less
updates to advertise all space deemed necessary to advertise as well
as sending less data in accomplishing this end.  

i was scanning through the current ID to see if it made mention of whether
evaluation of each route (meaning collection of all prefixes containing
consistant path attributes) occurs after the receipt of the entire route
or whether it can occur incrementally.  the cursory glance turned up
nothing. in the latter case, there is an advantage to keeping the update
sizes relatively small in a situation of network congestion.

as for the historical reason behind 4096, i don't have the 
answer, but perhaps the above would be valid a argument for
leaving it alone :).

BR

On Tue, 3 Aug 1999, Ben Black wrote:

> Why is there a 4096 octet maximum message size mandated in BGP4
> (both RFC1771 and the latest draft)?  It appears to have simply been
> pasted from the BGP3 RFC, but there is no justification for it anywhere
> that I see.
> 
> Can anyone expand on this?
> 
> 
> Ben
> 
> 

Date: Tue, 3 Aug 1999 22:51:34 -0700
From: Ben Black <[email-masked]>
To: [email-masked]
Subject: 4096 octet message limit?
Sender: [email-masked]

Why is there a 4096 octet maximum message size mandated in BGP4
(both RFC1771 and the latest draft)?  It appears to have simply been
pasted from the BGP3 RFC, but there is no justification for it anywhere
that I see.

Can anyone expand on this?

Ben

From: "John G. Scudder" <[email-masked]>
Subject: Re: minutes of the IDR WG meeting
To: [email-masked] (Yakov Rekhter)
Date: Mon, 2 Aug 1999 20:06:38 -0400 (EDT)
Cc: [email-masked]
Sender: [email-masked]

Yakov Rekhter wrote:
...
> IDR meeting minutes	07/15/99	9:00
> 
> Agenda bashing:
> 	I'll be back (Ward)
> 	Path attributes for multicast (Dave Thaler)
> 
> Dave Ward presentation:
...

One nit-pick:

	s/Dave Ward/John Scudder/

Dave's the tall one.  I'm the one with the beard and the ponytail who
was talking.

Regards,

--John

--
John G. Scudder                       email:  [email-masked]
Internet Engineering Group, LLC       phone:  (734) 213-4939 ext 14
122 S. Main, Suite 280                fax:    (734) 669-8661
Ann Arbor, MI  48104                  www:    http://www.ieng.com

To: [email-masked]
Subject: minutes of the IDR WG meeting
Date: Mon, 02 Aug 1999 16:25:56 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

Attached are the minutes of the IDR WG meeting.

Yakov.
-----------------------------------------------------------------
IDR meeting minutes	07/15/99	9:00

Agenda bashing:
	I'll be back (Ward)
	Path attributes for multicast (Dave Thaler)

Dave Ward presentation:
	Target to architectures that have forwarding detached from routing.
	Problem: software reload/failover
	New capability.
	New revised draft will be summited soon.

	Flags:
	IBB - hability to send Cease message
	ICB - hability to send i'm back message.

	software reload scenario:
	a) Negociate
	b) send SB cease (includes timeout until Open)
	c) Open with ICB (include timeout until reconvergence)

	Recovery:
	a) Negociate
	b) Send Open with ICB

Q: both E and IBGP ?
A: Yes.

Q: What happens when updates come while router is down... 
A: Takes time to reconverge not unlike BGP.

Peter: Do we need a way to verify that we are in sync ? When it comes back it
will have something in memory... how to deal with with memory curruption.

Curtis: Should move the timer to ms... will be failover situations
from primary RP to secondary.
Dave W: Agreed.

Dave W: After expiration of timer old information is flushed out.

Peter: Old information should be purged out after a time.
Yakov: That is refresh... implemented by some vendors.

Proposal to make it a working group document.
No objection from the floor. Proposal accepted.

Curtis: Possible evolution... Add an option just to send the deltas.
Peter: Problems with termination.
Curtis: Add hook to TCP layer.
Peter: It would be nice not to have the complexity of the redundacy in
the router.
[... Discussion of some of the technical difficulties...]
Dave W: Can be extended to do what you want... don't want to hold the
current proposal which can be useful by itself.

Dave Thaler	BGP Path Attributes for Multicast Tree Construction
		draft-idmr-bgp-cast-attr-00.txt

Goals:
	Provide policies on how routes may be used to construct
multicast trees.
Direction Attribute:
	- "Come-From": receive-only route
	- "Go-To": send-only route
	- "Both": no restrictions (default)
Can be used for unidirectional routes
Optional transitive attribute.

Both:
	- Used for bidirectional routes.

Go-To routes:
	- may be useful for Unidirectional links.

Come-From routes: usual mode for multicast.

[ include presentation ]

Yakov: How do you handle agreggation ? You have two routes that you
want to aggregate with different attributes.
Dave T: Shouldn't aggregate.
Yakov: Not a valid answer.

Pedro: Move information in proposed attribute inside multicast NLRI.
Dave T: maybe.
Yakov: Controversial topic... move it to mailing list.

Curtis: Back to the aggregation... have to take both directions and
move it to a "both".
Dave T: Slide on why you cannot combine CF + GT routes to get BOTH...
You get loops and duplicate data.

Dave T: Should this be a IDR document ?
Yakov: Discussion on the mailing list.

From: "David Oran" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Maestro BoF Results
Date: Mon, 2 Aug 1999 11:17:41 -0400
Importance: Normal
Sender: [email-masked]

The Routing Area held a BoF at the Oslo IETF whose purpose was to discuss
potential refinements to the IP multicast model in two areas:
  1) Enhanced two-part multicast addressing to ease scalability and
deployment
     headaches,
  2) Optimizations to exploit the single-sender case

The BoF announcement, along with its scope and agenda, may be found at:
http://www.ietf.org/ietf/99jul/maestro-agenda-99jul.txt.

I am sending this message to who I think are all the relevant WG mailing
lists, and it will also be sent out via IETF-announce, so please let me know
directly if I've missed a relevant group rather than risk clogging peoples'
mailboxes with multiple forwards.

The minutes of BoF are attached below. One of the conclusions from the BoF
was to continue discussions on these subjects to ascertain if there is a
critical mass of support to charter one or more Working Groups to pursue
IETF standards (or other outputs) in these areas. We are therefore
resurrecting a moribund Routing Area mailing list for this purpose:
	[email-masked]
Subscription is via [email-masked]

Thanks to all who participated in the BoF and in advance for useful
low-flamability discussion on the mailing list.

Regards, Dave Oran (routing co-area director)

MAESTRO BOF, Dave Oran
----------------------

AGENDA

History - modify multicast model, do we need a working group
on this?

A number of people think if we simplify the multicast model
there are significant benefits in reducing complexity.
changes: addressing model, assume single sender.

We want to look at the problems today and see how proposed
simplications might help.

Ground rules: talk about problems and how they map to the
proposed simplifications.  from two perspectives, isp's
and architectural view.

Bryan Lyles, Sprint Deployment Strategy
---------------------------------------
Today, multicast enabled, working with vendors and customers to make
it work.  built on PIM-SM, MSDP, MBGP, IGMPV2, GLOP.

Short Term - push current protocols, work in ietf to enhance base.

Certain kinds of applications want single server (radio station,
politician giving speech, dont want opposition heckling him)

Hugh Holbrook, Stanford/Cisco
-----------------------------
Some multicast applications work well with unicast
others its impossible, high data rates, many receivers
questions to isp's - how do you bill for it.  make billing reflect
cost.  so charge by size of group.

	dmm - if i am a source, receivers on same isp are onnet,
	other receivers are offnet. want to billed for offnet folks.

	brad cain - bill by bandwidth, can isp's break even on multicast.

Queries flow down tree, counts flow back up, somehow gather data
to bill src.  access control for large groups, restrict senders
in advance (pirates on tv station), important for commercial
applications too.

	kevin almeroth - why does it work with radia, lawyers are
	the answers, no one owns a multicast address, if they did
	you could sue someone for using yours without permission.

security - source provides passwd to receivers

www.dsg.stanford.edu/hollbrook/express

Jeremy Hall, uunet
------------------
Problems - scalability, single source model ok, hard to implement.
you are trying to restrict something that is not restrictable.
lots of protocols running as ships in the night, ok when it works,
never know which one is not working correctly.  way too much ad hoc
stuff going on. which protocol is broken.  nice to be able to trace
a problem from the sender, to the receiver.  receiver says i'm not
receiving this content.  have to figure out from that info, where
the source is and what the problem is.

Some applications hide the group, so you cant figure out where
to troubleshoot.  people dont understand how it works, so they
cant help you debug.  need education.

Billing problems, counting receivers might be nice but is hard
as groups get big.  onnet vs offnet.  tried to employ things
that are parallel to unicast.  unicast routing tries to dump traffic
asap, mulitcast wants to keep as long as possible.  current model
doesnt scale.  anyone can source to any group and thats a security
problem.  there are a lot of security issues with multicast.

Mark Handley, ACIRI
-------------------
Internet Standard Multicast, where it came from and why it had
nice properties.  direct extension of the unicast model, host
sends packets to destination address, it gets there.  nice
architecure, senders dont need to know about receivers.
recievers dont need to know who senders are.  distributed binding
is useful resource.  senders and receivers dont need to know about
topology, robust, route around failures etc.  hosts dont need to
knows about routing protocool.  need distinction between service
model and its implementation in the network.  separates what
the application wants and how the network achieves it.  clean
separation of routing and transport/application layer.

What can we do with it:

Regular one to many applications - video distribution, data distribution
many to many applications - conferening, games, dont know members in
advance, distributed binding is very robust, changes the way you design
applications (eg wb)

Many to few applications - server discovery

Scoping, used to have ttl scoping, poor for traffic engineering,
great for self organizing applications, expanding ring search,
we lost the ttl in pim, admin scoping getting it back, mzap

Security - can only restrict traffic safely with encryption.
content providers want authentication, have the mechanisms already.

problems:

	forwarding table size, aggregation helps some;
	how can isp's make money;
	lack of scalable routing protocol, bgmp, hierarchical pim,
	  bi-direction pim with grib, bgmp will probably work,
	  hierarchical pim too;
	lack or good network management and diagnostic tools.

serious growing pains, transition from dvmrp painful

distributed binding a key - wb, sdr, mimaze applications

important to avoid constraining network mechanisms to support only one
  to many applications

Bryan - lots of differences of opionion in the community.
Hugh  - avoid overly commplicating things for futures applications
	when we have existing applications that need support now.

jon crowcroft, ucl, www.cs.ucl.ac.uk/research/rama
--------------------------------------------------
Enhancing deering multicast, enhancing the addressing scheme.
class D address is a channel, not really an ip address.
Anonymously names a group of receivers, allows anyone to send to it.
alternatives, allow end systems to be explicit
DCM/connectionless multicast - add list of addresses,
transparency and fault tolerance

David Oran - Final Questions
----------------------------
we have 5 minutes, where should we go with this?

Brian Whetten - wishes had heard more from isps about problems.

TODO - decide which problems are of deployment and which are based
on what we are deploying.

Scott Petrak - 3 things: think about low bandwidth hosts at the end,
  like wireless; thing 2 i missed; small number of senders a worthy
  optimization.

Dorian Kim - deployment problems have been maturity of implementation issues
and how to make all the hacks play together.  havent tried running native
multicast at scales we want.  will find more answers as we deploy and ramp
up, at this point probably not worth limiting model.

Hum votes
	create a mailing list   2/3 hum
	no mailing list 	1/3 hum