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

From: Dennis Niermann <[email-masked]>
Date: Fri, 02 Nov 2001 08:24:42 -0600

"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]