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

From: Javier Pastor-Balbas <[email-masked]>
Date: Sun, 4 Nov 2001 11:44:50 -0800 (PST)

Brian, 

They are double-ended, following the AS-SG philosophy, same as ASPAC.

Read the text I provided in the first mail of this thread. I think it
was section 5.1.1.2. There you have a good example...

Cheers / Javier.

--- "Brian F. G. Bidulock" <[email-masked]> wrote:
> Javier,
> 
> You have not included the registation procedures for this example
> in other mail.  Please provide it now.
> 
> --brian
> 
> 
> Javier Pastor-Balbas wrote:                                (Sun, 04
> Nov 2001 10:46:11)
> > Brian, 
> > 
> > Could you complete this nice example with the registration process
> and
> > the ASPACs procedures for the single-ended as well? Double-ended's
> are
> > already included in the text I sent. 
> > 
> > You can probably deduce that since AS3 has registered in IPSP1 with
> two
> > RKs in your example, there'll also exist two RCs: RC3 and RC4
> (think of
> > the similar case for AS-SG communication where AS has two RKs).
> Hence
> > RC will follow the rule 1:1:1. 
> > 
> > Cheers // Javier.
> > 
> > 
> > --- "Brian F. G. Bidulock" <[email-masked]> wrote:
> > > 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]
> > 
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Find a job, post your resume.
> > http://careers.yahoo.com
> > 
> > 
> > ---
> > You are currently subscribed to sigtran as: [email-masked]
> > To unsubscribe send a blank email to
> [email-masked]
> 
=== message truncated ===

__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sun, 4 Nov 2001 13:48:48 -0600

Javier,

> > > > is a 1:1:1 relationship between RC, RK, and AS.

How can this happen?

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---