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

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

Javier,

Then why is there a need for twice as many RCs?  And twice
as many messages?

--brian

Javier Pastor-Balbas wrote:                                (Sun, 04 Nov 2001 12:39:14)
> Brian, 
> 
> One quick answer:
> 
> As IPSP2 registrates two RKs, it is serving to two ASs and therefore it
> gets two RCs... Always 1:1:1.
> 
> Cheers // Javier.
> 
> --- "Brian F. G. Bidulock" <[email-masked]> wrote:
> > Javier,
> > 
> > But Javier, then we have
> > 
> >   IPSP1 uses RC1 for traffic from AS1 to AS3.
> >   IPSP1 uses RC2 for traffic from AS2 to AS3.
> > 
> >   IPSP2 uses RC3 for traffic from AS3 to AS1.
> >   IPSP2 uses RC4 for traffic from AS3 to AS2.
> > 
> > This is not what was being described as the RC is associated
> > with the AS.  AS3 has two RC values (RC3 and RC4) in that
> > case for the same assocation and the same pair of IPSPs.
> > I thought you (or others) said that double-ended didn't
> > require this?  I though you (or others) said that this is
> > what made double-ended "like" the AS/SG case: that one
> > RC identified an AS.  But here you have two RCs for AS3.
> > If AS3 has similar RKs to 400 other AS, then AS3 will
> > require 402 RC values?  Gee, one for each traffic flow?
> > 
> > This is not double-ended at all.  It just has one set
> > of redundant RC values for the reverse direction.  With
> > 400 more AS, this would require 804 RC values.
> > 
> > 
> > In the single-ended case we have:
> > 
> >   IPSP1                       IPSP2
> > 
> >        REG REQ (RK2, RK1)
> >     -------------------------->
> >   
> >        REG RESP (RC1, RC2)
> >     <--------------------------
> >   
> > And,
> > 
> >   IPSP1 uses RC1 for traffic from AS1 to AS3;
> >   IPSP1 uses RC2 for traffic from AS2 to AS3;
> > 
> >   IPSP2 uses RC1 for traffic from AS3 to AS1;
> >   IPSP2 uses RC2 for traffic from AS3 to AS2;
> > 
> > Configuration need only be assigned at one end
> > instead of both as in the double-ended case.
> > There are half the messages, half the RC values
> > and there is no case of activations that are
> > stuck in half-duplex mode.
> > 
> > With 400 more AS, this would required only 402 RC
> > values.
> > 
> > 
> > Where is the value in the double-ended approach in
> > this case?
> > 
> > --brian
> > 
> > 
> > Javier Pastor-Balbas wrote:                                (Sun, 04
> > Nov 2001 12:20:32)
> > > Brian, 
> > > 
> > > IPSP1 won't return the same value for RK3 and RK4 in double-ended.
> > It
> > > will never happen...
> > > 
> > > 
> > > 
> > > IPSP1                       IPSP2
> > > 
> > >      REG REQ (RK2, RK1)
> > >   -------------------------->
> > > 
> > >      REG RESP (RC1, RC2)
> > >   <--------------------------
> > > 
> > > 
> > >      REG REQ (RK3, RK4)
> > >   <--------------------------
> > >  
> > >      REG RESP (RC3, RC4)
> > >   -------------------------->
> > > 
> > > 
> > > No violation here... 4AS:4RK:4RC
> > > 
> > > 
> > > Examples of DATA msgs
> > > 
> > >        DATA (RC4)
> > >   -------------------------->
> > >        DATA (RC3)
> > >   -------------------------->
> > >        DATA (RC2)
> > >   <--------------------------
> > >        DATA (RC1)
> > >   <--------------------------
> > > 
> > > 
> > > 
> > > 
> > > Cheers  // Javier.
> > > 
> > > 
> > > 
> > > 
> > > --- "Brian F. G. Bidulock" <[email-masked]> wrote:
> > > > Javier,
> > > > 
> > > > > > > >   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 can this happen?
> > > > 
> > > > --brian
> > > > 
> > > > -- 
> > > > 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]