Subject: Re: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt

From: "Stastny Richard" <[email-masked]>
Date: Thu, 2 Mar 2006 20:41:55 +0100

Folks,
 
I am a bit confused by this draft.
 
>The purpose of this document is to help the IETF community understand 

>   the route architectures being used today in SIP based peering

>   environments and to outline a set of requirements based on the same

>   for discussion within the community

Is this IMS in stealth mode?

The abstract should clearly state:

The purpose of this draft is to help the IETF community understand IMS ..

In particular I have problems with the following para:

"The call is originated at calling party "O", (called the
  "Origination" in this document) and terminates at called party "T"
  (called the "Termination" in this document).  T may be a subscriber,
  contact center, E911 operator etc.  The first hop and the last hop of
  the call in Figure 1 pass through SPs providing L5 (in our case SIP)
  access to the origination and termination and are called Access-O and
  Access-T respectively.  In most cases these SPs will also provide the
  physical access to the origination and termination devices.  The
  Access SP function is not optional.  While a separate Access SP may
  not exist, the function may be absorbed by the corresponding Core SP."

A Core SP ALWAYS needs an Access SP if he is not providing the access 
by itself? In L5?

And then we also have Interconnect SP = Transit

What happened to the SIP Trapeziod?

and may I remember on the req draft

"3.6.2.  Layer 5 Peering

   Layer 5 peering refers to interconnection of two service providers
   for the purposes of SIP signaling.  Note that in the layer 5 peering
   case, there is no intervening network.  That is, for purposes of this
   discussion, there is no such thing as a "Layer 5 Transit Network"."

The next problem I have with section

"5.2.  Addressing

   The type of A-O-R for the termination may also affect what kind of
   address location service is used.  Address location is done typically
   based on the following four characteristics of the termination's AOR.
   In each case, we list the most common address location method used.

   1.  Full E.164: ENUM or SP's local policy may be used.
   2.  E.164 prefixes: SPs local policy is generally used.
   3.  Full A-O-R: This is rarely used for routing in a peering
       environment.
   4.  Domain of A-O-R: DNS SRV or SPs local policy may be used."

Within SPEERMINT only Call Routing Data (CRD) are used

E.164 numbers are not CRD, they are also not A-o-R, 

E.164 numbers are names

so E.164 number is out of scope in SPEERMENT

And IMHO completely off is the idea to introduce
carrier selection within VoIP
 
" For example Equal Access is
   a LEC (Local Exchange Carrier) requirement and an SP operating as an
   LEC may be required to allow the subscriber his/her choice of IXC
   (IntereXchange Carrier) for certain set of calls.  In essence, these
   requirements may affect route policy for peering where the downstream
   peer is chosen based on origination's policy.  In this case, the
   Core-O and Core-T may be one and the same SP who peer through an
   Interconnect SP of the origination's choice."
 
I have an headache
 
Richard

________________________________

Von: Livingood, Jason [mailto:[email-masked]]
Gesendet: Do 02.03.2006 19:33
An: [email-masked]
Betreff: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt

FYI for the WG on this draft.  This is on the tentative agenda at the Dallas meeting (should be finalized shortly).
 
Jason

________________________________

From: Medhavi Bhatia [mailto:[email-masked]] 
Sent: Sunday, February 26, 2006 12:44 AM
To: [email-masked]
Cc: [email-masked]; Livingood, Jason
Subject: I-D draft-bhatia-sip-peering-00.txt

Abstract

   The purpose of this document is to help the IETF community understand

   the route architectures being used today in SIP based peering

   environments and to outline a set of requirements based on the same

   for discussion within the community.

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

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Thu, 2 Mar 2006 17:02:55 -0500

Hi Richard,

Sorry about the headache...
Hopefully my answers below will help :) 
Thanks for the quick read anyway.

Cheers,
Medhavi.

> Is this IMS in stealth mode?

The intent of the draft is to describe what is deployed and the
requirements driving that. We can choose to ignore or accept some of
them based on WG discussion. 

(IMHO - I don't think IMS is deployed anywhere :)

> A Core SP ALWAYS needs an Access SP if he is not providing the access

It says three things: (a) Access SP is mandatory (b) Access SP "may"
provide
physical access (c) Access SP can be absorbed within the Core SP. Maybe
the
language can be improved, but I think we capture the case you are
talking
about - an ASP (Vonage) like scenario!

> What happened to the SIP Trapeziod?

SIP Trapezoid is captured, since the Interconnect SP is optional (first
para on pg 4). 
However, I think there could be a special section devoted to that. Note
that in no way
the draft is supposed to be prescriptive or designed to ignore the
trapezoid. Sorry if it sounds 
confusing -  we can fix that problem...

Also, Note that Inteconnect SPs today don't map to "Transit" as defined
in requirements
draft. 

> The next problem I have with section

I think maybe the draft needs to clarify that Interconnect SP is not the
same as Transit.
We can try to do this if lot of people feel the same and it really
affects the routing
architecture selection (IMHO - it should not have any effect) in the
end.

> so E.164 number is out of scope in SPEERMENT

I am not sure what I need to fix, but we can address it after WG
discussion.

>    Interconnect SP of the origination's choice."

Equal Access gives a headache to anyone dealing with VoIP :). I think it
is good to know what some VoIP SPs are dealing with especially when we
are starting discussions in the WG. As the draft says  in the last para
- it is
possible that this may affect only a minor set of deployments in the
end. Time
will tell. Also, Equal Access is simply an example (I can't promise if
there
are not a host of other scenarios out there).

Thanks,
Medhavi.

> FYI for the WG on this draft.  This is on the tentative agenda at the
Dallas meeting (should
> be finalized shortly).
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.375 / Virus Database: 268.1.1/272 - Release Date:
3/1/2006

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Fri, 3 Mar 2006 11:08:25 -0500

Hi Otmar,

Thanks for comments. I have tried to provide some clarifications below.

-Medhavi.

> -----Original Message-----
> From: Otmar Lendl [mailto:[email-masked]]
> Sent: Friday, March 03, 2006 8:19 AM
> To: [email-masked]
> Subject: Re: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt
> 
> >
> > Network Working Group                                          M.
Bhatia
> > Internet-Draft                                    NexTone
Communications
> > Expires: August 30, 2006                               February 26,
2006
> >
> 
> This draft is quite helpful as it provides clarificatons concerning
the
> terminology and describes some setups.
> 
> Some questions, though:
> 
> > 2.  Terminology
> 
> >       Service Provider (SP): We use the term Service Provider in
this
> >       document to refer to a SIP Service Provider[3].  The
individual
> >       types of SPs are defined below.
> >
> >          Access SP: An SP which acts as the first hop between the
> >          subscriber and the Core SP.
> 
> Is this Access SP role restricted to the SIP layer or is it implied
> that this Access SP also is the layer 3 access provider for "O"?
> 

For purposes of this doc and given the WG scope, the Access SP (if one
exists in the flow) is a L5 (sip aware) SP. The case where there is a
layer 3 SP and is different from the Core SP or Access SP is probably
not worth considering since there is no SIP peering involved between the
Layer 3 SP and the access/core SPs (I also think that in most cases if
the access SP exists, it will exist because it owns the layer 3). Also I
realize that there may not be many access SPs (L5) today, but chances
are that today's Layer 3 SPs will attempt to become tomorrow's Access
SPs.

> > 4.  Routing Architectures
> >
> >    1.  Direct Peering:
> >
> >           Federation: A federation is typically a set of SPs which
are
> >           terminating calls to each other using some well known
> >           mechanisms for settlement, address location and some other
> >           common administrative policies.  In most cases the peering
SPs
> >           are connected to a trusted private network and trust all
calls
> >           terminating on them over this network.
> >
> >              Federations typically use ENUM as the registry database
> >              (owned by the federation or a trusted third party) to
> >              provide address location services and applications like
> >              number portability.  Other aspects of the routing
policy
> >              (as described in Section 5) are implemented using edge
> >              proxies or session border controllers (Section 4.1).
> 
> This use of "Federation" fits in very well with my definition
> of draft-lendl-speermint-federations-00. Good.
> 
> Federations can only use ENUM if routing is based on E.164 numbers.
> If we ever switch to direct URI dialing, then ENUM cannot be used
> within a federation.
> 
> Btw, draft-lendl-domain-policy-ddds-00 provides a solution for
> selecting the right federation for a call and thus enables SPs
> to be part of multiple federations.
> 
> >
> > 5.  Requirements for route policy and architecture for peering
> >
> >    2.  Addressing: Whether the address of record of the termination
is
> >        an E.164 address or a generic AOR (e.g [email-masked])
> 
> IMHO: We should not design a system which does assume that E.164
> numbers are available as routing information.
> 
I'd agree. I am thinking there will be a lot more discussion on how the
presence of E.164 changes the situation (maybe dips into some legacy
system). In practice the access SPs and core SPs may be providing SIP
based access to legacy PSTN. I assume those scenarios are also in scope.

Medhavi.

> /ol
> --
> < Otmar Lendl ([email-masked]) | nic.at Systems Engineer >
> 
3/1/2006