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

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

Hi Tolga,
You are correct, I started to bring in a separate issue.
I think that your example is 100% correct.
/Dennis

[email-masked] wrote:
> 
> Hi,
> 
> According to me the difference between allocation of RCs in two proposals
> is not that one needs to take associations into account and the other one
> not, but that one tries to code the two ends of traffic with a single RC
> whereas the other one uses separate RCs (this is in fact obvious, one of
> them uses one ASPAC, the other one two ASPACs)
> 
> To neutralize the affect of different associations, let's consider the
> following example:
>     +-------+                                    +------+
>     |       |                                    |      |
>     | AS1   +-----------+          +-------------+ AS5  |
>     |       |           |          |             |      |
>     +-------+           |          |             +------+
>                         |          |
>                         |          |
>     +-------+           |          |
>     |       +---------+ |          |             +--------+
>     | AS2   |         | |          | +-----------+ AS6    |
>     |       |         |-+--\      /+-+-\         |        |
>     +-------+        /      \    /      \        |        |
>                     | IPSP1  +--+ IPSP2  |       +--------+
>                      \      /    \      /
>     +-------+         |---+/      \--+-|         +--------+
>     |       |         |   |          | |         |        |
>     | AS3   +---------+   |          | +---------|  AS7   |
>     |       |             |          |           |        |
>     +-------+             |          |           +--------+
>                           |          |
>     +-------+             |          |           +---------+
>     |       |             |          |           |         |
>     | AS4   +-------------+          +-----------+  AS8    |
>     |       |                                    |         |
>     +-------+                                    +---------+
> 
> For double ASPAC proposal , I would expect a RC table like this for IPSP1:
> 
>      Outgoing Traffic
>      =================
>      AS1 ===> RC1
>      AS2 ===> RC2
>      AS3 ===> RC3
>      AS4 ===> RC4
> 
>      Incoming Traffic
>      ================
>      AS5 <=== RC5
>      AS6 <=== RC6
>      AS7 <=== RC7
>      AS8 <=== RC8
> 
> For single ASPAC proposal , again for IPSP1:
>      Incoming-Outgoing Traffic
>      =========================
>      AS1-AS5 <===> RC1
>      AS1-AS6 <===> RC2
>      AS1-AS7 <===> RC3
>      AS1-AS8 <===> RC4
>      AS2-AS5 <===> RC5
>      AS2-AS6 <===> RC6
>      AS2-AS7 <===> RC7
>      AS2-AS8 <===> RC8
>      AS3-AS5 <===> RC9
>      AS3-AS6 <===> RC10
>      AS3-AS7 <===> RC11
>      AS3-AS8 <===> RC12
>      AS4-AS5 <===> RC13
>      AS4-AS6 <===> RC14
>      AS4-AS7 <===> RC15
>      AS4-AS8 <===> RC16
> 
> It seems to me that the single ended approach uses M3UA point-to-point
> between ASs, whereas double ended approach uses it point-to-point between
> IPSPs.
> 
>     Tolga
> 
> > -----Original Message-----
> > From: Dennis Niermann <[email-masked]> On Behalf Of Dennis
> > Niermann <exudpn
> > Sent: Thursday, November 01, 2001 1:04 PM
> > To: "sigtran" <sigtran
> > Subject: Re: [Fwd: Re: IPSP proposed text (1st approach)]]
> >
> >
> > 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]
> 
> ---
> 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]