Subject: RE: [Speermint] RE: Background Reading on NGN Interconnect-transitvs peering

From: "Reinaldo Penno" <[email-masked]>
Date: Thu, 6 Apr 2006 18:00:13 -0400

> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]]
> Sent: Thursday, April 06, 2006 1:43 PM
> To: Reinaldo Penno; 'Medhavi Bhatia'; 'Otmar Lendl';
[email-masked]
> Subject: RE: [Speermint] RE: Background Reading on NGN Interconnect-
> transitvs peering
> 
> Somehow, we're not communicating.
> 
> Maybe we have to take a step back and see if we agree on the real
basics.
> 
> I believe that when we get right down to it, SPEERMINT is going to
define
> in
> a BCP what a SIP proxy server does to get a call from one domain to
> another
> which is harder than just the normal 3261 interdomain routing
mechanism.
> 
> That's about all we are doing.  It's that simple, but, we all know, it
is
> NOT at all simple.
> 
> If you think we are doing something way beyond that, what is it?
[[Reinaldo]] 

As you said, I think it is NOT that simple.

> 
> If you agree with that, then "peering system" is just the proxy
server(s)
> that do what the BCPs say to get the call from one domain to another.
> 
> So the SIP proxy is at L7.  If that L7 entity tells a router how to
route
> a
> flow (at L3 or worse, sub IP), then you have a layer violation.
[[Reinaldo]] 

I believe this is where we part ways. I see what you mean, but I
interpret it differently. I think routing of the media associated with a
L7 SIP routing decision is also a L7 routing decision since it is all
part of the same call.

> 
> If the SIP proxy server isn't telling the router, what is, and why is
it
> in
> scope?
[[Reinaldo]] 

What I mentioned above is not necessarily in scope. It is also different
from the purpose of the thread which was to make sure architecturally we
keep media in mind.

> 
> This doesn't say you can't have VPN tunnels, or MPLS tunnels, or any
other
> kind of links down in the router.
> 
> This doesn't say you can't mark media packets in some way that sends
them
> down some specific tunnels.
> 
> This doesn't say you can't create any kind of static routing
mechanisms
> you
> like for any set of flows you can identify.
> 
[[Reinaldo]] 

Okay. Identifying flows dynamically and entering static routes by hand
it's not very scalable, thus dynamic decisions based on CRD.

> It does say that SPEERMINT is defining what goes on in the proxy
servers
> that make the L7 call routing decisions.
[[Reinaldo]] 

Anyway, I believe we stretched this topic as much as it goes. You can
have the last word.

regards,

Reinaldo

> 
> Brian
> 
> -----Original Message-----
> From: Reinaldo Penno [mailto:[email-masked]]
> Sent: Thursday, April 06, 2006 4:20 PM
> To: [email-masked]; Medhavi Bhatia; Otmar Lendl; [email-masked]
> Subject: RE: [Speermint] RE: Background Reading on NGN
> Interconnect-transitvs peering
> 
> 
> 
> > -----Original Message-----
> > From: Brian Rosen [mailto:[email-masked]]
> > Sent: Thursday, April 06, 2006 1:00 PM
> > To: Reinaldo Penno; 'Medhavi Bhatia'; 'Otmar Lendl';
> [email-masked]
> > Subject: RE: [Speermint] RE: Background Reading on NGN Interconnect-
> > transitvs peering
> >
> > I remember that bit of the charter, but so far, I don't see how it
> > applies.
> > Sure, the media could take a different L3 path, which might involve
> > different VPN tunnels than the signaling takes.
> >
> > Why would we care?  Routers do this without any assistance.  The
> signaling
> > layer is unaware of any of this.
> >
> > What would be the use case that requires us to focus on the
> interactions
> > between the application layer and the lower layers?
> >
> > It's not that it's out of scope, it's that the differences don't
> matter to
> > SPEERMINT, at least I don't see anything that matters.
> >
> > I can see having peering policy take QoS capability into account.
> What I
> > cannot see is having the peering system itself decide to use a
> mechanism
> > (what mechanism could it be?)
> [[Reinaldo]]
> 
> Is this a decision based on the policies announced by various peers
and
> taken by one device or all devices need to be included in the
decision?
> 
> What is the "peering system"?
> 
>  to send the media a particular way through
> > the
> > underlying network based on it.  That means you may have more than
one
> way
> > to get from A to B, and your choice may depend on what QoS you can
> > maintain
> > across those ways,
> [[Reinaldo]]
> 
> Okay so far.
> 
> but not some mechanism that I don't even know exists
> > that
> > somehow influences the underlying network to take a particular path
> for
> > the
> > media.
> [[Reinaldo]]
> 
> Not sure I follow you here.
> 
> That is a really serious layer violation ("yeah, I know you can
> > take
> > this MPLS tunnel or that MPLS tunnel for any packets from A to B,
but
> I
> > want
> > these here media packets to be sent on that tunnel").
> [[Reinaldo]]
> 
> I definitely do not follow you here. A routing table can be populated
by
> peering with others routers, management systems, as a result of
off-line
> TE tools, manual configuration ("I know that path is better, let me
> direct packets there". Is that human performing a layer violation?)
> 
> Can you elaborate on who is performing the layer violation?
> 
> 
> That is WAY beyond
> > anything I would want to touch any time soon, if at all, not to
> mention
> > there isn't any way I know to do it at all.
> >
> > But then, I'm just one hummer here.
> >
> > Brian
> >
> >
> >
> > -----Original Message-----
> > From: Reinaldo Penno [mailto:[email-masked]]
> > Sent: Thursday, April 06, 2006 3:42 PM
> > To: [email-masked]; Medhavi Bhatia; Otmar Lendl;
[email-masked]
> > Subject: RE: [Speermint] RE: Background Reading on NGN
> > Interconnect-transitvs peering
> >
> >
> >
> > > -----Original Message-----
> > > From: Brian Rosen [mailto:[email-masked]]
> > > Sent: Thursday, April 06, 2006 12:28 PM
> > > To: Reinaldo Penno; 'Medhavi Bhatia'; 'Otmar Lendl';
> > [email-masked]
> > > Subject: RE: [Speermint] RE: Background Reading on NGN
Interconnect-
> > > transitvs peering
> > >
> > > Reinaldo
> > >
> > > The path taken by media either flows from one endpoint to the
other
> > > directly, or it goes through one or more media relays.  The path
> media
> > > takes
> > > is defined by which media relays it must traverse.  I don't think
L3
> > > considerations apply to our work.
> > [[Reinaldo]]
> >
> > Is it? The charter states that
> >
> > "In addition, the working group recognizes that
> > there will be use cases that require SPEERMINT to focus on the
> > interaction between the application layer and lower network
> > layers,"
> >
> > Potentially media could follow a different route than signaling by
> > tunneling (read VPNs) or MPLS. No media relays needed. If these
> > interactions are out of scope, fine.
> >
> > >
> > > I do think there are likely to be pin-hole firewalls that enable
> media
> > > flows, although I don't think we need to discuss these either.
> > >
> > > What in any of our documents would offer different advice
depending
> on
> > the
> > > path the media takes?
> > >
> > > What do we have to take into account?
> > [[Reinaldo]]
> >
> > See above.
> >
> > >
> > > I can imagine a discussion of marking of media.  That could
happen.
> > > I can imagine a discussion of security of media across a peering
> point
> > > which
> > > would deal with key exchange although I'm not sure there is much
we
> > could
> > > agree on that subject yet.
> > [[Reinaldo]]
> >
> > Well, all this related to the path the media will take. If your
"voip
> > peer" will not provide QoS (or even carry media), then you might
want
> to
> > send your media through some other path. Will this the stated in the
> > "peering policy" we will define?
> >
> > But, as I stated, if such interactions are out of scope, I will drop
> the
> > subject.
> >
> > Thanks,
> >
> > Reinaldo
> >
> > >
> > > I don't see much else we need to cover.  Do you?
> > >
> > > Brian
> > >
> > >
> > > -----Original Message-----
> > > From: Reinaldo Penno [mailto:[email-masked]]
> > > Sent: Thursday, April 06, 2006 3:11 PM
> > > To: [email-masked]; Medhavi Bhatia; Otmar Lendl;
> [email-masked]
> > > Subject: RE: [Speermint] RE: Background Reading on NGN
> > > Interconnect-transitvs peering
> > >
> > > I'm not sure the discussion was about media relays. Was it? The
> > > impression I had was that the discussion was about the path taken
by
> > > media when flowing between endpoints.
> > >
> > > From my point of view I see many discussions on SIP signaling and
> > > "signaling only providers" and I worry that we are forgetting to
> take
> > > media into account.
> > >
> > > Regards,
> > >
> > > Reinaldo
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Brian Rosen [mailto:[email-masked]]
> > > > Sent: Thursday, April 06, 2006 11:58 AM
> > > > To: 'Medhavi Bhatia'; Reinaldo Penno; 'Otmar Lendl';
> > > [email-masked]
> > > > Subject: RE: [Speermint] RE: Background Reading on NGN
> Interconnect-
> > > > transitvs peering
> > > >
> > > > I am sorry to be on a campaign to stop arguments that may be
> > > interesting
> > > > and
> > > > amusing to us all, but could someone come up with a scenario in
> > which
> > > any
> > > > of
> > > > our anticipated documents would somehow differentiate between a
> > > peering
> > > > mechanism that had media relays and one that did not?
> > > >
> > > > I think this whole line of discussion is interesting, but
> irrelevant
> > > to
> > > > the
> > > > task at hand.
> > > >
> > > > Peering occurs when a SIP INVITE, most often with an offer SDP
> body,
> > > which
> > > > contains some IP addresses and ports for it's desired media
> > > connections,
> > > > is
> > > > presented to some proxy (a peering proxy which could be within
the
> O
> > > > network, or could be in some special peering network) who is
going
> > to
> > > > determine a proxy in the T network to send the INVITE to.  The
> > > resulting
> > > > 200
> > > > OK message, which most often will have an answer SDP with its
own
> > > media
> > > > addresses and ports may traverse said proxies (if they Record
> > Routed).
> > > >
> > > > WHO CARES what the media address/ports are?
> > > >
> > > > WHO is going to do anything different if they are the
endpoint's,
> an
> > > SBC
> > > > in
> > > > the O-network, T-network or anything else.
> > > >
> > > > Who in the O or T network would care if they were in an SBC
inside
> a
> > > > peering
> > > > service?
> > > >
> > > > We need to think about media, because we have to deal with
pinhole
> > > > firewalls, we have to deal with NAT traversal, and we could
> imagine
> > > > dealing
> > > > with ancillary functions like transcoders, but really folks,
> whether
> > > there
> > > > are media relays anywhere just doesn't seem to matter; you can't
> > tell
> > > if
> > > > there are or there aren't and you don't do anything differently.
> > > >
> > > > Should anyone care, I personally think if systems are properly
> > > designed,
> > > > the
> > > > only media relays in the path pretty that much have to be there
> are
> > > for
> > > > legal intercept, and if we did that correctly (at L3 or below)
> then
> > > even
> > > > they would not be needed and we could get back to the original
> idea
> > > that
> > > > media flows direct between the UAs.  That does not obviate any
> > > firewall
> > > > needs.  I am under no illusions that "properly designed" is
often
> > > > achieved.
> > > > That having been said, lots of folks seem to like media relays,
I
> > hope
> > > > they
> > > > don't screw up when emergency calls are sent through, and we
have
> to
> > > > accept
> > > > that they may be all over the place.  But, again, who cares?
> > > >
> > > > Brian
> > > >
> > > > -----Original Message-----
> > > > From: Medhavi Bhatia [mailto:[email-masked]]
> > > > Sent: Thursday, April 06, 2006 1:38 PM
> > > > To: Reinaldo Penno; Otmar Lendl; [email-masked]
> > > > Subject: RE: [Speermint] RE: Background Reading on NGN
> > > > Interconnect-transitvs peering
> > > >
> > > > Reinaldo,
> > > >
> > > > Do you have an example of an operator doing just media but is
not
> an
> > > L3
> > > > carrier (e.g ISP/Transit)? If not, we can just talk about
> signaling
> > > only
> > > > or signaling and media.
> > > >
> > > > -Medhavi.
> > > >
> > > > > -----Original Message-----
> > > > > From: Reinaldo Penno [mailto:[email-masked]]
> > > > > Sent: Thursday, April 06, 2006 1:02 PM
> > > > > To: Otmar Lendl; [email-masked]
> > > > > Subject: RE: [Speermint] RE: Background Reading on NGN
> > Interconnect
> > > > -transitvs peering
> > > > >
> > > > > Okay, so when coming up with these terms we cannot forget
about
> > > media.
> > > > > So, when somebody provides "peering" and/or "transit"
services,
> we
> > > > need
> > > > > to specify in the context of speermint if that means:
> > > > >
> > > > > a) all IP packets (which includes media)
> > > > > b) only signaling
> > > > > ...
> > > > >
> > > > > Well, you get the idea...
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Otmar Lendl [mailto:[email-masked]]
> > > > > > Sent: Thursday, April 06, 2006 8:44 AM
> > > > > > To: [email-masked]
> > > > > > Subject: Re: [Speermint] RE: Background Reading on NGN
> > > Interconnect
> > > > -
> > > > > > transitvs peering
> > > > > >
> > > > > > On 2006/04/06 17:04, Richard Shockey <[email-masked]>
> wrote:
> > > > > > > Stastny Richard wrote:
> > > > > > > >The problem I have with the FCC definition is that
> > > > > > > >is states that peering is always bi-lateral
> > > > > > > >
> > > > > > > >The major reason for setting up SPEERMINT was that
> > > > > > > >everybody seems at least to agree that bi-lateral
> > > > > > > >peering does not scale globally.
> > > > > > >
> > > > > > > All peering arrangements among IP backbones are bi-lateral
> and
> > > the
> > > > > > Internet
> > > > > > > seems to have scaled reasonably well.
> > > > > >
> > > > > > The reason for that is "transit". It is thus not necessary
> that
> > > > > > any Autonomous Systems peers with all other AS.
> > > > > >
> > > > > > I think we should define the difference between "Peering"
and
> > > > > > "Interconnection" (which in my mind also allows for
transit).
> > > > > >
> > > > > > Bi-lateral peering alone will definitly not solve the
> world-wide
> > > > > > reachability problem.
> > > > > >
> > > > > > /ol
> > > > > > --
> > > > > > < Otmar Lendl ([email-masked]) | nic.at Systems Engineer >
> > > > > >
> > > > > > _______________________________________________
> > > > > > Speermint mailing list
> > > > > > [email-masked]
> > > > > > https://www1.ietf.org/mailman/listinfo/speermint
> > > > >
> > > > > _______________________________________________
> > > > > Speermint mailing list
> > > > > [email-masked]
> > > > > https://www1.ietf.org/mailman/listinfo/speermint
> > > > >
> > > > > --
> > > > > No virus found in this incoming message.
> > > > > Checked by AVG Free Edition.
> > > > > Version: 7.1.385 / Virus Database: 268.3.5/302 - Release Date:
> > > > 4/5/2006
> > > > >
> > > >
> > > > _______________________________________________
> > > > Speermint mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/speermint

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

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 7 Apr 2006 08:00:01 -0400

route
[[Reinaldo]] 

<BR> Perhaps you would care to explain what protocol is doing this and how
it works.  I don't think we are defining new protocols here.  I'm not aware
of any L7 protocol already defined that could reasonably be used to route
media with any more specificity than SIP now does (which ultimately is a
direct path between UAS and UAC).  You seem to be implying that there is an
L7 protocol, not SIP, which some peering element would use to cause media to
flow between the UAS and UAC via some set of ?what? L7 Intermediaries?
Routers? Links? Sub-IP tunnels?  What protocol would that be?

Brian