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

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

Javier,

It is the solution for the example I showed, which no-one has
been able to show a double-ended solution.  Please show the
double-ended solution for the example.  How registration works,
how there are suppose to exist two RKs in the same routing table
with the same RC value (precluded in current draft), and how
registration occurs when it appears that the IPSP registering
is registering its outgoing RK rather than the peer's outgoing
RK as in the AS/SG case.  Please address my simple example
for double-ended an instruct me on why you feel that it is
such a good solution in this case.

--brian

Javier Pastor-Balbas wrote:                                (Sun, 04 Nov 2001 12:10:16)
> Brian
> 
> I include what I snipped off:
> 
> > > 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
> 
> What is the solution for the example I showed ??? Tell me if it is
> included in the snipped text.
> 
> Single-ended model has a problem with the scenario below because you
> have more than once the same RC into the Routing Table of IPSP2.
> 
> Cheers // Javier.
> 
> 
> --- "Brian F. G. Bidulock" <[email-masked]> wrote:
> > Javier,
> > 
> > You snipped off the answer to your question.
> > 
> > --brian
> > 
> > Javier Pastor-Balbas wrote:                                (Sun, 04
> > Nov 2001 11:40:20)
> > > Brian, 
> > > 
> > > More comments below..
> > > 
> > > 
> > > --- "Brian F. G. Bidulock" <[email-masked]> wrote:
> > > 
> > > 
> > > 
> > > (snip)
> > > >   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.
> > > > 
> > > (snip)
> > > 
> > > 
> > > Although I've already answer this paragraph, read it again tell me
> > how
> > > the next scenario can work....
> > > 
> > > 
> > >             ASP1----ASP2-----ASP3
> > > 
> > > They serve to different AS (AS1, AS2, AS3). As in single-ended ASPs
> > > seems to have the RC predefined, imagine that ASP1 and ASP3 have no
> > > communication (e.g. they belong to different operators). They both
> > > decide to communicate with ASP2 with RC1=RC3=3. Therefore the
> > routing
> > > table in ASP2 will be:
> > > 
> > > RC1=3 RK1
> > > RC3=3 RK3
> > > 
> > > This is not compliance with the draft. How do you solve it?
> > > 
> > > Cheers // Javier.
> > > 
> > > 
> > > 
> > > 
> > > __________________________________________________
> > > 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]
> > 
> > -- 
> > Brian F. G. Bidulock
> > [email-masked]
> > http://www.openss7.org/
> 
> 
> __________________________________________________
> 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]

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