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

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 2 Nov 2001 00:17:06 -0600

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]