Subject: RE: [Speermint] Basic Peering Requirements

From: "Jean-Francois Mule" <[email-masked]>
Date: Thu, 5 Oct 2006 21:45:17 -0600

Thanks for the follow-up Daryl. Posting to the list is always preferred
as far as I am concerned, especially when I'm traveling.

We discussed this during our interim meeting. To clarify the intent of
such a list, the idea is to capture the list of things that may be
discussed between 2 peers in the form of a template in an appendix of
the requirement document. This suggestion was made by Tom Creighton.

This proposal would help:
	1. capture things that are out of scope outside the main
requirement document, yet keep on being raised like billing, IP
transport independency, federation membership or 'policies'
	2. help put some context and possibly requirements for the
federation text in draft-terminology-draft 6 and Otmar's
I-D.lendl-domain-policy-ddds 

Jean-Francois.

> -----Original Message-----
> From: Daryl Malas [mailto:[email-masked]]
> Sent: Thursday, October 05, 2006 4:38 PM
> To: [email-masked]
> Subject: [Speermint] Basic Peering Requirements
> 
> I was asked at the interim meeting to put together a list of base-
> level
> peering requirements by Jean-francois.  I put together a list and
> tried
> to send it to him, but I'm not sure it ever made it.  In either case,
> I
> wanted to post it to the list, so the WG will have ample time to
> pummel
> it before San Diego. ;-)
> 
> ----------------------------------------------------------------------
> 
> Jean-Francois,
> 
> Per our conversation in Philadelphia, I have compiled a list of basic
> peering requirements from one operators perspective.  I can post these
> to the list if you would like.  Here is a list of peering requirements
> (this is certainly not exhaustive, but is a platform):
> 
> Transport (Layer 1  3):
> 
> Peering must utilize IP as the primary mechanism for peering.
> 
> A federation must agree upon a common mechanism for IP transport
> either
> private (e.g. IPVPN, IPSEC, etc.) or public.
> 
> (Net of this...most operators will peer with these methods today.)
> 
> Billing:
> 
> If peering services involve billing, the peers or federation must
> agree
> on a common monetary policy.
> 
> The peers or federation must agree on a common currency.
> 
> (Net of this...some customers may abuse peering, and operators may
> want
> to bill for certain traffic pattern types (e.g. Layer 3 IP Peering
> Leaches).)
> 
> Policy:
> 
> Policies may be implemented locally to the peer or via a centralized
> mechanism within the federation.
> 
> Local policies should be disclosed when creating direct peering
> relationships with the applicable direct peer.
> 
> Local policies may supersede centralized federation policies.
> 
> (Net of this...some peering relationships will be 1:1, so policies
> will
> likely be local only.  Some peering relationships will be 1:N, so
> policies will likely be implemented within DNS or some centralized
> mechanism.)
> 
> Membership:
> 
> A peer may be a member of multiple federations
> 
> A peer must maintain compliancy for policies as defined by each
> federation the peer is a member of.
> 
> If a peer is providing connectivity to multiple federations, it should
> disclose AoRs providing indirect peering relationships to servicing
> peers or federations.
> 
> Peers providing indirect peering must enforce federation policies on
> behalf of the destination federation.
> 
> A peer providing indirect peering may enforce undisclosed policies for
> processing session requests between federations.
> 
> (Net of this...some peers will only desire to be part of a single
> federation, where wholesale carriers will likely be members of
> multiple
> federations.)
> 
> Media:
> 
> Peers must agree on one or more CODECs, which is either negotiated
> directly or via a transcoding mechanism.
> 
> A transcoding mechanism may exist locally or centralized within the
> federation.
> 
> (Net of this...most operators only support a couple of CODECs across
> the
> core of their network, but will transcode at the edge.)
> 
> Routing:
> 
> A peer must utilize the centralized federation routing mechanism if it
> is available.
> 
> A peer allowing another peer within a federation to provide indirect
> peering on their behalf must select only one indirect peer to host
> their
> AoRs.
> 
> A peer must not copy routing information from or make assumed routing
> choices on behalf of the centralized routing mechanism for use locally
> unless it takes place through standard caching methods.
> 
> A common API must be utilized and available for subscriber and route
> provisioning on any centralized federation location function.
> 
> Subscriber and routing information must be dynamically updated as soon
> as applicable for accurate routing within the federation.
> 
> (Net of this...In small peering (e.g. 1:1), a REDIRECT model is simple
> and not too inefficient.  In a larger peering scenario (e.g. 1:N), a
> more efficient method is absolutely necessary, in comes
ENUM/DNS/NAPTR.
> Unfortunately, both methods will likely be necessary until wider
> spread
> adoption of DNS methods takes place.)
> 
> Performance:
> 
> Performance metrics must be shared between peers as they apply
> directly
> to peering signaling and media on a consistent basis within the
> federation.
> 
> (Net of this...this is just a reality otherwise; finger pointing takes
> place anytime something breaks.)
> 
> 
> _______________________________________________
> 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: Daryl Malas <[email-masked]>
Date: Fri, 06 Oct 2006 09:23:05 -0600

Okay, so everything in this list would be discussed during the
negotiation between 2 peers.  The answers to these requirements or
discussion points might differ based on Operator; however, the same
basic requirements will likely need to be met.  I apologize if I
duplicated any, which are already in the requirements document.  I was
trying to think through the peering negotiation (business arrangement)
process, while detailing each of the sticking points along the way.

To be specific, policies in this list are at a very basic level.  Here's
the only list of policies I see being discussed at this time (feel free
to add or subtract as you feel necessary):

1.  Only 'X' CODEC(s) will be supported into federation B or Peer A's
network.
2.  Only 'n' number of peering sessions will be allowed at any given
time.
3.  Peer A will only support these 'X' SIP headers and methods
(extensions) via peering requests (In other words an Operator may not
support Redirect in and out of a federation...it's simply an example.)
--This one brings up an interesting aspect.  It might be noted a UAC
could send an OPTIONS message to a federation or peer to understand some
of these supported "aspects", but these will also likely be negotiated
up front.

These can be enforced at the federation level or via local policies.

--Daryl

---

From: "Uzelac, Adam" <[email-masked]>
Date: Fri, 6 Oct 2006 11:30:12 -0400

A some thoughts here....

I would add to number 2, or create a new entry for:
'x' number of sessions per second transaction rate.  This policy is
implemented to protect the peering point from mass call events,
malicious or "American Idol" style.

With regards to your point about being enforced at the federation level
- I could see mandates around codec and SIP headers at a federation
level, but I am not so sure about limits on concurrent sessions and
transaction rates.  That is purely local policy believe.

-AU

-----Original Message-----
From: Daryl Malas [mailto:[email-masked]] 
Sent: Friday, October 06, 2006 11:23 AM
To: Jean-Francois Mule
Cc: [email-masked]
Subject: RE: [Speermint] Basic Peering Requirements

--Daryl

On Thu, 2006-10-05 at 21:45 -0600, Jean-Francois Mule wrote:
> Thanks for the follow-up Daryl. Posting to the list is always 
> preferred as far as I am concerned, especially when I'm traveling.
> 

> 	1. capture things that are out of scope outside the main
requirement 
> document, yet keep on being raised like billing, IP transport 
> independency, federation membership or 'policies'
federation 
> text in draft-terminology-draft 6 and Otmar's 
> > level peering requirements by Jean-francois.  I put together a list 
> > and tried to send it to him, but I'm not sure it ever made it.  In 
> > either case, I wanted to post it to the list, so the WG will have 
> > ample time to pummel it before San Diego. ;-)
> > 
> > Per our conversation in Philadelphia, I have compiled a list of 
> > basic peering requirements from one operators perspective.  I can 
> > post these to the list if you would like.  Here is a list of peering

> > requirements (this is certainly not exhaustive, but is a platform):
> > 
> > Transport (Layer 1  3):
> > 
> > either private (e.g. IPVPN, IPSEC, etc.) or public.
> > 
> > agree on a common monetary policy.
> > 
> > want to bill for certain traffic pattern types (e.g. Layer 3 IP 
> > Peering
> > Leaches).)
> > 
> > Policy:
> > 

> > will likely be local only.  Some peering relationships will be 1:N, 
> > so policies will likely be implemented within DNS or some 
> > centralized
> > mechanism.)
> > 
> > Membership:
> > 
> > If a peer is providing connectivity to multiple federations, it 
> > should disclose AoRs providing indirect peering relationships to 
> > servicing peers or federations.
> > 

> > A peer providing indirect peering may enforce undisclosed policies 
> > for processing session requests between federations.
> > 

> > the core of their network, but will transcode at the edge.)
> > 
> > Routing:
> > 
> > A peer must utilize the centralized federation routing mechanism if 
> > it is available.
> > 

> > their AoRs.
> > A peer must not copy routing information from or make assumed 
> > routing choices on behalf of the centralized routing mechanism for 
> > use locally unless it takes place through standard caching methods.
> > 

> > Subscriber and routing information must be dynamically updated as 
> > soon as applicable for accurate routing within the federation.
> > 
> > (Net of this...In small peering (e.g. 1:1), a REDIRECT model is 
> > simple and not too inefficient.  In a larger peering scenario (e.g. 
> > 1:N), a more efficient method is absolutely necessary, in comes
> ENUM/DNS/NAPTR.
> > spread adoption of DNS methods takes place.)
> > 
> > Performance:
> > 
> > directly to peering signaling and media on a consistent basis within

> > the federation.
> > 
> > (Net of this...this is just a reality otherwise; finger pointing 
> > takes place anytime something breaks.)
> > 
> >

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 12 Oct 2006 14:19:27 -0400

I've been thinking about this thread and while there are some conversation
starters here, I wonder how really relevant a lot of this is.  Maybe
"relevant" is the wrong word, but I mean how much time and effort (and words
in a document) do we give it.

Generally speaking, the IETF designs protocols.  In this work, we are
probably not going to do that, we're going to do "Best Current Practice"
documents.  In the IETF, those are mostly "how best do you use the protocols
the IETF defined, for a specific task".

Generally speaking, IETF documents don't describe what would be in a
contract between peers or between a peer and a federation.  It is all well
and good, and in fact I enthusiastically agree that the resolution of the
codec discussion is that "The federation defines a codec policy to which all
peers must adhere which would include designation of one or more mandatory
to deploy codec and/or local transcode capability for each supported media
type (audio, video, text) so that all calls can successfully complete
offer/answer exchange.  Consideration should be given in specifying
mandatory-to-deploy codecs to include at least one that has minimal
degradation of signal fidelity when two transcodes are required to achieve
actual end to end compatibility."

But, is that all?  I think so.  So, yeah, we have to say that, but that is
all we do, because the actual work is in a contract.

In your list, I think most of the items have that characteristic.

I'm expecting our BCP documents will cover all of the items you listed, but
I think they are really tiny pieces of text, and amount to a description of
what's in the contract.

We need to spend more IETF time, and words, on the protocol mechanisms, and
how they are used.  That should be the bulk of our work.

Brian

---

From: Daryl Malas <[email-masked]>
Date: Thu, 12 Oct 2006 15:07:23 -0600

I think the best use of this information is to help us keep our feet on
the ground as we develop the protocol aspects of peering.  As you
remember in Philly (and, I'm just as guilty) we kept going off onto
tangents of "nice-to-haves".  We decided it was critical to stay focused
on the core (basic) aspects of peering.  This list was intended to be a
start at identifying the basic framework of peering, which we must start
by defining protocol aspects within.  After this is completed, over
time, extensions can be written identifying new innovative aspects of
peering.

This was my perception of the request...

--Daryl