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

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

Javier,

Already done in my reply to your previos note.

--brian

Javier Pastor-Balbas wrote:                                (Sun, 04 Nov 2001 12:29:47)
> Brian, 
> 
> I've already done it.
> 
> I would also like you to instruct me showing the solution you have for
> the scenario below...
> 
> Cheers // Javier.
> 
> --- "Brian F. G. Bidulock" <[email-masked]> wrote:
> > 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/
> 
> 
> __________________________________________________
> 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]