Subject: RE: [Speermint] RE: Background Reading on NGNInterconnect-transitvspeering

From: "Malas, Daryl" <[email-masked]>
Date: Thu, 6 Apr 2006 14:39:57 -0600

So, if we don't differentiate, then we need to simplify; otherwise, I
think we will have a difficult time ever reaching consensus.

--Daryl M.

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Thursday, April 06, 2006 2:04 PM
To: Malas, Daryl; 'Reinaldo Penno'; 'Medhavi Bhatia'; 'Otmar Lendl';
[email-masked]
Subject: RE: [Speermint] RE: Background Reading on
NGNInterconnect-transitvspeering

What doesn't make sense to me is listing categories of peering that
don't
have any different behavior specified in our documents.  It's all nice
and
warm to note that there are public and private peering arrangements, but
unless we do something different for them, why do we need to even define
them?  I'd hate to try to define the difference between "Carrier
Peering"
and "Private Peering" for example. 

The easiest thing to do is to not differentiate! 

Brian

-----Original Message-----
From: Malas, Daryl [mailto:[email-masked]] 
Sent: Thursday, April 06, 2006 3:49 PM
To: Reinaldo Penno; [email-masked]; Medhavi Bhatia; Otmar Lendl;
[email-masked]
Subject: RE: [Speermint] RE: Background Reading on
NGNInterconnect-transitvspeering

I think we can simplify these discussions by specifying the policies
relative to unique peering environments.  As I discussed before, can we
classify the peering environments into categories such as:

Public peering - 
	1.  Create Definition
	2.  Define policies
	3.  Develop use cases

Private peering -
	1.  <Similar to above>

Carrier peering -
	1. <Again, similar to above>

Any others??? -

I think the majority of the ambiguity is created from the varying
perspectives on peering.  The 3 categories listed above are simply my
guess to the most common perspectives in this WG.  With each, we can
tackle the various L3 and L5 issues, but at least we can maintain the
conversation within the framework of the specified peering environment.
I think this will eliminate some of the ambiguity.

Make sense?

--Daryl M.
-----Original Message-----
From: Reinaldo Penno [mailto:[email-masked]] 
Sent: Thursday, April 06, 2006 1:42 PM
To: [email-masked]; Medhavi Bhatia; Otmar Lendl; [email-masked]
Subject: RE: [Speermint] RE: Background Reading on
NGNInterconnect-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

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