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

From: Dennis Niermann <[email-masked]>
Date: Thu, 01 Nov 2001 11:54:56 -0600

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
>

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)
> 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.

> 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. 
And I believe that it is very unadviceable due to the extra
complexity that it would bring. Plus, the document clearly gives
examples and suggestions (not MUSTs) of having a unique
RC per RK (AS) at an SG.

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). 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. (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.

If you prefer dynamic configurations, how would the REG REQ and 
REG RSP look for the single ended case? It seems like you need 
both the local and the remote AS information to unique identify
a RC. 

> 
> >
> > At a given node, in the double ended case the number of
> > RCs to keep track of equals the number of ASs in the entire
> > network (known at that node).
> 
> This is not even true for the best case.  The
> best case is better as we have already
> discussed: no RCs.  If your IPSPs would
> communicate with each other and support the same
> ASs as their peers, no RCs are required in
> either case.
> 
> > Whereas in the single ended
> > case the number of RCs to keep track of is equal to the
> > number of associations times the number of ASs per association.
> > one particular node).
> 
> No, your assertion is false here.  We have
> already presented cases where no RCs are
> required for either single-ended or
> double-eneded.  Go back in the mail thread.
> 
> > So, if we were to extend the example to include the
> > associations for IPSP4,
> > the double ended would have exactly 6 RCs with unique
> > meanings and single ended would have 16 RCs with unique
> > meanings.
> 
> Not with correct tables....  Try filling them
> out again after answering your own questions.
> 
> --brian
> 
> >
> > Regards,  Dennis
> >
> >
> >
> > "Brian F. G. Bidulock" wrote:
> > >
> > > Dennis,
> > >
> > > Your example does not highlight any differences
> > > between the single-ended and double-ended approaches.
> > >
> > >       +------+                                  +------+
> > >       |      |                                  |      |
> > >       | AS   |                                  | AS   |
> > >       | 100:4|                                  | 201  |
> > >       |      | \                              / |      |
> > >       +------+   \  +-----+   IP   +-----+  /   +------+
> > >                    /       \------/       \
> > >       +------+     | IPSP1 |      | IPSP3 |     +------+
> > >       |      +- - -\       /-+   /\       /- - -+      |
> > >       | AS   |      +-----+   \ /  +-----+      | AS   |
> > >       | 100:3|                 \                | 200  |
> > >       |      |      +-----+   / \  +-----+      |      |
> > >       |      +- - -/       \-+   \/       \- - -+      |
> > >       +------+     | IPSP2 |      | IPSP4 |     +------+
> > >                    \       /------\       /
> > >       +------+   /  +---- +        +-----+  \   +------+
> > >       |      | /                              \ |      |
> > >       | AS   |                                  | AS   |
> > >       | 100:5|                                  | 202  |
> > >       |      |                                  |      |
> > >       +------+                                  +------+
> > >
> > > Consider example RC assignment for both the
> > > single-ended and double ended cases at IPSP3
> > > in the following table:
> > >
> > >                                      RC Values
> > >                                 ==========    ======
> > >                                   Double      Single
> > >     IPSP/    Remote    Local      Ended        Ended
> > >      Assoc     AS       AS      R->L  L->R     L<->R
> > >     -------  -------   -----    ----  ----     -----
> > >        1      100:4     200      4     1         1
> > >        1      100:4     201      3     2         2
> > >        1      100:3     200      2     3         3
> > >        1      100:3     201      1     4         4
> > >        2      100:3     200      4     1         1
> > >        2      100:3     201      3     2         2
> > >        2      100:5     200      2     3         3
> > >        2      100:5     201      1     4         4
> > >
> > > As you can see, the same AS pairings occur for both
> > > cases.  With the single-ended approach, IPSP3 has half
> > > the RC values to keep track of.  That's it.
> > >
> > > When IPSP1 loses activation of AS100:3 in the double-
> > > ended case it would send ASPIA RC=4 (from the table)
> > > to IPSP3.  If IPSP3 loses activation of AS200 it would
> > > send ASPIA (RC=1,3) to IPSP1.
> > >
> > > When IPSP1 loses activation of AS100:3 in the single-
> > > ended case it would send ASPIA RC=1 (from the table)
> > > to IPSP3.  If IPSP3 loses activation of AS200 it would
> > > send ASPIA (RC=1,3) to IPSP1.
> > >
> > > The same information is conferred, but in the single-
> > > ended case you need half the RC values and do not have
> > > to worry about half-duplex relationships between AS.
> > >
> > > Does this make things perfectly clear to you?
> > >
> > > There is absolutely no point in a double-ended
> > > procedure.  Double-ended procedures add overhead and
> > > complexity where not required.
> > >
> > > --brian
> > >
> > > Dennis Niermann wrote:                                     (Wed, 31 Oct 2001 10:11:03)
> > > >
> > > > Brian,
> > > >
> > > > I don't think that what you suggest is workable.
> > > > If one RC value is used that identifies both
> > > > ASs in a pair then problems arise.
> > > >
> > > > If IPSP1 sends an ASPIA to IPSP3 using RC=3 to
> > > > indicate that it is no longer serving AS100:3,
> > > > which of the ASs that IPSP3 is serving need to
> > > > also use RC3 on that association?
> > > > Both AS200 and AS201?
> > > > Or, just one of them?
> > > > If both AS200 and AS201 use RC3 then there is no way
> > > > distinguish between them.
> > > > If just one of them use RC3, then it breaks your rule
> > > > that the same RC value should be used by the ASs on
> > > > each side of the association.
> > > >
> > > > /Dennis
> > > >
> > >
> > > --
> > > 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]

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