RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

["Reinaldo Penno" <[e-mail]>]

I guess your translator to/from English must be broken. 

> -----Original Message-----
> From: Stastny Richard [mailto:[e-mail]]
> Sent: Saturday, May 27, 2006 2:55 PM
> To: Reinaldo Penno
> Cc: [e-mail]
> Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture
> 
> What question?
> Richard
> 
> ________________________________
> 
> Von: Reinaldo Penno [mailto:[e-mail]]
> Gesendet: Sa 27.05.2006 23:46
> An: Stastny Richard
> Cc: [e-mail]
> Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture
> 
> 
> 
> Apart form your outside-of-the-us rhetoric the questions remains.
> 
> > -----Original Message-----
> > From: Stastny Richard [mailto:[e-mail]]
> > Sent: Saturday, May 27, 2006 2:38 PM
> > To: Reinaldo Penno
> > Cc: [e-mail]
> > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering
Architecture
> >
> > ENUM issues should not be discussed in SPEERMINT,
> > just some questions
> >
> > >Enum? When I dial [phone], what is there to resolve _inside_
> the
> > >wireless network that owns this number apart from the location of
the
> > >user?
> >
> > and _outside_?
> > ENUM is about numbers like [phone]
> >
> > hello, we are talking E.164 numbers in ENUM, which is international
> > numbers
> >
> > >Now, in the scenario where an external call (for example, a
cingular
> > >customer calling a Verizon customer (which owns an original
t-mobile
> > >number). How that works today? If you say ENUM I would stand
> corrected
> > >(and surprised), since LNP has been fully deployed since 2003.
> >
> > Cingular?Verizon? ...
> >
> > we are talking about a global solution here
> > You are a bit US centric here,
> > there is also some 200 other nations ozt there.
> >
> > I have no access to the US LNP database from e.g. Austria
> >
> > So you want to consider US national databases only in speermint?
> >
> > Richard
> >
> >
> >
> > ________________________________
> >
> > Von: Reinaldo Penno [mailto:[e-mail]]
> > Gesendet: Sa 27.05.2006 21:30
> > An: Stastny Richard; Otmar Lendl
> > Cc: [e-mail]
> > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering
Architecture
> >
> >
> >
> > Enum? When I dial [phone], what is there to resolve _inside_
> the
> > wireless network that owns this number apart from the location of
the
> > user?
> >
> >
> > Now, in the scenario where an external call (for example, a cingular
> > customer calling a Verizon customer (which owns an original t-mobile
> > number). How that works today? If you say ENUM I would stand
corrected
> > (and surprised), since LNP has been fully deployed since 2003.
> >
> > When a user takes its number with them, I assumed this punches a
whole
> > in the telephone prefix hierarchy and a specific entry somewhere is
> > needed.
> >
> > Regards,
> >
> > Reinaldo
> >
> >
> > > -----Original Message-----
> > > From: Stastny Richard [mailto:[e-mail]]
> > > Sent: Saturday, May 27, 2006 4:26 AM
> > > To: Reinaldo Penno; Otmar Lendl
> > > Cc: [e-mail]
> > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering
> Architecture
> > >
> > > >I wonder how
> > > >LNP is solved within wireless...A specific entry for each phone?
> That
> > > >would be crazy.
> > >
> > > Ahem, ENUM?
> > >
> > > I thought that is all what ENUM is about?
> > >
> > > Richard
> > >
> > >
> > > ________________________________
> > >
> > > Von: Reinaldo Penno [mailto:[e-mail]]
> > > Gesendet: Sa 27.05.2006 11:04
> > > An: Otmar Lendl; Patrick Melampy
> > > Cc: Khan, Sohel Q [CTO]; [e-mail]
> > > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering
> Architecture
> > >
> > >
> > >
> > > Hello,
> > >
> > > I believe the crux of the problem was missed.
> > >
> > > The issue is not really the number of domains. We have today some
> > > 400.000.000 million hosts on the Internet. BGP peers to do not
> > exchange
> > > 400.000.000 million routes, they exchange in the low hundreds of
> > > thousands.
> > >
> > > And why is that? (I guess you know where I'm getting at). That's
> > because
> > > IP addresses lend themselves very well to hierarchical deployment,
> > > compression through prefix/CIDR usage and the like. DNS names are
> > > strings and hence difficult to come up with a similar scheme.
> > >
> > >
> > > I believe that if domains need to be exchanged between peers:
> > >
> > > 1 - Just a limited set would be exchanged and a "default layer 5
> > route"
> > > (equivalent to a traditional default route) would be used.
> > >
> > > 2 - Compression schemes like *.company.com, regular expressions or
> the
> > > like would need to be used. Having specific routes to AORs would
be
> > > hairy (maybe for the eventual roaming or visiting user). I wonder
> how
> > > LNP is solved within wireless...A specific entry for each phone?
> That
> > > would be crazy.
> > >
> > > 3 - Some new scheme that will make somebody rich....until then..
> > >
> > > I believe subscriptions would be used to exchange mostly "cost"
and
> > > policy information and some domains. I use cost here in the layer
3
> > > sense (number of calls, jitter, whatever). Cost would be an
abstract
> > > value or a more specific one (up to the administrator).
> > >
> > > Regards,
> > >
> > > Reinaldo
> > >
> > > > -----Original Message-----
> > > > From: Otmar Lendl [mailto:[e-mail]]
> > > > Sent: Saturday, May 27, 2006 1:29 AM
> > > > To: Patrick Melampy
> > > > Cc: 'Khan, Sohel Q [CTO]'; [e-mail]
> > > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering
> > Architecture
> > > >
> > > > On 2006/05/26 18:05, Patrick Melampy <[e-mail]>
> > wrote:
> > > > > I suppose like in any distributed routing protocol, there are
> some
> > > > chicken
> > > > > an egg issues. But consider the following.
> > > > >
> > > > > PREREQUISITES:
> > > > > 1.) You know the destination DOMAIN from either ENUM or other
> > means.
> > > >
> > > > [...]
> > > > >
> > > > > This technique is very similar to TRIP, only its for DOMAINS
and
> > not
> > > > partial
> > > > > E.164 numbers.
> > > >
> > > > [...]
> > > >
> > > > > Obviously, the data set could get large, as the list of
domains
> > can
> > > be
> > > > > really big. There are some possibilities here...
> > > >
> > > > Let's do a quick estimate on the number of domains involved:
> > > >
> > > > Right now, operators usually give customers URIs of the form
> > > > <number>@<providerdomain>. As long as this is the state of
> affairs,
> > > > we're fine as the number of providers is quite finite (a few
> > > > thousands, perhaps).
> > > >
> > > > This is like the state of affairs with respect to email, anno
> 1990.
> > > > Back then customers started to notice that if they use their own
> > > domain
> > > > for email, then they can switch providers without having to
change
> > > > their email address. Thus a *lot* of people opted to use their
> > > > own domain for email.
> > > >
> > > > My guess is that the same will happen to SIP. Once customers
print
> > > > their SIP uris on business cards, they will want to use their
own
> > > > domains. If providers won't support that feature then I suspect
> that
> > > > the regulators will step in and mandate an URI portability
> solution
> > > > just as they did in the PSTN with respect to numbers from number
> > > blocks.
> > > > (This could get really nasty protocol-wise, so I guess using
> > customer-
> > > > owned domains is the far better and likelier solution to the
> porting
> > > > question.)
> > > >
> > > > So: Anything we come up with here in SPEERMINT needs to cope
with
> a
> > > > scenario where the use of customer domains in SIP URIs is just
as
> > > > widespread as it is for email.
> > > >
> > > > How many domains are used for email? That's hard to say. There
are
> > > > about 60 million gTLD domains and probably more than 20 ccTLD
> ones.
> > > > Assuming that only a tenth of that is used for email we're at
> > > > 8 million domains. Given the exponential growth any system which
> > > > doesn't scale to at least 10 million domains will be obsolete
> before
> > > > the ink is dry on the RFC.
> > > >
> > > > So what happens if we do some sort of BGP or TRIP with domains?
> > > >
> > > > Let's say we need at least 100 bytes of state information per
> > domain.
> > > > That makes a full routing table 1 GB worth of data. That also
> means
> > > > that a new border element needs to exchange that amount of data
> > > > with its peers before it has learned the current state of the
> > > > routing table.
> > > >
> > > > That is some serious amount of data.
> > > >
> > > > > 1.) Have notification point to a published document, and the
> > > document
> > > > lists
> > > > > all of the relevant reachability in real time. Thus any change
> to
> > > the
> > > > > document would generate a NOTIFICATION.
> > > >
> > > > + a download of up to 1 GB per peer.
> > > >
> > > > > 2.) User partial domains, broken up by the "dots". This may
> allow
> > > some
> > > > > wildcarding to reduce the number of domains. For instance, a
> > carrier
> > > > like
> > > > > Verizon may have many 100's of domains attached to it, and
> version
> > > is
> > > > > willing to route and manage SIP traffic to any of them. The
> NOTIFY
> > > could
> > > > > contain something like: Verizon.com or *.verizon.com to
indicate
> > > that
> > > > any
> > > > > domain in Verizon is reachable.
> > > >
> > > > That's helpful if a provider uses subdomains for internal
> purposes,
> > > > but that won't help you with customer owned domains.
> > > >
> > > > > This technique may work -- and fit nicely into an existing
> > protocol.
> > > All
> > > > we
> > > > > would need to do is define the data models (XML?) and or
> documents
> > > for
> > > > > exchanging.
> > > >
> > > > I think this technique can work -- if you add an aggregation
step
> > > > before the routing scheme.
> > > >
> > > > Take another look at BGP: there you have the concept of an
> > > > Autonomous System and not only that of prefixes. Maybe you need
> > > > something similar.
> > > >
> > > > One approach to cope with hosted SIP domains could be to use the
> > > > hostnames as found in SRV records. E.g. for settings like
> > > >
> > > > _sip._tcp.customer.domain IN SRV 10 10 5060 sip.provider.com
> > > >
> > > > run the routing algorithm on "sip.provider.com" instead
> > > > of "customer.domain".
> > > >
> > > > Another option is to store some AS-equivalent in the customer
> domain
> > > > and have the routing algorithm operate on that. In my
> domain-policy
> > > > framework this could be expressed e.g. like
> > > >
> > > > customers.domain IN NAPTR 10 10 "u" "D2P+SIP:route-id"
> > > >       "!.*!urn:ietf:speermint:RID:1042!" .
> > > >
> > > > stating that this domain can be reached using the Speermint
> routing
> > > > logic by using the learned route to RoutingID 1042.
> > > >
> > > > Or, even better, use non-terminals, and thus refer to the
ingress
> > > > policy stored in the provider's domain:
> > > >
> > > > customers.domain IN NAPTR "" 10 10 "D2P+SIP" "" provider.com
> > > >
> > > > provider.com. IN NAPTR 10 10 "u" "D2P+SIP:route-id"
> > > >       "!.*!urn:ietf:speermint:RID:1042!" .
> > > >
> > > > (+ whatever other facts provider.com wants to announce about his
> > > > reachability.)
> > > >
> > > > This combination of our ideas can indeed work and scale to an
> > > > unlimited number of customer-owned domains.
> > > >
> > > > /ol
> > > > --
> > > > < Otmar Lendl ([e-mail]) | nic.at Systems Engineer >
> > > >
> > > > _______________________________________________
> > > > Speermint mailing list
> > > > [e-mail]
> > > > https://www1.ietf.org/mailman/listinfo/speermint
> > >
> > > _______________________________________________
> > > Speermint mailing list
> > > [e-mail]
> > > https://www1.ietf.org/mailman/listinfo/speermint

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