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

From: [email-masked]
Date: Fri, 2 Nov 2001 10:33:24 -0800

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

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