Subject: [Speermint] Access SP was: ( I-D draft-bhatia-sip-peering-00.txt)

From: "Stastny Richard" <[email-masked]>
Date: Fri, 3 Mar 2006 00:20:15 +0100

Hi Medhavi,
 
I think we should discuss the three topics separate
I will respond to the others tomorrow
(not because of the headache ;-), but it is after midnight here already.
 
First I consider your draft very useful, particularly the Figure 1,
and also your definitions,
to clarify the scope and also some issues within SPEERMINT
 
Regarding Access SP, my prime questiion is about your statement:
 
>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 aretalking
>about - an ASP (Vonage) like scenario!

Why is Access SP mandatory and how does it capture the Vonage scenario
We are talking L5 and SIP proxies, or do I misunderstand here something

In IMS there is of course an outbound proxy in the visited (access) network,
with Vonage and others there is not.

Could you please clarify
 
cheers
 
Richard

________________________________

Von: Medhavi Bhatia [mailto:[email-masked]]
Gesendet: Do 02.03.2006 23:02
An: Stastny Richard; Livingood, Jason; [email-masked]
Betreff: RE: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt

Hi Richard,

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

Cheers,
Medhavi.

>
> >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 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 :)

>
> 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?
>

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!

> And then we also have Interconnect SP = Transit
>
> 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.

> 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
>

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.

>
>
> "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
>

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

>
> 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."
>

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.

> 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
>
> --
> 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

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

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Fri, 3 Mar 2006 00:36:16 -0500

Richard,

I believe this is a bug. I have gone through the section 3 and seems
like para 1 (which states access SPs are optional) offers the correct
position. I will need to fix para 2 (acknowledging I probably confused
myself in the earlier reply). Only the Core SPs are mandatory and in the
ASP model, they need to be necessarily different to be in scope of the
WG I believe.

Cheers,
Medhavi.

> -----Original Message-----
> From: Stastny Richard [mailto:[email-masked]]
> Sent: Thursday, March 02, 2006 6:20 PM
> To: Medhavi Bhatia; Livingood, Jason; [email-masked]
> Subject: Access SP was: ( I-D draft-bhatia-sip-peering-00.txt)
> 
> Hi Medhavi,
> 
provide
understand
same
3/1/2006