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

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 2 Nov 2001 15:29:38 -0600

Dennis,

You have missed the requirement in the draft to
identify the AS source of incoming messages as
cited in my previous mail.

Why cannot anyone give a simple answer to the questions
that are asked concerning double-ended operation?
It certainly has not been well thought out.

--brian

Dennis Niermann wrote:                                     (Fri, 02 Nov 2001 08:24:42)
> "Brian F. G. Bidulock" wrote:
> Hi Brian,
> I think that the answer to these concerns is 
> what is addressed in a parallel mail.
> Namely that in
> outgoing SSNM messages the RC is supposed to 
> identify a local AS whereas in DATA messages
> it is supposed to identify the remote AS.
> I think that if there is a reason to also
> identify the local AS in a DATA message then
> the answer is to add that as a parameter
> and not try to combine the two in a confusing way.
> 
> 
> 
> > 
> > Dennis,
> > 
> > Dennis Niermann wrote:                                     (Thu, 01 Nov 2001 11:54:56)
> > >
> > > Hi Brian,
> > >
> > > I think we used different interpretations
> > > for the meaning of column "L->R".
> > > I interpretted it to mean "the RC used to
> > > address the remote AS". You must have meant it
> > > to mean "the RC used to refer to the local AS"
> > > My intention was to use the following mapping
> > > of AS to RC:
> > >   AS200 = 1
> > >   AS201 = 2
> > >   AS100:3 = 3
> > >   AS100:4 = 4
> > >   AS100:5 = 5
> > > So, if I change the two double ended column labels
> > > to match your meaning, the table would be like this.
> > > >
> > > > >
> > > > >                                       RC Values
> > > > >                                  ==========    ======
> > > > >                                    Double      Single
> > > > >      IPSP/    Remote    Local      Ended        Ended
> > > > >       Assoc     AS       AS      L->R  R-L     L<->R
> > > > >      -------  -------   -----    ----  ----     -----
> > > > >         1      100:4     200      1     4         1
> > > > >         1      100:4     201      2     4         2
> > > > >         1      100:3     200      1     3         3
> > > > >         1      100:3     201      2     3         4
> > > > >         2      100:3     200      1     3         1
> > > > >         2      100:3     201      2     3         2
> > > > >         2      100:5     200      1     5         3
> > > > >         2      100:5     201      2     5         4
> > 
> > It seems that you and Tolga are suffering the same confusion.
> > 
> > ASPs register routing keys with SGP and get returned the RC
> > value that will appear in incoming messages.  If the ASP
> > registers a routing key with another ASP, it will be returned
> > the RC value that it will recieve in message matching the
> > corresponding routing key.  If the ASP were to locally apply
> > destination routing keys to determine AS, there would be no
> > need to register a routing key with the peer.
> > 
> > So why do you have IPSP3 in the table above sending the RC
> > value (RC=1) that corresponds to its AS200 in messages to ISPS1
> > (L->R)?  It must place the RC value that it returned to ISPS3
> > when it registered for, e.g., RK(DPC=100/SI=3), which would
> > be RC=4 in the example.
> > 
> > L is Local, R is Remote and this is the table for IPSP3.
> > 
> > When IPSP receives a message from IPSP1 (R->L) with RC=4,
> > how does IPSP3 know which Local AS this message is for?
> > 
> > Does it apply a RK to determine this?
> > 
> > If so, why did it register an RK with IPSP1?
> > 
> > How did ISPS3 get RC=4 into this table in the first place?
> > It certainly wasn't returned in response to REG REQ(DPC=200)
> > because there are two values (3 and 4) in the table for the
> > key (DPC=200).
> > 
> > This is certainly not how RC/RK/AS relate in the SG/AS model.
> > 
> > RC identifies the RK which is used to route traffic towards
> > the AS that receives traffic for that RK.
> > 
> > The RC in your table identifies the AS that sent the message
> > and has no relationship to a RK.
> > 
> > You can reverse the labels all you want.  Either the ASP
> > will not be able to determine the AS that the message
> > originated from, or it will not be able to determine the AS
> > that the message is destined for.  For some RKs, the ASP
> > needs to know both (OPC/DPC/SI/CIC, TID).  Also for some
> > RKs it is impossible to determine one or the other from
> > the message.
> > 
> > So you have other set of questions now that the labels are
> > reversed.
> > 
> > > >
> > >
> > > Plus, see my comments below.
> > >
> > >
> > > "Brian F. G. Bidulock" wrote:
> > > >
> > > > Dennis,
> > > >
> > > > Please see comments below....
> > > >
> > > > Dennis Niermann wrote:                                     (Thu, 01 Nov 2001 07:57:57)
> > > > > Hi Brian,
> > > > > Your example of RC value assignments was a
> > > > > very clear explanation of how you see things.
> > > > > So, in that sense it helped a lot. Thanks.
> > > > >
> > > > > But, I have two points.
> > > > >
> > > > > First, I think that the RC values given for the double
> > > > > ended case are not accurate. I believe that in the double
> > > > > ended case there would always be a particular RC value used for a
> > > > > particular AS (1-1 mapping from AS to RC) and so then values
> > > > > would be as such:
> > > >
> > > > I said it was one example.
> > > >
> > > > >
> > > > >                                       RC Values
> > > > >                                  ==========    ======
> > > > >                                    Double      Single
> > > > >      IPSP/    Remote    Local      Ended        Ended
> > > > >       Assoc     AS       AS      R->L  L->R     L<->R
> > > > >      -------  -------   -----    ----  ----     -----
> > > > >         1      100:4     200      1     4         1
> > > > >         1      100:4     201      2     4         2
> > > > >         1      100:3     200      1     3         3
> > > > >         1      100:3     201      2     3         4
> > > > >         2      100:3     200      1     3         1
> > > > >         2      100:3     201      2     3         2
> > > > >         2      100:5     200      1     5         3
> > > > >         2      100:5     201      2     5         4
> > > > >
> > > >
> > > > This will not work: your table has some glaring
> > > > errors in it.  How does IPSP3 indicate to IPSP1
> > > > that it has inactivated only AS201?
> > > By using RC=2. ("L->R" interpretation issue)
> > 
> > Answer the question for the reverse direction now.
> > 
> > > > There needs
> > > > to be separate L->R RC values for AS200 and
> > > > AS201.  Also, (your own question), how does
> > > > IPSP1 indicate the inactivity of just AS100:3?
> > > By using RC=3. Another label interpretatin issue.
> > 
> > Answer the question for the reverse direction now.
> > 
> > >
> > > > You have assigned the same R->L RC value to both
> > > > AS100:3 and AS100:4 for IPSP1 on Association 1.
> > > > Only 1 RC value is communicated in ASPAC, not a
> > > > pairing.
> > > Yet another label interpretatin issue. AS100:3 has RC=3,
> > > AS100:4 has RC=4.
> > >
> > > >
> > > > >
> > > > > Second, I do not believe that the single ended case
> > > > > has half the RC values to keep track of.
> > > >
> > > > My table shows the ASP keeping track of two
> > > > values per AS (this is the minimum).  Worst
> > > > case, there will be two "values" per AS per
> > > > association.  It looks like you want to number
> > > > them so that, in your example, the ASP has to
> > > > keep track of 4 values per AS (one for the local
> > > > AS and 3 for the remotes for each AS) per
> > > > assocation.  It does not change the fact that in
> > > > the SG/AS case, the ASP only need track 1 RC
> > > > value per AS per association, nor the fact that
> > > > single-ended is both consistent with the SG/AS
> > > > approach, as well as being sufficient in this
> > > > regard.
> > > >
> > > > > In terms of
> > > > > "values" the single ended case uses from 1-4 and the
> > > > > double ended case uses from 1-5.
> > > >
> > > > You have not shown worst case.  Each
> > > > registration could yield a different value.
> > > > (And your table is full of errors.)
> > > >
> > > > > But, that is not
> > > > > important. What is important if the number of "meanings"
> > > > > of RC values to keep track of.  In the double ended case
> > > > > there is 5 (same as the total number of ASs).
> > > >
> > > > No, at IPSP3 there are 8 traffic flows as listed
> > > > in the table.  In double ended, those 8 traffic
> > > > flows require 2 RCs to be maintained per flow for a
> > > > worst case situation of 16 RC values.  For
> > > > single ended 1 RC per flow for a worst case of 8
> > > > RC values.  Get your table correct first and
> > > > then count 'em for the worst case (different RC
> > > > returned on each association for each
> > > > registration in each direction.)
> > > >
> > > > > Whereas in
> > > > > the single ended case there is 8.
> > > >
> > > > Well, you got one figure right.  Worst case 8.
> > > >
> > > > >This is because in the
> > > > > single case an RC has meaning only in the context of a
> > > > > particular association (the second RC 1 is unrelated
> > > > > to the first RC 1).
> > > >
> > > > This might be your oversight that caused you to
> > > > place errors in your table.  It is no different
> > > > for the double ended case.  In the double ended
> > > > case, each RC is just assigned per direction,
> > > > and twice the values can occur.
> > >
> > > I think that this is the fundamental issue.  And the source of
> > > the different perspectives.
> > >
> > > In the case of static configurations there is no need to use
> > > more than one RC per AS (not one per AS per association as you
> > > would have it).  It may be possible, but not necessary.
> > 
> > Did I say it was necessary?  It is possible and I was talking
> > worst case.  Worst case is one RC per AS per association.
> > 
> > > And I believe that it is very unadviceable due to the extra
> > > complexity that it would bring.
> > 
> > Join the discussion for the AS/SG case.  It is impossible to
> > enforce between SG.  A careful operator might number things
> > nicely, or they might not.
> > 
> > > Plus, the document clearly gives examples and suggestions (not
> > > MUSTs) of having a unique RC per RK (AS) at an SG.
> > 
> > Join the other discussion.  The examples show how you can
> > do things that way if you want, but if you dont want, dont.
> > Worst case is still worst case.
> > 
> > > Even in the case of dynamic registration there is an
> > > implication that at an SG that a RC would have a unique
> > > meaning for the node (refer to a single RK).
> > 
> > But strangely your RC values above do not refer to an RK,
> > they only attach themselves to originating AS (for which
> > there is no "originating" RK).  Are you perhaps having
> > difficulty applying the principle?
> > 
> > > There would be no reason to have the RC allocated by the SG
> > > and returned to the ASP unless it had significance beyond a
> > > single association.
> > 
> > And there is no reason for an RC that doesn't correspond
> > to a RK.  Where do your values come from in your table?
> > 
> > > (The ASP knows as well as the SGP what RCs are in use on that
> > > one association).  Of course, the ASP does have to handle the
> > > case that a different RC used for its local AS for each SG
> > > that it has an association with, that is a disadvantage of
> > > dynamic registration.
> > 
> > You think dynamic registration is different from static
> > configuration.  That is not the case.  Dynamic registration
> > changes nothing about the way that RC values are assigned:
> > it just changes *where* they are statically configured.
> > In the case of static configuration, they are configured
> > both at the SG and the ASP.  For dyamic, just at the SG and
> > the ASP asks for the value by RK.
> > 
> > You seem to be having some problems following the procedures.
> > 
> > > If you prefer dynamic configurations, how would the REG REQ
> > > and REG RSP look for the single ended case?
> > 
> > I think you should show how it works for the double-ended
> > case because contrary to your table, multiple RC values cannot
> > be returned in response to registration of a single RK over
> > a single association and single RC values cannot be returned
> > for multiple individual routing keys.
> > 
> > Please show how at least one line of the table that you
> > presently give can be built using double-ended registration.
> > 
> > > It seems like you need both the local and the remote AS
> > > information to unique identify a RC.
> > 
> > As in the SG/AS case, one side is statically configured,
> > the other does REG REQ for a given traffic flow.
> > 
> > Any questions?
> > 
> > --brian
> > 
> > --
> > 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]
> 
> -- 
> ---------------------------------------------------------------
>  Dennis Niermann              [email-masked]
>  Ericsson Network Systems   
>  Richardson, Tx 75081
> 
> 
> ---
> 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]