Subject: Re: [Fwd: Re: IPSP proposed text (1st approach)]]

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 6 Nov 2001 07:57:01 -0600

Javier,

Javier Pastor-Balbas (ECE) wrote:                          (Tue, 06 Nov 2001 14:37:52)
> Brian, 
> 
> I see you change your model of doing things everytime...

The model is the same, you view is what is changing...

> That is not serious and only confuses people.

I can only take this to meant that it confuses you.  But,
most people ask questions when they are confused rather than
making wild assertions, so, are you confused?

> Please, if you have a model for ASP-ASP communication, then
> send it out to be discussed. In the meantime, only one complete
> model has been shown.

The single-ended model already exists in the draft and is the
only one shown completely.  Everywhere IPSP is mentioned in the
draft it speaks to the single-ended model.

Your half-hearted double-ended model has a number of questions
and concerns surrounding it which have not been addressed in
any coherent proposal.  Even your "first approach" shows strange
labelling of in messages (what is an LRC?) and does not address
double RCs in DATA (or how to determine originating AS) and requires
RK management and tables in ASPs (which are not present in AS/SG)
and keeps shifting from registering local RKs to registering
remote RKs.  Why does the DE model keep changing?

But worst off it always speaks to two RCs where one will do (and
only one is described in the draft) and two messages (where all
IPSP examples in the current draft show one).

I'm afraid you will have to show a coherent proposal before the
draft is changed from its current signle-ended IPSP approach.

--brian

> 
> See more comments below...
> 
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: Tuesday, November 06, 2001 2:31 PM
> > To: Javier Pastor-Balbas (ECE)
> > Cc: sigtran
> > Subject: Re: [Fwd: Re: IPSP proposed text (1st approach)]]
> > 
> > 
> > Javier,
> > 
> > Javier Pastor-Balbas (ECE) wrote:                          
> > (Tue, 06 Nov 2001 14:22:24)
> > > Brian...
> > > 
> > > > -----Original Message-----
> > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > Sent: Tuesday, November 06, 2001 1:05 PM
> > > > To: sigtran
> > > > Cc: [email-masked]
> > > > Subject: Re: [Fwd: Re: IPSP proposed text (1st approach)]]
> > > > 
> > > > 
> > > > Javier,
> > > > 
> > > > Javier Pastor-Balbas (ECE) wrote:                          
> > > > (Tue, 06 Nov 2001 12:55:23)
> > > > > Brian, 
> > > > > 
> > > > > Only one comment. You misinterpreted my answer....
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > > Sent: Tuesday, November 06, 2001 12:50 PM
> > > > > > To: Javier Pastor-Balbas (ECE)
> > > > > > Cc: sigtran
> > > > > > Subject: Re: [Fwd: Re: IPSP proposed text (1st approach)]]
> > > > > > 
> > > > > > 
> > > > > > Javier,
> > > > > > 
> > > > > > Javier Pastor-Balbas (ECE) wrote:                          
> > > > > > (Tue, 06 Nov 2001 12:35:05)
> > > > > > > 
> > > > > > > 
> > > > > > > > -----Original Message-----
> > > > > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > > > > Sent: Tuesday, November 06, 2001 12:21 PM
> > > > > > > > To: sigtran
> > > > > > > > Cc: [email-masked]
> > > > > > > > Subject: Re: [Fwd: Re: IPSP proposed text (1st approach)]]
> > > > > > > > 
> > > > > > > > 
> > > > > > > > Javier,
> > > > > > > > 
> > > > > > > > Javier Pastor-Balbas (ECE) wrote:                 
> >          
> > > > > > > > (Tue, 06 Nov 2001 11:57:41)
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: Brian F. G. Bidulock 
> > [mailto:[email-masked]]
> > > > > > > > > > Sent: Tuesday, November 06, 2001 11:39 AM
> > > > > > > > > > To: sigtran
> > > > > > > > > > Cc: [email-masked]
> > > > > > > > > > Subject: Re: [Fwd: Re: IPSP proposed text 
> > (1st approach)]]
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > Javier,
> > > > > > > > > > 
> > > > > > > > > > Javier Pastor-Balbas (ECE) wrote:                 
> > > >          
> > > > > > > > > > (Tue, 06 Nov 2001 11:22:13)
> > > > > > > > > > > 
> > > > > > > > > > > (snip)
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Solve me this example where ASP1 and ASP2 
> > > > belongs to 
> > > > > > > > > > > > different operators
> > > > > > > > > > > > > with no communications between them and with 
> > > > > > prefixed RC=3:
> > > > > > > > > > > > 
> > > > > > > > > > > > > ASP1------ASP2-------ASP3, ASP2 can obtain two 
> > > > > > RC from ASP1 
> > > > > > > > > > > > and ASP3 that
> > > > > > > > > > > > > are the same value.
> > > > > > > > > > > > 
> > > > > > > > > > > > So can DE.  ASP2 is not in control of the RC that 
> > > > > > either ASP1
> > > > > > > > > > > > or ASP3 provide it.
> > > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > In my proposal (call it whatever) It is ASP2 
> > > > the one who 
> > > > > > > > > > decides what RC
> > > > > > > > > > > gives to ASP1 and ASP3 and ASP2 assures that 
> > > > both RCs are 
> > > > > > > > > > different. There's
> > > > > > > > > > > no need of previous ASP1-ASP3 communication.
> > > > > > > > > > 
> > > > > > > > > > But you need two RC values in DE.  One is assigned by 
> > > > > > > > ASP1 and another
> > > > > > > > > > assigned by ASP3.  They can be the same 
> > without ASP1-ASP3 
> > > > > > > > > > communication.
> > > > > > > > > > Same situation in DE.
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > The RC (RC23) that is assigned to the RK 
> > register by ASP2 
> > > > > > > > in ASP3 (call it
> > > > > > > > > RK23) is the index in ASP3 table of the RK23. When the 
> > > > > > > > application part in
> > > > > > > > > ASP3 wants to send a msg to ASP2, it will 
> > perform a search 
> > > > > > > > in its Routing
> > > > > > > > > Table where all the RCx3 are unique as well, 
> > because ASP3 
> > > > > > > > assures that all
> > > > > > > > > RCx3 are unique since it assign them to each new AS 
> > > > > > that wants to
> > > > > > > > > communicate to ASP3.
> > > > > > > > > 
> > > > > > > > > What each ASP needs to do is finding the unique 
> > RC that it 
> > > > > > > > gave to the peer
> > > > > > > > > to identify the peer AS in order to the peer ASP to 
> > > > > > > > differenciate what AS
> > > > > > > > > the message is for.
> > > > > > > > 
> > > > > > > > There is no need.  When an ASP registers with multiple 
> > > > > > SGs it gets the
> > > > > > > > can get the same RC value back from both SG for different 
> > > > > > > > routing keys.
> > > > > > > 
> > > > > > > Yes, but inside the SGP you have RC unicity.
> > > > > > 
> > > > > > It is not necessary.  The SGP can handle separate RK tables
> > > > > > per association.
> > > > > 
> > > > > How can you know what association routing table you have to 
> > > > use with only
> > > > > the routing parameters that you have receive from the SS7 
> > > > part? First find
> > > > > RK -> RC/AS -> ASP -> association
> > > > > 
> > > > > This is the only possible order.
> > > > 
> > > > RK -> ASP/Assoc -> RC/AS.
> > > 
> > > How do you know that an ASP serves the AS the message was 
> > for ?? There is no
> > > a 1:1 relationship between RK and ASP. Wrong order.
> > 
> > But there is 1:1 between RK and AS.  If the ASP serves the RK 
> > it serves
> > the AS.  Thus I can go RK --> ASP/Assoc.
> > 
> > Or even RK -> AS -> ASP/Assoc -> RC.
> > 
> > > 
> > > First thing you have to do is find the AS you are 
> > communicating with. After
> > > that select from the list of ASPs that serves that AS, one 
> > that is active.
> > 
> > Wel no.  I can get a list of ASP that are registered/configured for
> > the RK (which is the same thing as the AS), determine which one is
> > active for the RK/AS, find the association, and then determine the
> > value of RC to use for that AS on that association.  Big deal.
> > 
> > --brian
> > 
> 
> 
> Once you have RK you have the three: RK/RC/AS  (1:1:1 relationship). You only need to get an active ASP from the list of those serving the AS.
> 
> Cheers // Javier.
> 
> 
> > 
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > In the same way in IPSP, an ASP can get RC that are related 
> > > > > > to its local RK
> > > > > > > that are the same. But those RC are used only for msg 
> > > > > > distribution, and you
> > > > > > > can start searching by the Association Id in that case, 
> > > > > > since you have the
> > > > > > > association the mesg came from.
> > > > > > 
> > > > > > The same is true for SGP at the other end.  It can 
> > have separate
> > > > > > RK table per association.  It does not matter if the index for
> > > > > > one RK table is the same as another.  They are 
> > distinguished by
> > > > > > association.  Big deal.
> > > > > > 
> > > > > 
> > > > > Brian, I was talking about sending a msg from the SGP to 
> > > > ASP. There is no
> > > > > association information until you get it from the RK/RC/AS... 
> > > > 
> > > > RK -> ASP/Assoc -> RC/AS.
> > > 
> > > Same as before .... 
> > > 
> > > 
> > > Cheers // Javier.
> > > 
> > > 
> > > > 
> > > > --brian
> > > > 
> > > > 
> > > > > 
> > > > > Cheers // Javier.
> > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > > The RC value is a local thing that pertains only to the 
> > > > > > entity that is
> > > > > > > > providing it. 
> > > > > > > 
> > > > > > > RC belongs to both, but it is a reference of the RK that 
> > > > > > belongs to the
> > > > > > > entity that is providing it.
> > > > > > 
> > > > > > For the association over which it is exchanged.
> > > > > > 
> > > > > > > 
> > > > > > > > When you consider that IPSPs are performing SG routing
> > > > > > > > functions, it is not a stretch for the ASP to receive 
> > > > > > > > different RC values
> > > > > > > > for the same routing key from different IPSPs.  
> > There is no 
> > > > > > > > problem here.
> > > > > > > > It fits the data model for the ASP just fine.  SE will do.
> > > > > > > > 
> > > > > > > > --brian
> > > > > > > > 
> > > > > > > 
> > > > > > > The RC is an index to the RKs table (also called routing 
> > > > > > table) and the SGP
> > > > > > > needs to have the 1:1:1 relationship.
> > > > > > 
> > > > > > At an SGP for a given ASP.  Anything more is unnecessary.
> > > > > > 
> > > > > > > When an ASP sends a msg to the remote peer it has to behave 
> > > > > > in the same way
> > > > > > > SGP do.
> > > > > > 
> > > > > > SGP are permitted to give out the same RC values on different 
> > > > > > associations
> > > > > > to different ASPs for different RKs.  They can do this today.
> > > > > > 
> > > > > > > In that way upon the reception of the message by the peer 
> > > > > > ASP it will behave
> > > > > > > as ASP does in the SG-AS model. With the existing model in 
> > > > > > M3UA everything
> > > > > > > works fine.
> > > > > > 
> > > > > > Gee, you are so worried about making an IPSP *be* an 
> > ASP, yet act
> > > > > > like an SGP.  Get rid of the ASP and just make the 
> > IPSP an SGP.
> > > > > > IPSP is just SGPs talking peer-to-peer.  This is 
> > consistent with
> > > > > > the SIGTRAN architecture.  An IPSP is an SG/SGP.
> > > > > > 
> > > > > > If you want to distribute a bunch of ASs, distribute them on
> > > > > > ASP on the back-end per the SIGTRAN architecture and 
> > have them 
> > > > > > talk to the IPSPs as SGPs.
> > > > > > 
> > > > > > --brian
> > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > Cheers // Javier.
> > > > > > > 
> > > > > > > 
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > Your proposal can not solve it without ASP1-ASP3 
> > > > > > > > > > communication. And that
> > > > > > > > > > > communication can be impossible if we are 
> > talking of 
> > > > > > > > > > different operators...
> > > > > > > > > > 
> > > > > > > > > > Your proposal does not solve it either.
> > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > > > In that case another characteristic of  RC 
> > > > (index of RK
> > > > > > > > > > > > > table) has been aniquilated.
> > > > > > > > > > > > 
> > > > > > > > > > > > No difference SE to DE here.  It is still an 
> > > > > > index into the
> > > > > > > > > > > > RK table, one is the index into the RK table 
> > > > for ASP1, the
> > > > > > > > > > > > other is the index into the RK table for ASP2.  
> > > > > > RKs and RCs
> > > > > > > > > > > > are acquired on a per-association basis.  
> > > > This is true for
> > > > > > > > > > > > AS/SG as well.
> > > > > > > > > > > > 
> > > > > > > > > > > > Example SGP1(SG1)---ASP2---SGP3(SG2).  Again the 
> > > > > > ASP is not
> > > > > > > > > > > > in control of the RC value provided it.
> > > > > > > > > > > > 
> > > > > > > > > > > > Also for, SGP1---ASP2---SGP2.  There is noting 
> > > > > > stopping SGP1
> > > > > > > > > > > > from returning the same RC value as SGP2 (it even 
> > > > > > SHOULD for
> > > > > > > > > > > > the same RK).
> > > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > Let's focus in that example. There is a big 
> > difference 
> > > > > > > > > > here. At SGP there
> > > > > > > > > > > are not more than one RC with the same value. 
> > > > SGP needs to 
> > > > > > > > > > have this unicity
> > > > > > > > > > > since it is using RC/RK/AS table to route 
> > > > towards the right 
> > > > > > > > > > AS. When SGP is
> > > > > > > > > > > sending a message to an AS it looks at the 
> > addressing 
> > > > > > > > > > information and match
> > > > > > > > > > > a RK. That RK has associated an AS and that 
> > AS a RC. 
> > > > > > > > > > Afterthat, it can send
> > > > > > > > > > > out the message to the right IP address.
> > > > > > > > > > > 
> > > > > > > > > > > ASP is only using the receiving RC (optionally) 
> > > > to pass the 
> > > > > > > > > > message to the
> > > > > > > > > > > right AS and it can do it by association. 
> > When an ASP 
> > > > > > > > > > receives a mesg it
> > > > > > > > > > > gets the AS from both inputs RC and association 
> > > > identifier 
> > > > > > > > > > (in the case it
> > > > > > > > > > > serves more than one AS).
> > > > > > > > > > > 
> > > > > > > > > > > As you see there are different tables for different 
> > > > > > purposes.
> > > > > > > > > > > 
> > > > > > > > > > > > For double ended:  ASP1---ASP2---ASP3  The RC 
> > > > is an index
> > > > > > > > > > > > into the ASP1 RK table and that index can be 
> > > > the same as
> > > > > > > > > > > > the index into ASP3's RK table.
> > > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > In my proposal the RC is an index into the 
> > > > Routing table 
> > > > > > > > > > ASP has as M3UA
> > > > > > > > > > > draft says. 
> > > > > > > > > > 
> > > > > > > > > > The draft says for the SGP.
> > > > > > > > > 
> > > > > > > > > Yes, when you send a message to an ASP. Same case.
> > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > The work ASP sends a message to another ASP has 
> > > > to work in 
> > > > > > > > > > the same way it
> > > > > > > > > > > works when an SG sends a message to an ASP. 
> > From the 
> > > > > > > > > > information given by
> > > > > > > > > > > the user part to send a message to the M3UA 
> > layer, M3UA 
> > > > > > > > > > will find a RK
> > > > > > > > > > > associated with an unique RC associated with a 
> > > > unique AS 
> > > > > > > > > > associated with and
> > > > > > > > > > > Association Id. RC in the Routing Table is 
> > unique since 
> > > > > > > > > > although ASP1 and
> > > > > > > > > > > ASP3 don't have communication between them, 
> > > > it's ASP2 the 
> > > > > > > > > > one who assigns
> > > > > > > > > > > the RC for their RK. And these are the unique 
> > > > RC that ASP 
> > > > > > > > > > sends to the peer
> > > > > > > > > > > ASP along with DATA. The table keeps the 
> > consistency of 
> > > > > > > > > > RK-RC-AS as 1:1:1. 
> > > > > > > > > > 
> > > > > > > > > > But these are not unique across SGs.  An there is no 
> > > > > > > > reason to expect
> > > > > > > > > > then to be unique across IPSPs either (DE or SE).  
> > > > > > > > Independent IPSPs
> > > > > > > > > > cannot avoid another IPSP's RC values.
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Message distribution is per SGP in the AS-SG 
> > communication.
> > > > > > > > > Message distribution is per IPSP in the IPSP 
> > communication.
> > > > > > > > > 
> > > > > > > > > In SGP and IPSP, the RCs that identify the 
> > remote AS shall 
> > > > > > > > be unique. Remember 1:1:1.
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Cheers // Javier.
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > When ASP receives the message, it works exactly 
> > > > the same as 
> > > > > > > > > > in the SG-AS
> > > > > > > > > > > model.
> > > > > > > > > > > 
> > > > > > > > > > > There is no way of having this RC unicity with 
> > > > your model 
> > > > > > > > > > if there is no
> > > > > > > > > > > previous communication between ASP1 and ASP3. 
> > > > Imagine if we 
> > > > > > > > > > increase the
> > > > > > > > > > > number of ASPs that wants to communicate with 
> > > > ASP2.... It's 
> > > > > > > > > > even harder for
> > > > > > > > > > > you..
> > > > > > > > > > 
> > > > > > > > > > There is no way in DE either.
> > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > > Sorry, you'll have to do better than that.
> > > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > Brian, I'm not trying to do it better or worse, 
> > > > just trying 
> > > > > > > > > > to reflect the
> > > > > > > > > > > reasons why I think your model doesn't work. 
> > > > And the worst 
> > > > > > > > > > thing is that you
> > > > > > > > > > > are trying to change basic concepts as RC 
> > > > definition/use, 
> > > > > > > > > > the needs an ASP
> > > > > > > > > > > and its user part have, etc. I don't know 
> > what kind of 
> > > > > > > > > > implementation you
> > > > > > > > > > > are doing (if any). But for big networks, it 
> > > > doesn't work 
> > > > > > > > > > efficiently: think
> > > > > > > > > > > about O&M, and also you try to change M3UA 
> > > > basic concepts.
> > > > > > > > > > 
> > > > > > > > > > You are blind to the same deficiencies in DE.  SE is 
> > > > > > just DE with
> > > > > > > > > > one RC value per pair and single message exchange.
> > > > > > > > > > 
> > > > > > > > > > --brian
> > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > Cheers // Javier.
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > ---
> > > > > > > > > > > You are currently subscribed to sigtran as: 
> > > > > > [email-masked]
> > > > > > > > > > > To unsubscribe send a blank email to 
> > > > > > > > > > [email-masked]
> > > > > > > > > > 
> > > > > > > > > > -- 
> > > > > > > > > > Brian F. G. Bidulock
> > > > > > > > > > [email-masked]
> > > > > > > > > > http://www.openss7.org/
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > ---
> > > > > > > > > > You are currently subscribed to sigtran as: 
> > > > > > > > > > [email-masked]
> > > > > > > > > > To unsubscribe send a blank email to 
> > > > > > > > > > [email-masked]
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > ---
> > > > > > > > > You are currently subscribed to sigtran as: 
> > > > [email-masked]
> > > > > > > > > To unsubscribe send a blank email to 
> > > > > > > > [email-masked]
> > > > > > > > 
> > > > > > > > -- 
> > > > > > > > Brian F. G. Bidulock
> > > > > > > > [email-masked]
> > > > > > > > http://www.openss7.org/
> > > > > > > > 
> > > > > > > > 
> > > > > > > > ---
> > > > > > > > You are currently subscribed to sigtran as: 
> > > > > > > > [email-masked]
> > > > > > > > To unsubscribe send a blank email to 
> > > > > > > > [email-masked]
> > > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > ---
> > > > > > > You are currently subscribed to sigtran as: 
> > [email-masked]
> > > > > > > To unsubscribe send a blank email to 
> > > > > > [email-masked]
> > > > > > 
> > > > > > -- 
> > > > > > Brian F. G. Bidulock
> > > > > > [email-masked]
> > > > > > http://www.openss7.org/
> > > > > > 
> > > > > 
> > > > > 
> > > > > ---
> > > > > You are currently subscribed to sigtran as: [email-masked]
> > > > > To unsubscribe send a blank email to 
> > > > [email-masked]
> > > > 
> > > > -- 
> > > > Brian F. G. Bidulock
> > > > [email-masked]
> > > > http://www.openss7.org/
> > > > 
> > > > 
> > > > ---
> > > > You are currently subscribed to sigtran as: 
> > > > [email-masked]
> > > > To unsubscribe send a blank email to 
> > > > [email-masked]
> > > > 
> > > 
> > > 
> > > ---
> > > You are currently subscribed to sigtran as: [email-masked]
> > > To unsubscribe send a blank email to 
> > [email-masked]
> > 
> > -- 
> > Brian F. G. Bidulock
> > [email-masked]
> > http://www.openss7.org/
> > 
> 
> 
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to [email-masked]

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]