Subject: RE: [Sigtran] IPSP double exchange mode of operation

From: "PELLAN,HERVE (HP-France,ex1)" <[email-masked]>
Date: Mon, 23 Dec 2002 19:00:49 +0100

Brian,

I would like to conclude on this and define whether this would help to add
some text to the existing RFC as proposed on just leave it as it is. See
comment in line. 

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Wednesday, December 18, 2002 12:56 PM
> To: PELLAN,HERVE (HP-France,ex1)
> Cc: [email-masked]'; Javier Pastor-Balbas (ECE);
> [email-masked]
> Subject: Re: [Sigtran] IPSP double exchange mode of operation
> 
> 
> Herve,
> 
> PELLAN,HERVE (HP-France,ex1) wrote:                           
>                 (Wed, 18 Dec 2002 12:27:27)
> > Hi Sandeep and Brian,
> > 
> > Leaving the RFC as it is is OK for us. 
> > 
> > However, to benefit from people experience on IPSP, I think 
> this would be
> > valuable to add a few comments (in section 4.4.3 ?) on 
> where one might
> > better adapted than the other. All the discussions were 
> about this aspect.
> > The purpose is here not to give rules. The exact text is to 
> be defined but
> > basically the main lines are:
> 
> Clarifications are fine, but there are some problems with the 
> following:
> 
> > 
> > - Single exchange: RK basically consist of <OPC,DPC> i.e. 
> symetric RK.
> 
> All RKs (MTP-SAP bindings) are symmetrical in SS7.  OPC/DPC/SI, even
> OPC/DPC/SI=5/CIC (ISUP binding) is symmetrical in SS7.
> 
> In fact, it would be better to say that in DE all RKs must be made
> symmetrical and must be registered in symmetrical pairs, otherwise
> user parts will be unable to perform their functions.
>

I disagree on that. M3UA do not force you to have symetrical RK. Overall,
the local and remote AS may end-up being symetric but this is not mandatory.
Forcing symetry is a design implementation choice.
 
> > - Dynamic Registration, when used on both end, requires 
> double exchange. 
> 
> Write it the other way: when dynamic registration is used in SE, one
> side should statically configure the routing key and the 
> other dynamically
> register (gee, sounds like the definition of SE).

That's OK for me.

> 
> > - Double exchange: may provide additional flexibility when 
> several AS are
> > located on one peer while corresponding remote AS are 
> spreaded on several
> > ones. Generally speaking, DE is more appropriate with 
> dissymetric RK as OPC
> > may not have to be specified.
> 
> All SS7 RKs are symmetrical: even "PC to anywhere" is 
> symmetrical to "anywhere
> to PC".  Can you provide an example of where an MTP User 
> needs a truly 
> asymmetrical routing key?
> 

As you underlined in the examples on which we discussed, it seems difficult
to specify in 2 lines generic cases where DE/SE would be more appropriate.
Generally speaking, It showed how important is the carefull choice of the
RK. 

So let's conclude this thread with the sole addition of the following text
to RFC section 4.4.3, i.e replace IG section 3.12 from the IG with the sole
text:

3.12 IPSP stuff
3.12.1 Description of the problem

Issue was raised about a possible condition while both peers were using
dynamic registration in Single Exchange.

3.12.2 Text changes to the document

---------
New text: (Section 4.4.3)
---------

"When dynamic registration is used in SE, one side should statically
configure the routing key and the 
other dynamically register." 

Does it sounds Ok?

Best Regards,
Herve

> --brian
> 
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
> 
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 23 Dec 2002 11:35:30 -0700

PELLAN,HERVE,

PELLAN,HERVE (HP-France,ex1) wrote:                                           (Mon, 23 Dec 2002 19:00:49)
> Forcing symetry is a design implementation choice.

MTP requires symmetrical routing keys, so M3UA permitting them is absurd.

> Generally speaking, It showed how important is the carefull choice of the

Can you provide an example of where an MTP User needs a truly asymmetrical
routing key?

> configure the routing key and the other dynamically register." 

Why not just say:

	When dynamic registration is used, one side SHOULD statically
	configure the routing key and the other dynamically register.

Because it is true of DE as well.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 23 Dec 2002 11:35:30 -0700

PELLAN,HERVE,

Why not just say:

--brian

---

From: Tolga Asveren <[email-masked]>
Date: Mon, 23 Dec 2002 12:20:34 -0800 (PST)

Just to underline my opinion, personally I am still
against this change. It seems rather than trying to
standardize things, we are putting all of the
possibilities (regardless how suitable they are) to
the M3UA documents.(just my personal opinion, no
offense)
Below Brian mentioned about absurdity of not symmetric
RKs. I can add some more to this(most of this, I
mentioned before but anyway):
-Is it logical to use  a client server interface for
peer-to-peer relationships? For example what will
happen when PC granularity is used for DE and one user
part becomes unavailable? If the answer is that DUPU
is allowed, this just shows to me that the model is
broken(ASPTM is used fot the SPMC directly connected
and SSNM for the remote nodes, and mixing them for the
same entity does not sound nice to me)So, I would
think PC granularity shouldn't be supported with DE
mode.
-Let's say M3UA stack at one IPSP is congested (and
let's assume we have an ANSI network, where signalling
point congestion is considered)What will happen? Who
will execute congestion procedures? 

User part unavailability/node congestion procedures
are executed by the local MTP3 logic(unlike
availability/unavailabity), so if one separates MTP3
logic to a separate node (which is the case with DE),
it is easy to create unfriendly scenarios.

-Is it possible to bring relaying functionality to
this model?One could argue, IPSP is supposed to
support only peer-to-peer mode but I think, it also
could be nice to have as few models as possible (one
for client/server and one for peer-to-peer
relationships), which are well-defined and don't have
architectural problems.

As I said at the very beginning, just my 2 cents....

    Tolga
>                          (Mon, 23 Dec 2002 19:00:49)
> > 
> > Brian,
> > 

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sun, 29 Dec 2002 13:07:20 -0700

HERVE,

[snip]
> configure the routing key and the other dynamically register." 

Actually, there is no need to "statically" configure RKs.  The point
is that one side registers.  This is the same for DE: each RK is
registered by one side.  So something like:

  "When dynamic registration is used, one side SHOULD dynamically
   register."

Which seems rather trivial.

So, let's just strike the whole section.

--brian