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

From: "Medhavi Bhatia" <[email-masked]>
Date: Fri, 3 Mar 2006 12:44:09 -0500

> This raises may questions such as:
> if you are able to unbundle your access and are
> able to choose another DSL provider, to you still
> need carrier selection?

My personal opinion is that it may not be not required for the case you
have above. I think for the WG purposes, the solution we come with for
the Interconnect SP problem (in the other thread we have on the WG list)
may also be used to solve this. An Access SP or Core SP which needs to
provide this to the subscriber for whatever reason treats the LD carrier
as an Interconnect SP. The LD Carrier will need to do another lookup to
get to Core-T (which may be same as Core-O in this case). 

> 
> Is carrier selection only valid for voice and voice
> related services, especially if the selected carrier
> still has only access via the PSTN? What if you switch
> during a call to video?
> 
> What does carrier selection imply with IP Interconnect?
> L5 Interconnect or also L3 transit?
> 
> A very nice example is if Core-O and Core-T is the
> same, e.g. running on the same server,
> do you still have to provide carrier selection
> if the call is now forced via the PSTN?
> 

This scenario may exist. I have heard about it as a requirement in some
VoIP deployments.

Medhavi.

> Etc. etc.
> 
> Cheers
> 
> Richard
> 
> 
> 
> > -----Original Message-----
> > From: Medhavi Bhatia [mailto:[email-masked]]
> > Sent: Thursday, March 02, 2006 11:03 PM
> > To: Stastny Richard; Livingood, Jason; [email-masked]
> > Subject: 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
> > >
> 
> --
> 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: "Dolly, Martin C, ALABS" <[email-masked]>
Date: Fri, 3 Mar 2006 12:45:48 -0600

Hello,

If this is a requirement, is it not a regional SDO requirement, and
therefore, should be an input requirement from one of those regional
SDOs?

Cheers,

Martin

> Sent: Friday, March 03, 2006 12:44 PM
> Subject: [Speermint] RE: Equal Access (was
> I-Ddraft-bhatia-sip-peering-00.txt)
> 
>

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 17 Mar 2006 13:28:47 -0500

Wading to the middle here...

It seems to me that we would be wise to think about the ability to specify a
transit network when there needs to be a transit network, and there is more
than one available.  

If I have four networks, A, B1, B2 and C, where the networks peer in more
than one place, then I may have a transit network:
A -(p1)- B1 -(p2)- C
       \    /
         B2

and I may wish to instruct p1 to use either B1 or B2.  I may do that for a
variety of reasons.  

Brian

-----Original Message-----
From: Medhavi Bhatia [mailto:[email-masked]] 
Sent: Friday, March 03, 2006 12:44 PM
To: Stastny Richard; Livingood, Jason; [email-masked]
Subject: [Speermint] RE: Equal Access (was

Medhavi.

"T"
hop
Access-O
provide
Core
of
termination's
as
IXC
the
an
think
we
if
3/1/2006