[RAM] Jabber notes from the IETF 69 meeting

[Marshall Eubanks <[e-mail]>]

Here is the complete jabber log from today's meeting - without any  
editing, and including smiley's, as text and pdf.
Enjoy.

Regards
Marshall

Jabber Chat with [e-mail], [e-mail],  
[e-mail], [e-mail], [e-mail],  
[e-mail], [e-mail], [e-mail],  
[e-mail], [e-mail], [e-mail],  
[e-mail], [e-mail], [e-mail],  
[e-mail], [e-mail], [e-mail],  
[e-mail], [e-mail], [e-mail].
10:17 AM
The topic has been set to:
10:17 AM
questions interrupt or at the end?
lixia: good point
haven't discussed tradeoffs
that's Dave Meyer
(dave meyer?)
mike: religion about keeping routing table small, but this comes at a  
cost
solutions...
problem: too many entries in GRA, too many updates
hm, a GRA is just "globally routable address". I hadn't noticed  
"space" on that slide.
(scribe: not GRAS?)
terminology: GRA: globally routable address space
if you see anything that's missing or is incorrect, let us know
framework will become better over time
process not finished yet, what I say is not complete
10:10 AM
looked at solutions
framework didn't fall out of the blue sky
as in sbrim 

Brim
prepared with Scott Brim(m?)
it's good, as long as they repeat audience questions into the mike
lixia about taxonomy
(microphone trouble)
I can hear 

if you can't hear me, it's no important
lixia:
3.10: solutions required to be deployable from a technical  
perspective, not touching other perspectives
3.9: clarification: not current level of security as of publication,  
but level current when solution is deployed
rearranged reference
3.8: new criterium: stability
3.6: changed "needed" to "required"
10:05 AM
also added: strongly desired that control plane scale independently  
from...
3.1 terminology change: routing plane -> control plane
comments not absorbed yet due to vacation
want to go throug the changes
we have a draft
tony li: design goals
change accepted
agenda proposal: first dino, then elliot, dave, luigi
I mean, audio
slides at http://videolab.uoregon.edu/events/ietf/ietf698.m3u
agenda bashing
no scheduled breaks, no cookies but there will be a break at some point
thanks
iljitsch is jabber scribe for part of the day
Hi, Scott - hope all is well.  I'm in TAM
ah
are any of you actually in the room?
9:55 AM
Hi
Good morning...
2:05 AM
Testing
10:15 AM
proposed solutions:
proposed solutions
a1: only use topologically aggregatable address space = multihoming - 
 > multiple addresses (GSE, shim6, Six/One)
[e-mail] has joined this chat.
a2: move "edge" prefixes out of global routing system by tunneling
10:20 AM
dino and lisp folks use ETR/ITR terminology, I didn't
egress tunnel router
ingress tunnel router
(sorry I always mix up itr / etr)
Geoff Huston : Beware of false dichotimies
geoff: beware of false dichotomies, is there an a3?
lixia: not complete, but no a3 at this time
Geoff : you have the ability to numberthe network, not the edges
[e-mail] has joined this chat.
This is just categorizing things that have actually been submitted  
here. There may be more ideas out there, and we're hoping that we can  
establish dimensions along which we can evaluate new concepts as they  
are proposed, but we don't have all possible approaches listed.
lixia: you can recursively apply a2
Geoff : I think that there are more
lixia: send a more precise description
Q : Do you have an example ?
aaaaaaaaaaa 

_
[e-mail] has joined this chat.
Geoff : MPLS moves out of those dichitomies
Geoff : I was asked for a quick example, I gave one off of the top of  
my head
I don't get his point
Geoff : The tokens in the routing system might be how to get rid of  
the packet relative to you, not necessarily relative to the destination
[I am not sure what that means]
10:25 AM
maybe it means the packet is tagged with my egress, as opposed to my  
destination's ingress ?? But that's the way we're all doing it  
already. ?
lixia: For some solutions the mapping happens at the border router
lixia: for others, like shim6, it happens inside the host
lixia: 3 questions
Scott: where is the slide pack that Lixia is using (url?)
lixia: Geoff may have more
lixia: Q1 How do you get mapping information
I don't see it on the web. We were still fixing them this morning.
lixia: how do you detect reachability failures
Ask her if she has it up for FTP somewhere
Geoff: please do send mail about what you said.
she's talking - I though you may have a copy 

I do ... I'll send it
I'll send mail
lixia: I forgot : in some designs, we assume that CE may be the ETR []
lixia: Question 3 : When you detect the failure, how do you handle it
lixia: will elaborate more in future slides
lixia: also abuse issue and the scalability issue
lixia: what is the assumption of the size of the row
Question : You don't have how to update mapping info
lixia: this will be included later
[e-mail] has joined this chat.
[questioners please state names !]
lixia: Question 1 - elaboration
lixia: Suppose that our campus has three providers
10:30 AM
lixia: who holds this information
lixia: Q1.1 how to inject the mapping information into the system
lixia: Q1.2 who holds this information
lixia: The holder and the user are not necessarily the same entity
lixia: two kinds of updates
lixia: one is changes in mapping information, like dropping a provider
lixia: this is separate time granularity from the second, which is  
topology failures
lixia: when a router goes down
lixia: etc
lixia: How does one get mapping information into the system
[e-mail] has joined this chat.
lixia: the second way the mapping happens when the packet is injected
[I missed the first one]
lixia: How you get this information out - some proposals will mention  
the specifics - the security question
[e-mail] has left this chat.
lixia: is an important consideration, so that you don't get  
misdirected to the wrong site
lixia: You can push or pull this information
lixia: push = flood
lixia: security is a critical component
10:35 AM
lixia: how to detect failures is very important
She distinguishes "flood" as general and "push" as more specific, as  
to who gets sent the information.
lixia: we have a routing system to that inside the local address  
space, or at least this is the defaukt
lixia: do not harm is one of the principles
Scott  - an automated flood of ROW to GRA mappings is just a  
reinvention of BGP - right?
lixia: when the mapping happens at a edge router (this is a new issue  
we do not have today)
i.e. its precisely the same as the automated flood of ROW to nexthop
geoff: not necessarily, IMO. BGP works across multiple hops, a system  
like this wouldn't necessarily have hops
lixia: today, a failure along one path results in a prefix withdrawl  
and the data flow will move to other paths
so it could be like iBGP, not eBGP
lixia: if the routing system stops at the border of a cloud
then BGP updates will not cover a path update [outside of the cloud]
lixia: the ETL [?] prefix is not in the routing system
[e-mail] has joined this chat.
lixia: Means for failure detection
lixia: given that the routing system cannot handle these failures
lixia: how can you detect them ?
lixia: if you put the mapping information into the source host -  
shim6 relies on the upper layers to detect the errors
lixia: In A2 a new thing will have to detect these
Internet omnia in duo partes divisa est
lixia: what I have seen relies on ICMP messages or their equivalent
10:40 AM
[e-mail] has left this chat.
[e-mail] has joined this chat.
Q : There is another factor - you can rely on symmetric paths
who is it?
Erik Nordmark
lixia: how to handle failures
aha
we can't assume symmetric paths
lixia: when the host handles failures
[Erik was hard for me to hear]
you should try the audio feed 

I think Erik's point was that at the edge, you see both directions  
but due to asymmetric paths, you generally don't in the middle
aha, got it
Erik's point is that the end host (and in some cases routers very  
close to them) can see symmetric paths and can do more
thanks all
(iljitsch beat me to it 

lixia: there is no free lunch. If we take the A2 approach the packets  
have gone into the system. How do you handle inflight packets when a  
failure is detected
lixia: failures are hopefully not permanent
[e-mail] has left this chat.
lixia: even for Shim6, hosts try to keep up with the status of the  
different destinations
lixia: for A2, we will see later how this is handled
Dino ; In the core of the network, how to handle failures is well known
lixia: there are two additional factors
[e-mail] has joined this chat.
lixia: one is how to handle packets during lookup delay
[on faiure]
10:45 AM
lixia: two new factors that introduce packet losses
Dino : My comment was about the locatability reachability issue
Q : Duplicate detection efforts by multiple hosts is not necessarily  
a problem
[please give names !]
Tim Sheppard
lixia: There is not a central node - everybody addresses - detects  
failure and takes corresponding efforts
lixia: the mapping stuff introduces new issues that don't exist today/
lixia: if you take the "host take care of itself" approach you wish  
you could share this information
lixia: we have two computers that try and reach Google (for example)
lixia: first guy tries address X
lixia: it doesn't work, he uses address Y
Tim : Google certainly announces multiple addresses
[e-mail] has left this chat.
Tim : You seems to be assuming that hosts are only connected through  
one network
Q : You seem to be assuming that you have to do the mapping before  
you inject packets into the network
I don't see why he thinks that
Kevin Fall
10:50 AM
Q : If you can encode the destination into the packet you may be able  
to do this more effeciently
Kevin : If we have a world where devices are less and less capable,  
like mobile devices, putting this into the host makes me uncomfortable
this is Erik again now
Erik : If it is only X and Y that is easy. If you have 16 things to  
chose from that is different
[e-mail] has joined this chat.
lixia: You can see that in some of the proposed solutions
Summary of questions
q1 : How to get mapping info
lixia: Her are evaluation criteria
[too many to retype]
data delivery performance: delay due to mapping lookup, delay due to  
suboptimal paths, loss due to lack of mapping info, loss during  
transient failure, traffic concentration
Kevin [?] : Does the routing have the ability to pick shortest paths  
is an important factor
(yes this is Kevin Fall)
lixia: Should we make dynamics separate
[e-mail] has joined this chat.
lixia: now it is in two places
[e-mail] has left this chat.
Kevin does not seem to be talking about the criteria, but how to  
measure along the dimensions the criteria invoke. That's fine. We  
didn't get there very much.
[e-mail] has joined this chat.
lixia: What I hear you saying is that we should have a separate item  
about this
10:55 AM
about dynamicity
Erik : I am confused - there is a risk of a solution that solves  
multi homing but forgets about traffic engineerin g
lixia: I don't see that there is a fundamental difference between the  
two
Erik : There are multiple levels at which you might want to do TE
lixia: I didn't mention about that
Q : There is an area where we need a lot more data
^ Eliot Lear
Elliot : If you solve multi homing is that good enough ? And if not,  
why not ?
Sandy Murphy : The security of the router system.
Sandy : John Scudder at the last IETF had a functional description of  
the security of the routing system
Sandy : Your slide said security of the mapping info, which is only  
one part of the security of the routing system
it shouldn't be a hierarchy. I learned the term "facet-based  
categorization" from Melinda.
lixia: This is a very important question. We definitely need a  
document or a framework there
Ilijitch : The number of prefixes from the RIR is growing by 7 % /  
year, while the prefixes in the table is growing by 16% / year
11:00 AM
Ilijitch : if people have PI space and they want to announce multiple  
blocks in mulitple locations - there are only 25 As now and 225,000  
prefixes
25k
lixia: We will incorporate these comments into the next draft - the  
first draft
who's next?
Vogt
Christian Vogt
thanks
[e-mail] has left this chat.
Christian : I want to present the Six / One solution, which is a  
combined edge based host based solution
Christian : three stakeholders
Christian : Edge networks, providers and hosts
Christian : Edge networks want to select from multiple providers
Christian : another goal of edge networks is to reduce the cost of  
network configuration
Christian : the goals of the host is also to select a particular  
provider
Christian : it is also a goal of the host to adapt
Christian : say if the provider changes, or on RTT measurements
Christian : there are 3 types of solutions
11:05 AM
Christian : current practice is PI space to edge networks, which is  
globally visible
[has a table on his graph]
Christian : Each PI address block increases size of address space
Christian : Host goals are not met with PI space as the hosts does  
not see these
Christian : Shim6 was developed to solve the routing address space  
growth
Scott: I just uploaded the slides to RRG page http:// 
www3.tools.ietf.org/group/irtf/trac/wiki/RRGagendaChicago (it is the  
same as the one I sent you last night)
OK thanks
Christian : With shim6 the edge network cannot select providers, as  
these are selected by the hosts
with the tail slides (on individual proposals) cutoff
shhhh 

Christian : Another thing that edge networks may not like is that  
they don't have PI space
Christian : to give the edge networks more capabilites and reduce  
rehoming costs there
Christian : have been recent proposals with PI space and a mapping  
between PI space in a edge network and provider dependent space in  
the global network
Christian : the goal of Six/One was to meet all of these goals
Christian : here is an overview
Christian : you can think of six /one as a combination of Shim6 and 8+8
\Christian : Erik Nordmark has a draft to combine these
11:10 AM
Christian : draft-nordmark-shim6-esd
Christian : Hosts get dependent address space
Christian : within the edge network every link gets a subnet ID
Christian : hosts then configure one address per subnet prefix
[e-mail] has left this chat.
Christian : all of these addresses have a common, cryptographically  
generated, interface identifies
Christian : which is the same across the entire address bunch
Christian : the host shows a single stable address to each application
Christian : with a variable address on the wire
Christian : what is different from shim6 is that the edge network is  
able to rewrite the routing prefix of a host
Christian : Why ?
Christian : so that the edge network can change providers
Christian : hosts need context of each other's address bunches
Christian : this is split into two parts
Christian : this figure shows how the rewriting works
Christian : both the host and the corresponding host run a six/one  
instance
[e-mail] has left this chat.
Christian : when an application sends a packet, say with routing  
prefix 1000
11:15 AM
Christian : I forgot - there are two cases - one where the addresses  
are passed through, and the second where they are rewritten
Christian : the host is suggesting the provider
Christian : at some point the edge network may decide to rewrite the  
routing prefix of the packets source address
to povider number two
Christian : the six one instance on the correspondant host recognizes  
this change
Christian : and adopts it
Christian : so that the return packet goes through provider 2
Christian : applications don't see the change
Christian : when the host sends the next packet its own six/one  
instance it uses the new routing prefix
Erik Nordmark : How do you enforce [symmetric paths]
That was Dave Oran
Christian : You don't need host specific state to do the re-writing
Q : How does the edge network detect that the correspondant host can  
detect this change
[e-mail] has left this chat.
Christian : I was not talking about discovery of support
Q = Tim Sheppard
Christian : I was assuming you can rely on the correspondent host to  
detect this
Christian : I am assuming that at this point
Tim : This is a neat idea but I am worried if we can ever get there
11:20 AM
Tim : I wish we had thought of this years ago
Christian : The crucial part is of course to bring this into the hosts
Dino : This looks very much like Shim6
Christian : The edge network can decide where the packets go
Dino : You mean that there are routers in the edge network doing this ?
Dino : You have that Six / One vertical bar. Where is the functionality
Christian : The veritical bar is within the host
Christian : The rewrite happens within a rotuter, presumabably a  
border router
Dino : Now tell me the difference between the this slide and GSE
my last name is spelled "Shepard" (only one 'p')
Christian : In GSE the host doesn't see the provider. The source  
addresses don't show this. They cannot adopt the provider and don't  
when it is changed
[e-mail] has left this chat.
Christian : The cryptographic indentifier can be used to make sure  
that these packets belong together
the rewriting router has to have state for each connection, right ?
Brian Carpenter : I wish that this had come up in the Multi-6 WG
Brian : I was waiting on a version of GSE that was plausible
[e-mail] has left this chat.
[e-mail] has joined this chat.
11:25 AM
Brian : I believe that this is very promising. I am not proposing  
that we drop Shim6, as Geoff might hit me [laughter]/
Goeff : Shim6 does its own failure detection
Christian : Both the host and the edge network can rewrite the  
addreses. However, the edge network has the final say
[e-mail] has joined this chat.
Geoff ; The problem is that the only time you understand true failure  
is in the host.
[I am not sure I got that right]
Christian : This is the collision of the goals that we have
Christian : The routers only rewrite the source address
his point is that if the edge rewrites without seeing the return  
path, it can rewrite to an address the host rewrote away from to get  
around failure of the return path
Christian : You can only select the providers that the edge network  
directly connects to
so geoff is saying that this breaks shim6 failure avoidance
thanks Dave - yes that is my point - the host can see the failure,  
but the edge router cannot
Q : Did you remove anything from Shim 6 ?
Christian : No. There is stuff on top of Shim 6
Jari : This is cryptographically slightly different
[e-mail] has left this chat.
[e-mail] has joined this chat.
Christian : The router in the edge network only needs to rewrite the  
routing prefix. It doesn't need to keep any host state in the edge  
network
[e-mail] has joined this chat.
[e-mail] has joined this chat.
11:30 AM
Q : Suppose that there is a 3000 prefix. If the host doesn't know  
about it, the packet will get dropped on the floor. This is different  
of 8+8
Q=Erik Nordmark
[thanks!]
Christian : The next slide shows how context gets established
Christian : The Six / One has a local context which shows what  
providers are available, and an incomplete remote context
Christian : That context is given an unique context ID chosen by the  
host.
[e-mail] has joined this chat.
Christian : With the first packet the host sends there is piggy back  
information to describe the hosts context
Christian : with adiditonal information so that the correspondent  
host can verify that these belong togther
Christian : when the packet arrives, the correspondent host has a  
complete local and remote context
Christian : the correspondent host sends back the corresponding  
information
Christian : after that, each side only sends context ID's
Christian : One of the goals was to reduce the cost of  
reconfiguration when the edge network rehomes
11:35 AM
Christian : the basic idea is to split the router configuration into  
subnet ID (which doesn't have to change) and one set of routing  
prefixes which does have to change
Christian : there doesn't have to be any link specific updates
Christian : routers only have to rewrite the subnet prefix
[e-mail] has joined this chat.
Christian : Six/One only handles changes within one address bunch
[e-mail] has left this chat.
Christian : Host mobility and host multi-homing and during host  
network renumbering will cause changes in address bunches
Christian : these will require a separate protocol
[e-mail] has joined this chat.
[e-mail] has joined this chat.
Christian : Middle box interoperablity
Christian : Devices like firewalls operate on addresses of hosts
Christian : this will still work
Christian : these middle boxes can indentify hosts by masking the  
routing prefix
Christian : similar to 8+8
Christian : Identifying a remote corresponding host - by looking at  
the local host with which it communicates
11:40 AM
Christian : the triple of subnet, context and identifier ID can  
uniquely indentify a host
Christian : [Summary slide]
[e-mail] has joined this chat.
Dino : Have you got any input from operators about the trade off  
between tunneling and re-writing ?
Dino : Did you consider tunneling
Q : Back when Mike wrote 8+8 he said that rewriting would be useful  
for operators
Q=Erik Nordmark
Q ; This rewriting is a useful way of doing traffic engineering
this is Suresh Krishnan
11:45 AM
[sorry - interrupt]
Suresh asked how it worked with CGAs, and Christian explained HBAs
Geoff : I think that there is a tension that Shim 6 does more. When  
the edge sites are busy rewriting - the host knows about connectivity  
- the hosts and the edges are trying to do something subtly different
Christian : The writing in the edge network can only affect the  
source address
Christian : that does not affect the provider at the correspondant host
Christian : the writing is a local think
Christian : I assumed that the edge network was aware of which  
provider has connectivity
11:50 AM
Christian : the writting can only affect the local routing
Q : You have decided to make the signalling from the host - the host  
was selecting the path - if you chose to override this, the packet  
will be going out the provider you want, but you cannot ensure that  
the correspondent host makes that choice
Q=Tim Shepard (with correct spelling this time 

[e-mail] has joined this chat.
Tim : In Shim6 the end host is making all of the decisions. I almost  
think that there is some means of communicating the networks desires  
for traffic engineering to the end host
Christian : Another approach is in terms of transistion
Christian : It would be easier to cope with legacy hosts if you do  
not change addresses during a connection
Q : The beauty of rewriitng in the router is that this is a router  
through which the packet is passing, so it could have dropped the  
packet anyway
Q=Erik
11:55 AM
Erik: So presumably it has authoriity to change the packet
Erik : With PI space it is pretty clear who can select the path. With  
Shim 6 this is moved to the host. This is a mixed approach
Christian : In this approach the host can only suggest
Thomas Narten : In this case the host and the edge network do not  
have consistent information. Some times they will make the wrong  
decision for the other one
Geoff : Here is a simple example. Path A and Path B are completely  
different. The edgte network wants to TE to Path A. The hosts have  
found that there is a
Geoff : a break in Path A, and want to use Path B. There is no  
signalling mechanism to share this infromation
right
Geoff : Unlike what Brian said, we saw some of these proposals
[computer battery break]
[e-mail] has left this chat.
12:00 PM
[e-mail] has joined this chat.
Q : If the network could signal TE - one way of doing that is by  
dropping it, or rate limiting it
Q=Tim Shepard
[e-mail] has left this chat.
Tim : If the host could have a collection of prefixes, there is a  
real traffic engineering question here. Is that in scope for the RRG ?
[e-mail] has joined this chat.
Christian : The ability of the edge network - you can give it full  
control. It might not have the full view, as Geoff has said
[e-mail] has joined this chat.
Q : If the network is going to rewrite something, the network is  
saying, you can use this one, the end host has the set of possible paths
[this was Dow Street speaking]
[I didn't understand that ]
I think Dow was saying instead of rewriting, edge could tell host  
what to rewrite it to (and drop traffic that isn't rewritten by the  
host)
Dino : I was think of the opposite - if we want session reachability,  
it might be useful if the hosts could tell the routers which paths to
Dino : That means more mechanisms
I think those who don't remember multi6 are forced to relive it. 

[even I know you, I may not know your voice !]
lixia: My stduents couldn't make it here
12:05 PM
lixia: APT
lixia: Where does APT sit ?
[e-mail] has joined this chat.
lixia: Its an older sister of LISP
lixia: We didn't know that RRG was the venue for this
lixia: APT does two parts
lixia: distributes mapping information
lixia: then what do you do with it
to clarify my previous comment - there is not any re-writing in the  
network.  the host selects addresses for the packet - and this  
selection impacts the path that is taken.
lixia: Three types of nodes
lixia: standard routers, the routers of today
[e-mail] has left this chat.
lixia: in organge there are the routers that understand this new  
information
lixia: they hold the mapping information
however, this host-based selection of addresses is bounded to the set  
of allowable addresses published by the network.
[e-mail] has left this chat.
lixia: the ITRs are the users of this information
lixia: We submitted a draft for the IETF deadline
lixia: but then detected some issues which have been changed
lixia: Mappers - these are new device
[e-mail] has left this chat.
[e-mail] has joined this chat.
lixia: these store entire mapping information
12:10 PM
lixia: What if you have multiple mappers
lixia: we propose anycast to reach them
lixia: each AS should have one
lixia: at least
Dino : Are you required to use anycast ?
lixia: if you have multiple mappers, yes
lixia: Mappers tell the ITRs what mapping entries to use
lixia: The mappers do control, TE
[e-mail] has left this chat.
lixia: In return the ITRs are as simple as possible
lixia: The goal for the tunnel routers os minimal changes and stay  
simple
lixia: the brains are in the mappers
lixia: Each ITR has one entry for each routable prefix
lixia: No mapping entry, tunnel packet to the mapper
lixia: the mapper forwards the packets, abnd responds with a mapping  
entry back to the ITR
[e-mail] has joined this chat.
lixia: this is influenced by the goal of making the ITR simple
lixia: I want feedback on this goal
lixia: We hope that there are no changes to other existing routers
lixia: Although such changes might be optional;
lixia: examples
12:15 PM
lixia: edge prefixes are numbers
lixia: GRA addresses are letters
(in the slide, not literally 

(though the idea of reducing the routing table to 26 prefixes is  
strangely appealing)
make it binary and reduce to 2 prefixes....
(yeah but half of them are already taken by dns root servers 

[sorry, interrupt]
lixia: [Stepping through situation 1]
12:20 PM
lixia: If there is a failure, the mapper learns about it from the BGP  
stuff
lixia: When the mapper sends the new mapping information to the ITR,  
it sets a new TTL for this
[the ttl is a mapping ttl, not a hop count]
Q : Does the mapper return all information ?
Q = Eliot Lear
lixia: We assume that the ITR is as simple as possible
lixia: So we only send one
Elliot : We need to look at this later
lixia: If you notice a failure, you just forward packet to the mapper
lixia: As I said before, for preferred path, you put a longer TTL
lixia: Situation 2
lixia: This is a new failure mode
[e-mail] has left this chat.
lixia: "Michael" has no routable prefix and so then his link fails  
this does not go into the global routing table
so the ITR does know this
lixia: How to do the data forwarding
Robert asked the load-splitting question in the ITR
12:25 PM
lixia: Michael's ETR forwards the packet to its default mapper
lixia: Michael's ETR Mapper tries to find an alternate GRA tunnel  
address
lixia: The dat handling
lixia: data handling goal is to minimize packet losses
lixia: 2 options to inform sender
lixia: the first is easier
lixia: send an ICMP destination unreachable message to the ITR, which  
forwards it to its mapper
lixia: the second assumes a well known mapping address. The ETR  
domain mapper sends a message to the ITR's mapper
lixia: The source mapper needs to keep information about currently  
failed things
[e-mail] has left this chat.
12:30 PM
[e-mail] has left this chat.
You left the chat by logging out or being disconnected.
Rejoining chat room…
[e-mail] has joined this chat.
[e-mail] has joined this chat.
[e-mail] has joined this chat.
[e-mail] has joined this chat.
[e-mail] has joined this chat.
[e-mail] has joined this chat.
[e-mail] has joined this chat.
[e-mail] has joined this chat.
[e-mail] has joined this chat.
[e-mail] has joined this chat.
[e-mail] has joined this chat.
[e-mail] has joined this chat.
[e-mail] has joined this chat.
[e-mail] has joined this chat.
[e-mail] has joined this chat.
[e-mail] has joined this chat.
[e-mail] has joined this chat.
[e-mail] has joined this chat.
[e-mail] has joined this chat.
[e-mail] has joined this chat.
[e-mail] has joined this chat.
[e-mail] has joined this chat.
11:50 AM
Christian : the writting can only affect the local routing
Q : You have decided to make the signalling from the host - the host  
was selecting the path - if you chose to override this, the packet  
will be going out the provider you want, but you cannot ensure that  
the correspondent host makes that choice
Q=Tim Shepard (with correct spelling this time 

Tim : In Shim6 the end host is making all of the decisions. I almost  
think that there is some means of communicating the networks desires  
for traffic engineering to the end host
Christian : Another approach is in terms of transistion
Christian : It would be easier to cope with legacy hosts if you do  
not change addresses during a connection
Q : The beauty of rewriitng in the router is that this is a router  
through which the packet is passing, so it could have dropped the  
packet anyway
Q=Erik
11:55 AM
Erik: So presumably it has authoriity to change the packet
Erik : With PI space it is pretty clear who can select the path. With  
Shim 6 this is moved to the host. This is a mixed approach
Christian : In this approach the host can only suggest
Thomas Narten : In this case the host and the edge network do not  
have consistent information. Some times they will make the wrong  
decision for the other one
Geoff : Here is a simple example. Path A and Path B are completely  
different. The edgte network wants to TE to Path A. The hosts have  
found that there is a
Geoff : a break in Path A, and want to use Path B. There is no  
signalling mechanism to share this infromation
right
Geoff : Unlike what Brian said, we saw some of these proposals
[computer battery break]
12:00 PM
Q : If the network could signal TE - one way of doing that is by  
dropping it, or rate limiting it
Q=Tim Shepard
Tim : If the host could have a collection of prefixes, there is a  
real traffic engineering question here. Is that in scope for the RRG ?
Christian : The ability of the edge network - you can give it full  
control. It might not have the full view, as Geoff has said
Q : If the network is going to rewrite something, the network is  
saying, you can use this one, the end host has the set of possible paths
[this was Dow Street speaking]
[I didn't understand that ]
I think Dow was saying instead of rewriting, edge could tell host  
what to rewrite it to (and drop traffic that isn't rewritten by the  
host)
Dino : I was think of the opposite - if we want session reachability,  
it might be useful if the hosts could tell the routers which paths to
Dino : That means more mechanisms
I think those who don't remember multi6 are forced to relive it. 

[even I know you, I may not know your voice !]
12:05 PM
lixia: My stduents couldn't make it here
lixia: APT
lixia: Where does APT sit ?
lixia: Its an older sister of LISP
lixia: We didn't know that RRG was the venue for this
lixia: APT does two parts
lixia: distributes mapping information
lixia: then what do you do with it
to clarify my previous comment - there is not any re-writing in the  
network.  the host selects addresses for the packet - and this  
selection impacts the path that is taken.
lixia: Three types of nodes
lixia: standard routers, the routers of today
lixia: in organge there are the routers that understand this new  
information
lixia: they hold the mapping information
however, this host-based selection of addresses is bounded to the set  
of allowable addresses published by the network.
lixia: the ITRs are the users of this information
lixia: We submitted a draft for the IETF deadline
lixia: but then detected some issues which have been changed
lixia: Mappers - these are new device
lixia: these store entire mapping information
12:10 PM
lixia: What if you have multiple mappers
lixia: we propose anycast to reach them
lixia: each AS should have one
lixia: at least
Dino : Are you required to use anycast ?
lixia: if you have multiple mappers, yes
lixia: Mappers tell the ITRs what mapping entries to use
lixia: The mappers do control, TE
lixia: In return the ITRs are as simple as possible
lixia: The goal for the tunnel routers os minimal changes and stay  
simple
lixia: the brains are in the mappers
lixia: Each ITR has one entry for each routable prefix
lixia: No mapping entry, tunnel packet to the mapper
lixia: the mapper forwards the packets, abnd responds with a mapping  
entry back to the ITR
lixia: this is influenced by the goal of making the ITR simple
lixia: I want feedback on this goal
lixia: We hope that there are no changes to other existing routers
lixia: Although such changes might be optional;
lixia: examples
12:15 PM
lixia: edge prefixes are numbers
lixia: GRA addresses are letters
(in the slide, not literally 

(though the idea of reducing the routing table to 26 prefixes is  
strangely appealing)
make it binary and reduce to 2 prefixes....
(yeah but half of them are already taken by dns root servers 

[sorry, interrupt]
lixia: [Stepping through situation 1]
12:20 PM
lixia: If there is a failure, the mapper learns about it from the BGP  
stuff
lixia: When the mapper sends the new mapping information to the ITR,  
it sets a new TTL for this
[the ttl is a mapping ttl, not a hop count]
Q : Does the mapper return all information ?
Q = Eliot Lear
lixia: We assume that the ITR is as simple as possible
lixia: So we only send one
Elliot : We need to look at this later
lixia: If you notice a failure, you just forward packet to the mapper
lixia: As I said before, for preferred path, you put a longer TTL
lixia: Situation 2
lixia: This is a new failure mode
lixia: "Michael" has no routable prefix and so then his link fails  
this does not go into the global routing table
so the ITR does know this
lixia: How to do the data forwarding
Robert asked the load-splitting question in the ITR
12:25 PM
lixia: Michael's ETR forwards the packet to its default mapper
lixia: Michael's ETR Mapper tries to find an alternate GRA tunnel  
address
lixia: The dat handling
lixia: data handling goal is to minimize packet losses
lixia: 2 options to inform sender
lixia: the first is easier
lixia: send an ICMP destination unreachable message to the ITR, which  
forwards it to its mapper
lixia: the second assumes a well known mapping address. The ETR  
domain mapper sends a message to the ITR's mapper
lixia: The source mapper needs to keep information about currently  
failed things
12:30 PM
The topic has been set to:
test
[e-mail] has left this chat.
[e-mail] has joined this chat.
[sorry - Jari and I both lost Internet connection for about 3 minutes]
[e-mail] has joined this chat.
Audio seems to be gone. Please type a lot 

Dave Thaler : My question is whether the new ETR learns the new  
destination or has to send packets to ETR 2 as if he was a mapper
[e-mail] has joined this chat.
I'm losing audio due to drilling in the wall beside me
12:35 PM
lixia: This is the question of the brains of the ITRs
[e-mail] has joined this chat.
lixia: There is the possibility that if ETR 1 knows all of the  
mapping information for its conencted to it can directly forward  
packets to ETR 2
My question was whether ETR2 (who can't send packets to destination  
and has to forward to his default mapper) learns the new mapping (to  
ETR1 in the example) or whether all traffic continues to go to  
default mapper
[e-mail] has left this chat.
lixia: Distributed mappings
what does that mean?
lixia: between ASes
since in situation 3, lots of sources could be sending to the  
destination and have the same problem, so if he doesn't learn the  
mapping, lots of traffic ends up going via the default mapper
lixia: Quick and dirty solution is to add to BGP
lixia: So we propose a new BGP transitive attribute
[e-mail] has left this chat.
and if it does learn the mapping, then it works just like the case  
where it's an ITR
lixia: the mapping entry is the edge prefix to GRA address mapping
scott -- is the audio still out?
lixia: An edge network sends a singed mapping to al providers,  
together with its key
So ... this pushes "important" mappings to the mappers, mappers pull  
"less important" mappings from somewhere, and ITRs pull from the  
mappers.
Leslie: I'm getting 404 not found at UoO
a provider network floods thier customers mappings to other provider  
networks by BGP
Q : We are securing BGP at some point.
Can we secure these mappings
Q=Erik
Erik : Presume that secure BGP says, I am allowed to speak on behave  
of this prefix
Erik : Here, I think we need another mechanism
12:40 PM
Dino : Are these mappings advertised in line ?
lixia: It doesn't use another top[ology
Dino : So, you will have to modify all BGP routers
lixia: This is a detail that I don;'t remember now
Dino : If you don't change the NLRI then youwill have a name space  
collision
lixia: No
[e-mail] has left this chat.
Dino : They will
Dino : The path attributes are associated with a NLRI
lixia: Did I say this was quick and dirty ?
Q : At some point you stop advertising customer routers. What is the  
trigger ?
Q : I think it will be much cleaner to define a new SAFI
John : I would like to join the people who are encouraging you to  
abandon this particular use of BGP
John : People may filter BGP - this is an unreliable way of  
transmitting this information
12:45 PM
Erik : I have a higher level question. The end result that the  
mapping information for every end site would be in the RIB of every  
router of every tier 1 ISP.
that was Dave Oran
lixia: This was another detail that I didn't want to discuss [laughter]
Joel Halpirin : You have said that you have to distribute the whole  
table - do you have to do this or not ?
Halpern
lixia: Why not ?
audio is back (thanks much!)
lixia: We let everybody inject their own piece into the system
Dino : Packets go into the default mapper
Dino : The ITR doesn't know what to do so it sends it to a default  
mapper
another issue: the data plane of the default mapper needs to be well,  
huge
Dino : If you use anycast, you can't pick which one to send to, so  
they all have to contain the complete mapper
right
otherwise how do you know which to talk to?
right scott
or does a packet chain from one to the other, wandering through the  
lonely night until it finds a place to call home?
well you could have multiple anycast addresses for disjoint address  
space ranges
<nod>
but then there's a new routing protocol to route map packets
[e-mail] has left this chat.
as long as the default mapper and ITRs agree
[e-mail] has joined this chat.
lixia: In defense of pigybacking on BGP
right (but could be static config)
sure, but the aggregate of those default mappers still add up to one  
omniscient default mapper
right
it's just a distributed device at that point
[e-mail] has joined this chat.
12:50 PM
lixia: Mapping updates are far less problematic than BGP routing updates
jgs: exactly
as long as there's a clear algorithm to select one you're ok -- like  
5 anycast addresses
lixia: APT is not married to BGP
and what about any damage done by the new attribute (path explosion,  
convergence, ....)
lixia: If you have a better solution we will be happy to consider
sure, you can easily figure out how to distribute it -- but that's  
not responsive to joel's comment
lixia: Mapping information is only accepted from configiured BGP peers
correct, APT can't work with CONS as currently defined
lixia: Mappers talk to ITRs in the same AS
lixia: So, security is local
lixia: mapping information does not cross boundaries
lixia: border link failure packets can only be sent by GRA packets
lixia: You could do something about secure commiunication between  
mappers
lixia: Our current goal is to say that address will not change
[e-mail] has joined this chat.
lixia: edge prefixes may not have mappings to start with
we seem to be on schedule
lixia: We take the soft state religion
lixia: refresh on a regular basis - all infroamtion has a ttl  
attached to it
12:55 PM
lixia: Security issue - how can mappers find other mappers kets
lixia: Could send through BGP annioucnement
lixia: Keys can be sent through multiple paths
[e-mail] has left this chat.
lixia: so key spoofing can be detected
lixia: by comparing results along different paths
lixia: priority is assigned by the owner of the prefix
lixia: Once the traffic flows inside the routable space, the ISPs do  
what they are already doing
lixia: Security - publicize all keys
lixia: the number of ASes in the routable space is 2 - 3 orders of  
magnitude than the edge space
[this network may drop in 15 seconds]
1:00 PM
lixia: We need more data
? from UCN : We are collecting netflow data. If you have software, I  
can run it on our traces
I think it's Luigi Iannone
lixia: We could use that. We don't care about the traces, just the  
distribution
yes, it was Luigi
from UCL Belgium
[e-mail] has left this chat.
[e-mail] has left this chat.
lunchtime!
[e-mail] has left this chat.
[e-mail] has left this chat.
[e-mail] has left this chat.
[e-mail] has left this chat.
[e-mail] has left this chat.
[e-mail] has left this chat.
[e-mail] has left this chat.
[Mention of a proposal from Cornel U that lixia thinks might be  
valueable
You left the chat by logging out or being disconnected.
2:15 PM
Rejoining chat room…
The topic has been set to:
1:00 PM
[Mention of a proposal from Cornel U that lixia thinks might be  
valueable
lunchtime!
from UCL Belgium
yes, it was Luigi
lixia: We could use that. We don't care about the traces, just the  
distribution
I think it's Luigi Iannone
? from UCN : We are collecting netflow data. If you have software, I  
can run it on our traces
lixia: We need more data
12:55 PM
[this network may drop in 15 seconds]
lixia: the number of ASes in the routable space is 2 - 3 orders of  
magnitude than the edge space
lixia: Security - publicize all keys
lixia: Once the traffic flows inside the routable space, the ISPs do  
what they are already doing
lixia: priority is assigned by the owner of the prefix
lixia: by comparing results along different paths
lixia: so key spoofing can be detected
lixia: Keys can be sent through multiple paths
lixia: Could send through BGP annioucnement
lixia: Security issue - how can mappers find other mappers kets
12:50 PM
lixia: refresh on a regular basis - all infroamtion has a ttl  
attached to it
lixia: We take the soft state religion
we seem to be on schedule
lixia: edge prefixes may not have mappings to start with
lixia: Our current goal is to say that address will not change
lixia: You could do something about secure commiunication between  
mappers
lixia: border link failure packets can only be sent by GRA packets
lixia: mapping information does not cross boundaries
lixia: So, security is local
lixia: Mappers talk to ITRs in the same AS
correct, APT can't work with CONS as currently defined
lixia: Mapping information is only accepted from configiured BGP peers
sure, you can easily figure out how to distribute it -- but that's  
not responsive to joel's comment
lixia: If you have a better solution we will be happy to consider
and what about any damage done by the new attribute (path explosion,  
convergence, ....)
lixia: APT is not married to BGP
as long as there's a clear algorithm to select one you're ok -- like  
5 anycast addresses
jgs: exactly
lixia: Mapping updates are far less problematic than BGP routing updates
12:45 PM
it's just a distributed device at that point
right
sure, but the aggregate of those default mappers still add up to one  
omniscient default mapper
right (but could be static config)
lixia: In defense of pigybacking on BGP
as long as the default mapper and ITRs agree
but then there's a new routing protocol to route map packets
<nod>
well you could have multiple anycast addresses for disjoint address  
space ranges
or does a packet chain from one to the other, wandering through the  
lonely night until it finds a place to call home?
right scott
otherwise how do you know which to talk to?
right
Dino : If you use anycast, you can't pick which one to send to, so  
they all have to contain the complete mapper
another issue: the data plane of the default mapper needs to be well,  
huge
Dino : The ITR doesn't know what to do so it sends it to a default  
mapper
Dino : Packets go into the default mapper
lixia: We let everybody inject their own piece into the system
audio is back (thanks much!)
lixia: Why not ?
Halpern
Joel Halpirin : You have said that you have to distribute the whole  
table - do you have to do this or not ?
lixia: This was another detail that I didn't want to discuss [laughter]
that was Dave Oran
Erik : I have a higher level question. The end result that the  
mapping information for every end site would be in the RIB of every  
router of every tier 1 ISP.
12:40 PM
John : People may filter BGP - this is an unreliable way of  
transmitting this information
John : I would like to join the people who are encouraging you to  
abandon this particular use of BGP
Q : I think it will be much cleaner to define a new SAFI
Q : At some point you stop advertising customer routers. What is the  
trigger ?
lixia: Did I say this was quick and dirty ?
Dino : The path attributes are associated with a NLRI
Dino : They will
lixia: No
Dino : If you don't change the NLRI then youwill have a name space  
collision
lixia: This is a detail that I don;'t remember now
Dino : So, you will have to modify all BGP routers
lixia: It doesn't use another top[ology
Dino : Are these mappings advertised in line ?
12:35 PM
Erik : Here, I think we need another mechanism
Erik : Presume that secure BGP says, I am allowed to speak on behave  
of this prefix
Q=Erik
Can we secure these mappings
Q : We are securing BGP at some point.
a provider network floods thier customers mappings to other provider  
networks by BGP
Leslie: I'm getting 404 not found at UoO
So ... this pushes "important" mappings to the mappers, mappers pull  
"less important" mappings from somewhere, and ITRs pull from the  
mappers.
lixia: An edge network sends a singed mapping to al providers,  
together with its key
scott -- is the audio still out?
lixia: the mapping entry is the edge prefix to GRA address mapping
and if it does learn the mapping, then it works just like the case  
where it's an ITR
lixia: So we propose a new BGP transitive attribute
lixia: Quick and dirty solution is to add to BGP
since in situation 3, lots of sources could be sending to the  
destination and have the same problem, so if he doesn't learn the  
mapping, lots of traffic ends up going via the default mapper
lixia: between ASes
what does that mean?
lixia: Distributed mappings
My question was whether ETR2 (who can't send packets to destination  
and has to forward to his default mapper) learns the new mapping (to  
ETR1 in the example) or whether all traffic continues to go to  
default mapper
lixia: There is the possibility that if ETR 1 knows all of the  
mapping information for its conencted to it can directly forward  
packets to ETR 2
lixia: This is the question of the brains of the ITRs
12:30 PM
I'm losing audio due to drilling in the wall beside me
Dave Thaler : My question is whether the new ETR learns the new  
destination or has to send packets to ETR 2 as if he was a mapper
Audio seems to be gone. Please type a lot 

[sorry - Jari and I both lost Internet connection for about 3 minutes]
2:15 PM
[e-mail] has joined this chat.
test
:blinks
we're back!!!!
[e-mail] has joined this chat.
Jim Griffioen
Separating Routing and Forwarding
Postmodern Internet
Jim : Tony asked me to come and talk about our NSF project
This is a view of the future
[e-mail] has joined this chat.
Jim : What are we trying to do here ?
Jim : Now we are looking at much higher level issues
Jim : with lots of stakeholders
Jim : with lots of different requirements
Jim : We are saying, what if we take a clean slate approach
2:20 PM
Jim : we are not interested in backwards compatibility
Jim : this is early in the process
[e-mail] has joined this chat.
Jim : with lots of open issues
Jim : what we are doing
Audio not working
[e-mail] has joined this chat.
Jim : parts of what we are doing you have seen before
Jim : what are the problems now
Jim : the hourglass approach is the right way to do it
Jim : but routing, forwarding and addressing are entangled
Jim : trust issues were largely ignored in the early design
Jim : we would like to separate policy from mechanism
[e-mail] has joined this chat.
Jim : the service is opaque
[e-mail] has left this chat.
Jim : some of our work is motivatd by a paper by Dave Clark
Jim : tussles between players should be played out on top of the  
mechanism
this leads to kludges, which are now ossified kludges
Jim : building blocks
Jim : want to implement policy outside of mechanisms
Jim : deep packet inspection should never be necessary on the  
forwarding path
Jim : isolate forwarding from any endpoint addresses
Jim : avoid hierarchical or topology based indentifiers
Jim : we also want to separate customer and provider relatonships  
from topology
2:25 PM
Jim : Assumptions
Jim : network infrastructure is deployed to make money
Elliot Lear : About allowing users greater control over the path  
taken by packets
Eliot (spelled with one L) asked why, Jim responded saying  
applications trying to build overlays today to get greater contol
Jim : Application developers are building overlay networks to not  
take the routing offered by the probividers
[e-mail] has joined this chat.
Joel Halperin : What is a rough order of magnitude about header  
versus data bits
Halpern
Jim : Once you send the first packets through, you can often reduce  
the state in the remaining packets
Jim : we are assuming that hardware speeds continue to increase, so  
we can do significant computing, including cryptographic computing,  
on a per packet basis
Jim : 5 components in building blocks
Jim : forwarding directive. Where is this packet heading, and a  
partial path to get there
[e-mail] has joined this chat.
[e-mail] has joined this chat.
Jim : the idea is that the source has some control over where the  
packet is going
2:30 PM
Jim : motivation directive
Jim : why should this packet be forwarded
[e-mail] has joined this chat.
Jim : we are sttill trying to figure this out
Jim : also default motivations, say within a domain
Jim : next is the accountability field
Jim : we would like to put in an unforgeabile record of who handled  
the packet
"within a domain" would be a scope, not a motivation
Oh. Never mind.
Jim : another BB is the knobs field - how this packet should be treated.
Jim : in the opposite direction we have a dials field to pass  
information back
Jim : I would like to talk here about our routing infrastructure
to forward packets between realms
Jim : our goal is not to provide an address space, just to do forwarding
Jim : terms
Jim : endpoint is a destination
Jim : forwarding node is inside the network
Jim : a realm is a coillection of nodes and channels
Jim : a channel is a means of transporting packets
Jim : and an end channel is the last hop
Jim : every channel is named
Jim : nodes are anonymous
Jim : every channel has a unique channel ID
based on a secret held by the two nodes at each end
Jim : naming channels allow for abstracting
2:35 PM
Jim : If you name nodes
Jim : abstracting them requires heirarchical structure
Jim : nodes and realms behave the same way
Jim : what does forwarding do
Jim : forwarding nodes look at forwarding directives
Jim :upon a new packet
Jim : verify it passed through channel
Jim : if next link is directly attached
Jim : send it
Jim : if no next channel
Jim : it is a path fault
Jim : the fauliting node sends the packet to a predetermined Path  
Fault Handler
Jim : the PFH carry out routing policy
Jim : but may not route
Jim : what about path selection ?
does the PFH return a next_hop?
Jim : PoMo separates path selection from topology discovery
Jim : three components of path selection
Jim : first - selected by the source
Jim : assume it knows the internal topology of the realm it belongs to
[e-mail] has joined this chat.
2:40 PM
second - the destination
it also needs to knows the internal topology of the realm it belongs
Jim : third are the providers
Jim : it is the providers responsibility to get the packet across its  
realm
Jim : let me explain locators
Jim : the path into the destinations realm is the locator
Jim : a locator defines ingress points and paths to a destination  
node (an EID).
Jim : We don't define specifications, but they are mapped to a node
Jim : the transit providers provide translations from partial paths  
to full paths
Jim : how does the source discover topology ?
Jim : within a realm it is simple - link state advertisements
Jim : the realm only advertises egress links
2:45 PM
Jim : we introduce a channel level at a node - there is one  
associated with the nodes at each end of a channel
Jim : the channel level represents the maximum level of all realms  
containing
Jim : the node
Jim : whose boundary is crossed by the channel
Jim : given channel levels a boarder node is able to generate an  
advertisements after it
border
learns the entire topology of the realm it must advertise
Jim : topology servers broadcast within their realm - they have to  
know about all interior and border channels of every realm that  
contains it
it floods its existence and topology
Jim : there is a separate set of route servers, where the policy is  
located
Jim : paths are useless unless there is a business relationship
Jim : they distribute this information to the sender and all path  
fault handlers
2:50 PM
Jim : in summary we wanted a thin forwarding mechanism
Jim : forwarding nodes are dumb
Jim : multiple level of abstraction
Questions
?
Peter Lothberg : So, when the forwarding element needs to learn  
something they ask the policy server, and they cache it. If I have a  
long lived flow and the policy changes, how do they learn about it
Jim : We have relatively short timers...
[e-mail] has joined this chat.
Christian : Only the hosts have real knowledge of end to end  
reachability
Jim : We wanted to allow the tussles between services and hosts to  
play out
Jim : You could get that capability
Christian : This would be an add on to get information to the hosts
Jim : Currently the hosts query the route servers anyway, this could  
be added on.
2:55 PM
Ilijitch ; Will all of this information, there is not much  
information in these packets
Jim : We are not designing for today's equipment
Ilijitch : Do you have a ballpark figure for the size of the headers
Jim : Currently we are using CIDs of 160 bytes
[e-mail] has left this chat.
Ilijitch : You can make many packets large, but with VOIP the data  
are small and they need to get through
Jim : Yes, but these are long lived flows
Sue harris : You made some interesting points. Have you gone to see  
if the statistics you used were validated
Jim : Which paper ? The one I posted had no studies on it
This is research in early stages. We have not looked at all of those  
packet flows and how this plays out with them
Jim : the question too is how do you write your applications in the  
future. You may have to rewrite a lot of them
3:00 PM
Sue : You should look back on past research on flow lengths, at least  
how it seems to me, and you should look at past papers
Jim : If you have specific papers you suggest please send it to me
Kevin : I can order N^2 for a graph with N nodes. Why is it better to  
label channels than nodes
[e-mail] has joined this chat.
Jim : As you add abstraction to the flat name space, you don't have  
to change the names of nodes
Kevin : Have you quantified relatively stable ?
Jim : No
Christian : Can we re-use route information for multiple flows ?
Jim : This is an area we are still working on
Christian : Since this is cached on a per flow basis you are  
introducing a connection based approach
Jim : We used a fixed lifetime on how long you store the flow]
Nurd before LISP
[e-mail] has joined this chat.
Different Jim now
Eliot "Jim" Lear?
3:05 PM
sorry - Eliot
Eliot : Draft-lear-lisp-nerd-01
Eliot : A not so novel mapping database
Eliot : for use by lisp
Eliot : all of these mapping databases do not transmit operational  
databases
data
so if a link goes down, you do not change the DB
Eliot : principles and assumptions
Eliot : relatively static provisiioning data
Eliot : the rate is low
Eliot : assume that in flight packet loss or delay is bad
Eliot : the data does not change hop to hop
[e-mail] has left this chat.
Eliot : scale to 10^7 to 10^8 mappings
Eliot : Brian Carpenter's estimate for 2050
Eliot : BGP is not a good candidate, as it is a mechanism for  
transmitting data that changes hop by hop
Eliot : A small number of database authorities
Eliot : they sign the databases
3:10 PM
Eliot : the way they get the mappings is not described in the draft
Eliot : but I envision something like a DNS registrar
Eliot : the data does not change often
Eliot : how to verify the end user is out of scope
Eliot : LISP entries look like mapping data
Eliot : you collect them and then sign them
Eliot : When an ITR comes up it requests an entire copy of the DB and  
then caches it
Eliot : ITRs then request updates periodically
Eliot : it may be possible to use a P2P network to send that
Eliot : ITRs can retreive information from each other (other ITRs)
remember the ancient days, there was something that would trickle out  
jpg files via multicast?
it barely used any bandwidth
Eliot : because the information is signed at the source it doesn't  
matter how you get them
Eliot : there is overlap between LIST-CONS and NERD at the authority
Eliot : this is based on IPv4 right now
Eliot : 16 butes for the first RLOC
[e-mail] has left this chat.
3:15 PM
Eliot : 8 bytes for subsequent RLOCs
for 10^7 EIDs in 2050 that is 400 MBytes of data
(with 4 RLOCs each)
[e-mail] has joined this chat.
if you assume 720 Mbytes of data and a 0.1% change per day, that is
[tiny]
Eliot : This the best possible use of PKIs
Eliot : operators should have a cow about it
Eliot : Do we need a pull model ? No
Eliot : How many sources are there many ?
Eliot : NERD falls apart if there are too many sources
Eliot : Who can be these sources ?
Eliot : order the number of RIRs
Eliot : can we mix and match with other things ?
[e-mail] has left this chat.
Eliot : Yes. You could for example mix and match NERD and ListCons
Dino : This is not that much data - it can be stored in non volitile  
memory
Mark Handley : We have been using P2P to do something very similar
[e-mail] has left this chat.
3:20 PM
Mark : We think that there would be no problem with this data.
Mark :The general idea of signing this is the right idea
Eliot : I didn't use P2P here because I coulldn't describe it in a  
few sentances
Q : I would like to get consensus that handling this is one database  
is the way to do this.
Eliot : Before we dp that I would like to get more data and more  
analysis
John Scudder : You said that this would not be updated frequently
Eliot : The whole thing fails apart if this becomes an operational  
state database
Eliot : You can update to the Nerd DB as often as you want, but they  
control how often updates are propagated down. They are control the  
signing
Ilijitch : There are people who multihome. You need to know which of  
these connections are up
Eliot : This is a general problem with LISP, and I will let Dino  
handle that.
3:25 PM
Eliot : I have to go - thanks !
[e-mail] has joined this chat.
[e-mail] has joined this chat.
Dino : I am going to give two presentations in 45 minutes
[e-mail] has left this chat.
Dino : First is LISP draft changes - 01 to 02
Dino : Most of the technical description will be in Dave's talk
Dino : first LISP draft was in January 2007
Dino : LISP includes multiple variants
Dino : back in January we didn't understand how the DB mapping would  
work
Dino : we originally did IP in IP encapsulation
Dino : We described TE ITRs
Dino : and a data-triggered mapping mechanism
Dino : We want to fix the routing table size problem, but this  
doesn't provide features to the end uses. What we really want to  
provide ingress TE to end users
Dino : Dave Meyer is now co-author
Dino : LISP is now AFI agnostic
3:30 PM
Dino : IP4 and IPv6 - a single solution - IPv4 has a problem as well
Dino : Security was mostly moved into the control section
Dino : we added a multicast section
Dino : We added UDP encapsulation
Dino : people don't like tunneling - there are huge flows (as smaller  
flows are aggreged
aggregated)
Dino : We decided to hash on the inner header to produce a source  
port the LAG router can hash on
Dino : this also made it possible to carry a NONCE for ETR anti-spoofer
Dino : we are taking a very strong stance to NOT put locatior  
reachability into the database
Dino : In LISP, the outer headers have locators the inner headers  
have EIDs
Dino : check sums are turned off on the inner header- sorry Brian -  
because they are stupid
Dino : we added a nonce
Dino : IPv6 looks a lot like IPv4
3:35 PM
Dino : NO locator reachability in the mapping services
Dino : you cannot depend on ICMP unreachables
[e-mail] has joined this chat.
Dino : they are commonly turned off
Dino : if they come to use, you use them, but don't depend on them'
Dino : ITRs know when their partner ITRs go down
Dino : green are EIDs and red are locators
Dino : let's say that we have 4 locators
Dino : 2 are high priority
slide (12)
Dino : as long as they are up, me the ETR are telling you the ITR to  
load split
[e-mail] has joined this chat.
Dino : each ITR advertises implicitly which ones are up in a loc- 
reach-bits bitfield
(one bit per locator)
you can't get any faster than that
3:40 PM
If one of the high priority locators goes down, all traffic is sent  
to the other
if both high priority locators go down, then it is ok to use the  
lower priority ones
Q : I thought that locators are routable. If they are, everyone knows  
their state
Dino : Not all of the boxes run BGP
Q : Why not
Dino : We want to be flexible
Jari : You can survive reachability problems if you are receiving ICMP
Dino : You cannot know if they are being aggregating
Jari : If packets are dropped on the floor in between you don't know it
Dino : I am making the assumption that transit ISPs are transiting.  
That is a strong assumtion I am making
Iljitsch : What if I am a multihomed customer ? Everyone who is  
multihomed has to run an ETR box ?
Dino : If you deploy the ITRs at PE and not at the site.
3:45 PM
Dino : if there are not running eBGP you would have to read another  
protocol
Dino : if you deploy LISP you can remove BGP
Dino : If you have one CE box going to two ISPs, deploy one. If you  
have two going to two, you need two
Dino : Juniper and Cisco have conditional advertisements. If a link  
goes down they withdraw the advertisements
Christian : Do these go to ?
Dino : The ITR describes the reachability at the source site
reachability-flag is an opportunity scheme, not that it will get all  
the ITRs status to all interested parties. e.g. site A talks to site  
B, B may learn the status of all A's ITRs. But site C will not know  
at time time C starts sending to A.
Christrian : Where does the information come from ?
Dino : from the internal routing protocol - there are many exisitng  
mechanisms.
Mark Handley : I am confused. You are sending these bits from your  
ITR to someone's ETR for their ITR to use. Is there a synchronization  
problem
Dino : Most people want to use both paths
3:50 PM
Mark : Is the assumption is that the ETR and the ITR are the same box ?
Dino : It works much better if they are
Dino : Lisp 02 was sent out but didn't quite make the deadline
Dino : fixed bugs in packet format
Dino : LISP implementation report
CISCO has an impklementation
started at IETF Prague on DC-OS
[e-mail] has left this chat.
Dino : hope we don't have to spin silicon
Dino : supports both ITR and ETR
Dino : support for multiple EID prefixes per site and static cache  
mappings
Dino : supports priority and weight configuration
Dino : put some forwarding options in
Dino : you can forward if there is a cache miss - that means that it  
forwards it natively
Dino : you may want to glean mapping in the ETR
Dino : this may be useful for mobility
3:55 PM
Dino : content providers have told me that they want it to work like ARP
Dino : with the mapping provided in the first packet
Dino : we support sending probes in a separate VRF to support LISP 1.5
Dino : LISP 1.0 will probablynever be deployed
Dino : Started unit testing in May 2007
Dino : 02 draft unit testing started in June 2007
[shows unit test topology]
In early July gave Titaniums to Dave Meyer and Vince Fuller
4:00 PM
Dave's site is behind no firewall
Dino : What did we learn
Dino : using firewalls gives you another layer of addressing
\Dino : firewalls mess around with UDP headers
Dino : the ETR didn't care
Dino : ITR should encap all packets
s/should/should not/
Dino : don't encapsulate if there is no mapping
(i.e., sent natively)
Dino : packet through a LISP ETR is simpler than to a LISP ETR
[e-mail] has left this chat.
4:05 PM
Dino : future testing
Dino : ipv6 and v4 concurrently
Dino : mix pi and pa addressing
Dino : testing with BGP
Dino : Lisp 1.5 testing with BGP
Dino : any interested implementors
?
Dino : let us know
Dino : interested in pilot testing
Dino : at first on data plane
Dino : no production at present
Dino : questions ?
Suram [?] from NIST : if you get a packet addressed to your EID ?
Dino : If you can forward it natively you do
4:10 PM
Christian : You need support on both sides if you want to get PI  
addresses out of the routing table
Dino : I f a site is non LISP and it has PI it is injecting into the  
routing table.
Christian :As of now you need an over net transisition. You could  
learn from anycast - it moves the mapping deeper into the core.
this is how I interpret Christian's comment: a (non-LISP) PI site  
injects its prefix, some part of the net is LISPized, and other part  
is not. So the question is whether the LISPized part can have a  
smaller table.
Christian : They could set up a business relationship to do this
Dino : I am not sure if this would work operationally
Christian : It is a transistion mechanism
4:15 PM
Christian : There is a disincentive with being an early adopter,  
because other people who haven't deployed lisp can't reach you
[e-mail] has left this chat.
[e-mail] has joined this chat.
[e-mail] has left this chat.
Dino : What if Google deplyed LISP
[e-mail] has left this chat.
Brian Carpenter :You problem is a legacy site that knows nothing  
about anything. Your problem is to get that to an ITR - any ITR
Brian : You have to figure out how incentivised the ISPs are to put  
out ITRs where customers can reach them
Dino : Do you have a business case for this
one candidate answer to whether EID can be PI or PA: one can avoid  
this confusing question by using different terminology: (1) we are  
talking about IP addresses; (2) the only question is whether an  
address is routable in a given scope.
Dino : no
sorry : Brian : No
brian carpenter?
[i have to take a bio break - Dave Meyer is next]
yes
Brian Carpenter
Brian is wrong 

but he's an academic as of next month so he's allowed
why is brian wrong?
4:20 PM
Within a site, IP routing is going to continue to route subnets etc.  
which include the things we are calling EIDs.
Currently called IP addresses.
They are in fact locators.
What the various map-and-wrap approaches are doing is reducing the  
scope within which they are routable
So Lixia is exactly correct
and if Brian says "no" to her, then he's wrong
I thought you were referring to his comment at the mic.
which made sense to me
I don't have audio anymore
and I'm not in the room
so, the result is "google rules" 

All I saw was above: "brian: no"
ah. that was two different conversations being interleaved
Now I see
brian's "no" was to dino's request for a business case
(sorry for interuption.)
imho the business case is that the Internet growth rate can be  
increased dramatically if we can deal with the "rate*state" routing  
info problem, and the bigger the Internet is the more money the big  
ISPs make.
4:25 PM
Dave Meyer
Lisp Cons
Dave : Cast of thousands
Problem statement
Dave : just for context
Dave : in IPv6 we can split locator and ID
Dave : in v4 it is more complicated
Dave : Noel calls it a jackup model
Dave : you have to jack up the network layer to put more stuff in there
4:30 PM
[e-mail] has joined this chat.
[interrupt]
Dave : Sca;ability is a big issue
Dave :this is a rate * state problem
[really d state / dt]
[e-mail] has joined this chat.
Dave : State will be big, so rate must be small
[e-mail] has joined this chat.
Dave : Lisp cons is a hybrid
Dave : push at the top
Dave : mappings get pulled at the lowest level when needed
Dave : is NOT a DHT
Dave : we can get good EID-prefix aggregation if it is based on  
allocation not topology
Dave : Map requests routed through the logical hierarchy
Dave : Content Access Routers or CARs
Dave : two types - Querying and replying
Dave : the mappings live in the replying cars at the bottom of the  
hierarchy
[e-mail] has left this chat.
Dave : there is no place where the entire database is assembled
Dave : at the very bottom is ITRs and ETRs
level 0 has qCARs and rCars
Dave : above them are CDRs in meshes of meshes
4:35 PM
Dave : ETRs tell CARs which aggregate and push them up to a level of  
CDRs
Dave : if there is a map request, and it isn't cached, it goes up  
until it finds the map, which then is pushed down to the original  
qCAR and then to the ITR
Dave : CDRs can have siblings, parents and children
Dave : we have tried hybrid models
Dave : I have tried to merge NERD and CONS to lower latency
Um ... requests don't travel to ITRs. They travel to replying-CARs  
which then reply (via the tree) back to the querying-CAR which tells  
the ITR.
Dave : in this case, there is no mesh, but you still pull and push  
to / from the top level
4:40 PM
Dave : CARs are default mappers
in this case
Dave : Is LISP 1.5 suffiecient ?
Dave : This is Vince's Idea
CARs are default mappers for control only -- they don't forward packets
[but they do forward mappings, don't they ?]
Dave : Use BGP on an alternative name space
Dave : You run normal BGP on PI space
Dave : and BGP on EID prefixes
swtich to Dino
Dino : Host sends data packet
Dino : it's sent on an alternate typology
[e-mail] has left this chat.
Dino : Moving it out of expensive memory for PI BGP to cheaper  
memory, and maybe even different devices
4:45 PM
Dino : This eventually does to the destination ETR, which sends back  
the mapping
Dino : And the next packet uses it
[e-mail] has joined this chat.
Joel : This seems to imply (1.5) that those who allocate EIDs also  
pick up a packet forwarding responsibility
Joel : We lose some flexibility
Vince Fuller : Yes, and no. You use this overlay network to forward  
query. In that sense this separate typopology is just a way of  
implementing hte database
if you use it for forwarding data then you are correct
Dino : We have this trade off that people have told us, you cannot  
drop a single packet
Dino : You can stretch is out, but not drop it. Others have said, you  
can drop, but we care about latency
[Question about how this like DNS]Vince : People are absolutely
Vince : People are absolutely
terrified about overlaying anything on the DNS
4:50 PM
[e-mail] has joined this chat.
Darryl Lewis : There is a difference. When a qCAR makes a recursive  
lookup, it follows the topology in both directions. There are some  
interesting security implemtnations about this
Mark : It seems there are two route questions : Can the ITR hold the  
entire mapping database, and will they have to ?
Mark : It seem that they will, and that pushes me towards NERD and a  
push model
To Kevin's question: in CONS, all data flows along configured links  
to neighbors only, for security consideration.
next is Luigi
in DNS, any resolver can send to any server directly
That's true theoretically, not necessarily in practice.
(BCP is to ensure that isn't the case)
right, it gets complicated
Luigi : Thanks for remaining for the last presentation !
Luigi : IT networking lab in Belgium
Luigi : starting to talk with Dino to impement LISp
Luigi : We asked ourselves about the costs for making lookups and caches
[e-mail] has joined this chat.
Luigi : We started making traces using netflow on our border router,  
conectect to Belnet with a 1 Gbps link
[e-mail] has left this chat.
Luigi : ~ 10,000 users per day
4:55 PM
Luigi : basic assumption is a /BGP granularity for the mapping
assign one locator to each BGP prefix
Luigi : How many prefixes per day ?
[e-mail] has left this chat.
25,000 to 55,000 per day with a diurnal and a weekly cycle
Luigi : outgoing and incoming flow numbers are roughly the same
Luigi : per minute granulatiry is very spikey
Luigi : 4000 in the night , 11,000 / minute during the day
Luigi : the LISP cache overheard
units are megabits / second
Luigi : cache with 3 RLOCs and 3 minute timeout is 227 KB (night) and  
545 KB (day)
Luigi : Cache size is 10,000 to 18,000
Luigi : number of cache misses is ~ 1000/ minute
5:00 PM
[e-mail] has left this chat.
Luigi : with 13 minute timeouts
Luigi : the cache size doubles
Luigi : can reach 1 MB during the day
Luigi : with 300 minutes time out
30 min ?
13 -> 30 ?
[I believe it was 3, 30 and 300[
[this now is 300 ]
[the first was for sure 3 minutes]
[yes, 3, 30 and 300 - sorry for typos]
Luigi : cumulative distribution function - large majority of the  
entries last until the time out
Luigi : a large number of prefixes are used for short duration flows
Luigi : however, a few flows last for up to 24 hours, which is the  
time interval we used to plot these graphs
Mark : Are these short lived flows a natural property of flow, or  
some sort of scanning
Luigi : I don't know. We have a lot of incoming flows that are just a  
couple of packets
Luigi : each entry of a cache is used to handle traffic
Luigi : what you see is the CDF of the traffic per entry
5:05 PM
Luigi : for 3 minute cache, 99% are used for < 1 MB of traffic
Luigi : there are a few that are used for GB of traffic - mostly  
physicists pulling things
from CERN
Luigi : the lookups in a pull model
Luigi : 500 per minute to 3000 per minute
Luigi : when we receive an encapsulated packet we can glean the  
mapping from the inner and outer addresses
one question about the cache size is: instead of constant timeout  
value, what about some simple adaptation scheme based on usage?
Luigi : when we send a flow or receive a flow and don't have a  
mapping, and then perform a lookup - a full PULL model
Luigi : 1500 lookups at night to 4000 in the day, and up toi 48.74  
Kbps lookup flow for the 3 minute cache
5:10 PM
Luigi : the longer the time out the more likely a flow can find a  
mapping in the cache
Luigi : how does this compare to DNS traffic ?
Luigi : dns lookups outbound
Luigi : 2000 per minute during the night, up to 15,000 per minute  
(also during the night)
Luigi : although the average is greater during the day
Luigi : so, this is more than LISP, and we could use the DNS as a  
mapping system
Luigi : questions ?
Luigi : if you want to run my scripts
Luigi : you can
Dino : CONS is per site queries while DNS is per host queries
DIno : I think that the DNS tree is very wide and flat
Tony : I wanted to high lite a few things
Tony : in doing an ID locator split we are making some trade offs
[e-mail] has left this chat.
Tony : in today's PI world we depend on the routing plane for  
reachability
5:15 PM
Tony : we are trying to compensate for this in moving to a split
Tony : we need to be clear with people and make sure that they know  
that this will not be like PI space today
Tony : a lot of the table growth is due to self-deaggregation, and we  
need to understand better why people do that
Tony : we very much want to be doing analysis on proposals that we do  
have in havd
hand
Tony : I would very much like folks to continue to focus on the  
conceptual level
Tony : this is the IRTF
[e-mail] has left this chat.
Tony : if you are talking about packet formats, you are probably not  
doing research
Dave Meyer : It seems worthwhile to get experience
Tony : I wasn't disputing experience
Dino : Unless you get into the details people misunderstand your  
proposals
Tony : I encourage you to try and keep them at a conceptual level too
Tony : I wanted to talk about meeting next time.
We could change from the Friday of IETF week
[general silence]
Tony : Papers, please
Tony : green sheets, please
Tony : Thanks !
[e-mail] has left this chat.
[e-mail] has left this chat.
5:20 PM
[e-mail] has left this chat.
[e-mail] has left this chat.
[e-mail] has joined this chat.
[e-mail] has left this chat.
[e-mail] has left this chat.
[e-mail] has joined this chat.
[e-mail] has left this chat.
[e-mail] has left this chat.
[e-mail] has left this chat.
[e-mail] has left this chat.
5:25 PM
You left the chat by logging out or being disconnected.

_______________________________________________
RAM mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ram