Subject: Re: [dispatch] dispatch Digest, Vol 36, Issue 5

From: Sohel Khan <[email-masked]>
Date: Mon, 5 Mar 2012 14:21:52 -0800 (PST)

Thank you Dale and Paul.
How about we will study the existing mechanism on loop prevention, recommend any changes needed on existing mechanism, and/or work on a new solution (e.g, SPID sequence.)

Regards,
Sohel Khan

________________________________
 From: "[email-masked]" <[email-masked]>
To: [email-masked] 
Sent: Monday, March 5, 2012 3:00 PM
Subject: dispatch Digest, Vol 36, Issue 5
 
If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to 

https://www.ietf.org/mailman/listinfo/dispatch

Click the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME.  You can set this option
globally for all the list digests you receive at this point.

Send dispatch mailing list submissions to
    [email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
    https://www.ietf.org/mailman/listinfo/dispatch
or, via email, send a message with subject or body 'help' to
    [email-masked]

You can reach the person managing the list at
    [email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of dispatch digest..."

Today's Topics:

   1. Re: Proposal: ESPID Sequence Charter (Worley, Dale R (Dale))

----------------------------------------------------------------------

Message: 1
Date: Mon, 5 Mar 2012 13:04:47 -0500
From: "Worley, Dale R (Dale)" <[email-masked]>
To: Paul Kyzivat <[email-masked]>, "[email-masked]"
    <[email-masked]>
Subject: Re: [dispatch] Proposal: ESPID Sequence Charter
Message-ID:
    <[email-masked]>
    
Content-Type: text/plain; charset="us-ascii"

> From: Paul Kyzivat [[email-masked]]
> 
> I disagree with the concept being proposed here.
> 
> I'm still waiting for an explanation for why the existing mechanisms for
> loop detection aren't sufficient to solve the problem here. But even if
> there is some inadequacy, then it should be solved in general, not just
> for loops through multiple service providers. There is really nothing
> special about loops through SPs.

I'm with Paul here.

The real problem is that the SIP loop-prevention mechanisms often
don't work when network elements:
(1) hide the path the call has traversed
(2) are B2BUAs

One consequence of this is that in many cases a call can loop between
two service providers and not be detected.  But there are many
somewhat more complex situations that also loop.

The proposed charter assumes that the desired anti-looping mechanism
would be some form of list of the service providers that the call has
traversed.

But many of the more complex scenarious would *not* be detected by a
"list of traversed service providers" mechanism (unless it was so
aggressive that it flagged similar, non-looping calls).  Here is one:

Users A and C are served by service provider P.
Users B and D are served by service provider Q.

User B has forwarded his phone to user C.
User C has forwarded his phone to user D.

User A calls user B.  The route of the call is:

A->P->Q->B->Q->P->C->P->Q->D

At D, the call has traversed P three times and has traversed Q three
times.  It has been routed based on three different phone numbers.

If user D's phone rings, this call is valid and should succeed.  If
user D has forwarded his phone to user A, the call is looped and
should fail.

No doubt the problem needs to be solved.  But we need to start by
studing it, and determining a mechanism that works in all the cases
that our customers will shortly be exercising.  The current charter
specifies a mechanism, and that mechanism will not work.

Dale

------------------------------

_______________________________________________
dispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch

End of dispatch Digest, Vol 36, Issue 5
***************************************

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 05 Mar 2012 17:54:14 -0500

On 3/5/12 5:21 PM, Sohel Khan wrote:
> Thank you Dale and Paul.
> How about we will study the existing mechanism on loop prevention,
> recommend any changes needed on existing mechanism, and/or work on a new
> solution (e.g, SPID sequence.)

Sounds good.

If you didn't already know, Hadriel previously submitted something on 
making loop detection work better through SBCs.

	Thanks,
	Paul

> Regards,
> Sohel Khan
> ------------------------------------------------------------------------
> *From:* "[email-masked]" <[email-masked]>
> *To:* [email-masked]
> *Sent:* Monday, March 5, 2012 3:00 PM
> *Subject:* dispatch Digest, Vol 36, Issue 5
>
> [email-masked] <mailto:[email-masked]>
>
> [email-masked] <mailto:[email-masked]>
>
> [email-masked] <mailto:[email-masked]>
>
> From: "Worley, Dale R (Dale)" <[email-masked] <mailto:[email-masked]>>
> To: Paul Kyzivat <[email-masked] <mailto:[email-masked]>>,
> "[email-masked] <mailto:[email-masked]>"
> <[email-masked] <mailto:[email-masked]>>
> <[email-masked]
> <mailto:[email-masked]>>
>
>  > From: Paul Kyzivat [[email-masked] <mailto:[email-masked]>]
>  >
> [email-masked] <mailto:[email-masked]>

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 6 Mar 2012 12:02:52 -0500

> From: Sohel Khan [[email-masked]]
> 
> recommend any changes needed on existing mechanism, and/or work on a
> new solution (e.g, SPID sequence.)

That sounds like a good way to frame the work.

I would recommend phrasing that explains the problem area more
completely.  *We* all know the difficulties we are attempting to
solve, but it would be better to document it.  E.g.,

    Current SIP loop-detection mechanisms do not work effectively in
    large-scale service provider networks as they are now deployed.  For
    example, the use of B2BUAs and topology-hiding techniques often defeat
    loop-detection.

    The purpose of the WG is to study how the existing mechanisms for
    loop detection work in current large-scale service provider
    networks, and to recommend changes (to the networks and/or the
    mechanisms) to provide practical and effective loop detection in
    those networks.

Dale