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

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 2 Nov 2001 19:44:26 -0600

Dennis,

Dennis Niermann wrote:                                     (Fri, 02 Nov 2001 17:38:08)

> > Dennis, this is not what the table says above:
> > it says that message from AS1 have RC1, meaning
> > that they are labelled with the AS from which the
> > message is sent, in reverse to that of the draft
> > for AS/SG case.  These are completely reversed.
> > If you place the other RC in the message, then
> > the question arrises where the message came from
> > and how to apply ASPTM on imcoming messages.

> OK, then I think it is a table interpretation issue.

I think the table provided as very clear and not
open to interpretation.

> What I believe for the ASP/SGP case is what I said
> in the previous paragraph. But I left out the case
> of DATA from the ASP to the SGP. The fact is that the RC
> value is included in DATA messages for different reasons
> when it flows ASP to SGP versus SGP to ASP. There has 
> probably been a previous discussion as to why it is helpful
> to receive RC at the ASP "to assist in internal distribution".

There was a disccusion about why it was necessary, not
why it was "helpful".  Please refer to any long thread
in the archive in the last 4 mo. that has "Network Appearance"
or "Routing Context" in the subject line.  You are comming
into this discussion rather late.  It might be helpful to
ask questions before making assertions coming in so late.

> I don't understand why the SI isn't used to distribute
> the message to the right M3UA user, but I'll accept that
> there is probably some reason.

Refer to the threads on Network Appearance and Routing
Context for detail technical discussion of the reasons
for the REQUIREMENT that RC be place in the DATA in both
directions where not implied by the association.

> I also accept your explantion that the RC should be used
> at the SGP to verify the AS is active.

Good.

I am not convinced that the double-ended approach that
you describe can even work.  Perhaps you (or Javier or
Tolga or someone) could describe how the ASPs obtain
their RC values in the following very simple example:

(I don't agree yet that an IPSP has any need to support
multiple AS in a point-to-point arrangement, however,
this is the example.)

   PC1,SI5
    _____                                            
   /     \                                           
  |  AS1  |                                          
   \_____/\                                  PC3,SI5 
           \  _______           _______       _____  
            \|       |  assoc  |       |     /     \ 
             | IPSP1 |---------| ISPS2 |----|  AS3  |
            /|_______|         |_______|     \_____/ 
    _____  /                                         
   /     \/                                          
  |  AS2  |                                          
   \_____/                                           
                                                     
   PC2, SI5                                          

You would have IPSPs send a pair of RC values in each
message where one RC value corresponds to the sending
AS and the other RC value corresponds to the receiving
AS.

Now, let there be no ambiguity in the table:

  When IPSP1 sends messages from AS1 to AS3 it uses
  the RC values RC1,RC3.

  When IPSP1 sends messages from AS2 to AS3 it uses
  the RC values RC2,RC3.

  When IPSP2 sends messages from AS3 to AS1 it uses
  the RC values RC3,RC1.

  When IPSP2 sends messages from AS3 to AS2 it uses
  the RC values RC3,RC2.

  We have the following routing keys at IPSP2:

        RK1  (OPC=PC3,DPC=PC1,SI=SI5)
	RK2  (OPC=PC3,DPC=PC2,SI=SI5)

  We have the following routing keys at IPSP1:

	RK3  (OPC=PC1,DPC=PC3,SI=SI5)
	RK4  (OPC=PC2,DPC=PC3,SI=SI5)

  Now let's take a look at the routing tables (as described
  in the draft, where the RC can be viewed as an index into
  a table containing the Routing Keys.)

  The routing table at IPSP2 is:

	RC1 RK1
	RC2 RK2

  The routing table at IPSP1 is:

	RC3 RK3
	RC3 RK4

Now, there is a problem.  This routing table at IPSP1 is
not valid: there is the same RC value (index) for two RK
entries.  How can this happen?  How will IPSP1 know to
return the same RC value when RK1 and RK2 are registered?
This would also violate the key relationship that there
is a 1:1:1 relationship between RC, RK, and AS.

How do you expect this to work?  Differently than the
current RC/RK/AS approach for SG/AS???

Note that this prolem does not occur if you do point-to-
point: that is, if there is one association per AS pair.
Nor does it occur for the signle-ended case.

In the single ended case, we have two traffic flows: RC1
and RC2.

The table at IPSP2 is:
	
	RC1 RK1
	RC2 RK2

The table at IPSP1 is:

	RC1 RK3
	RC2 RK4

Please describe how you see this working in the double-ended
case.

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