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

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 31 Oct 2001 23:57:43 -0600

Tolga,

TMT used to be in ASPAC Ack.  This would still
be useful for both the SG/AS and IPSP cases so
that the SGP TMT can be communicated in the
SG/AS case and the passive IPSP TMT can be
communicated in the IPSP case.

       SG                       ASP

       <-----ASPAC(Loadshare)------

       -----ASPAC Ack(Override)--->

and

       IPSP                    IPSP

       <-----ASPAC(Loadshare)------

       -----ASPAC Ack(Override)--->

Make sense?

There are obviously still some changes to be made
to support IPSP cases (but that was the original
issue).

--brian

Tolga Asveren wrote: (Wed, 31 Oct 2001 16:39:06)
>
> Brian,
> 
> In general, one point is not very clear to me. For
> ASP-SG case, traffic mode for messages in ASP->SGP
> direction is based on the configuration on ASP. But
> traffic mode for SGP->ASP is determined according to
> ASPACs. So, how will it be according to the IPSP model
> you propose? In one direction based on ASPAC and in
> the other one based on configuration? If there is
> going to be only one ASPAC, then I assume this will be
> the case.
> 
>     Tolga
>  
> --- "Brian F. G. Bidulock" <[email-masked]>
> wrote:
> > Dennis,
> > 
> > Dennis Niermann wrote:                              
> >       (Wed, 31 Oct 2001 08:22:40)
> > > 
> > > 
> > > Hi Brian,
> > > 
> > > I believe that you are saying that ASPIA and ASPAC
> > 
> > > can flow both directions, but that the
> > > RC value between any two pair of ASs should
> > > always be the same. Do I have that right?
> > 
> > Pretty much.
> > 
> > > Are you saying that an RC value does not
> > > identify an AS, that it identifies a pair of ASs?
> > 
> > Not really.  I'm saying that only one RC value
> > is needed.  That same value identifies both AS
> > in a pair over a given association between IPSPs
> > by nature of the fact that both IPSPs can assign
> > the same value to the AS at each end of a pair
> > in a strictly point-to-point configuration.
> > 
> > Follow?
> > 
> > --brian
> > 
> > > 
> > > /Dennis
> > > 
> > > "Brian F. G. Bidulock" wrote:
> > > > 
> > > > Dennis,
> > > > 
> > > > No, what I'm saying is that there are many
> > > > situations where one group of AS that live
> > > > and die together will do, not requiring RC.
> > > > 
> > > > But who cares if you cannot get away without
> > > > using RC all of the time?  The procedure is
> > > > there to include RC when it is necessary.
> > > > 
> > > > If you use RC3 for AS100:3 to AS201 on any
> > > > of the 4 associations, have IPSP1 or IPSP2
> > > > send ASPIA whenever it wants for RC3.  The
> > > > same is true for AS201 to AS100:3.  The major
> > > > point is you only need one RC value to
> > > > describe the traffic between a pair of AS--not
> > > > two values as the double-ended procedure would
> > > > have you do.
> > > > 
> > > > --brian
> > > > 
> > > > Dennis Niermann wrote:                          
> >           (Wed, 31 Oct 2001 07:45:01)
> > > > > Hi Brian,
> > > > > I do not see your point.
> > > > > All three AS(s) serviced by IPSP1
> > > > > and IPSP2 are for one point code but different
> > SIs.
> > > > > But that is only one example and is not the
> > point.
> > > > > Once again, if the ASPAC message can not be
> > used to
> > > > > tell the external world which of the ASPs is
> > currently
> > > > > actively handling an AS, how do you do it?
> > > > >
> > > > > Are you saying that for the IPSP-IPSP case
> > that
> > > > > an ASP can only handle one AS? Or, that an AS
> > can
> > > > > only be handled by one ASP?
> > > > >
> > > > > /Dennis
> > > > >
> > > > >
> > > > >
> > > > > "Brian F. G. Bidulock" wrote:
> > > > > >
> > > > > > Dennis,
> > > > > >
> > > > > > I don't think your example is a very good
> > one.
> > > > > > You certainly cannot not mix PC granularity
> > and
> > > > > > SI granularity RKs and have a point-to-point
> > > > > > arrangement.
> > > > > >
> > > > > > --brian
> > > > > >
> > > > > > Dennis Niermann wrote:                      
> >               (Wed, 31 Oct 2001 07:16:39)
> > > > > > > Brian,
> > > > > > > You did not at all address the question I
> > pose.
> > > > > > > Using the diagram below, IPSP3 wants to
> > send
> > > > > > > data to AS100:3.  IPSP1 and IPSP2 are the
> > two
> > > > > > > possible ASPs that service that AS, but in
> > > > > > > override mode.
> > > > > > > The typical M3UA message for communicating
> > > > > > > "I am the ASP that is actively serving
> > this/these
> > > > > > > AS(s)" is the ASPAC message. If IPSP1 and
> > IPSP2
> > > > > > > are not allowed to send an ASPAC message,
> > > > > > > how does a remote node (IPSP3) know
> > whether to
> > > > > > > send AS100:3 data to IPSP1 or to IPSP2?
> > > > > > >
> > > > > > > /Dennis
> > > > > > >
> > > > > > >
> > > > > > > "Brian F. G. Bidulock" wrote:
> > > > > > > >
> > > > > > > > Dennis,
> > > > > > > >
> > > > > > > > None of the UA drafts address how AS
> > distribute messages
> > > > > > > > over ASPs or visa versa.  It is expected
> > that the ASPs
> > > > > > > > have inter ASP communication and share
> > AS state when
> > > > > > > > they jointly serve an AS.
> > > > > > > >
> > > > > > > > So if IPSP1 looses connection(?) to
> > AS100:3 it should
> > > > > > > > have a chat with IPSP2.
> > > > > > > >
> > > > > > > > What you are trying to build here is a
> > multi-point-to-
> > > > > > > > multi-point configuration, rather than
> > the point-to-point
> > > > > > > > configuration proscribed in the draft. 
> > But, keep trying.
> > > > > > > >
> > > > > > > > --brian
> > > > > > > >
> > > > > > > > Dennis Niermann wrote:                  
> >                   (Tue, 30 Oct 2001 17:46:17)
> > > > > > > > > resending...
> > > > > > > > >
> > > > > > > > > Hi Brian,
> > > > > > > > > I agree there is no problem with
> > distributing SSNM messages.
> > > > > > > > > The issue is if IPSP3 has data to send
> > to AS100:3.
> > > > > > > > > How does it know to send it to IPSP1
> > or IPSP2?
> > > > > > > > > If they work in override mode, only
> > one is actively
> > > > > > > > > handling traffic for AS100:3.
> > > > > > > > > /Dennis
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > "Brian F. G. Bidulock" wrote:
> > > > > > > > > >
> > > > > > > > > > Dennis,
> > > > > > > > > >
> > > > > > > > > > There is still no need (or
> > requirement) for RC in
> > > > > > > > > > your illustration.  Each IPSP can
> > activate for all
> > > > > > > > > > the AS that it supports (ASPAC
> > without RC).
> > > > > > > > > >
> > > > > > > > > > Then, for example, if IPSP3 loses
> > connection to
> > > > > > > > > > AS201, it is ok to send DUNA(201) to
> > IPSP1 and IPSP2.
> > > > > > > > > > If you draw the same diagram with
> > AS(PC201/SI3), then
> > > > > > > > > > IPSP3 can send DUPU.
> > > > > > > > > >
> > > > > > > > > > Can you come up with a configuration
> > where RC is
> > > > > > > > > > 'required' considering the
> > point-to-point nature of
> > > > > > > > > > IPSPs?  It is not required in this
> > configuration.
> > > > > > > > > >
> > > > > > > > > > --brian
> > > > > > > > > >
> > > > > > > > > > Dennis Niermann wrote:              
> >                       (Tue, 30 Oct 2001 14:24:54)
> > > > > > > > > > > Hi Brian,
> > > > > > > > > > > Thanks for the challenge!
> > > > > > > > > > >
> > > > > > > > > > > "Brian F. G. Bidulock" wrote:
> > > > > > > > > > >   <snip>
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > It is going to be tough finding
> > a case where RC is needed at
> > > > > > > > > > > > all for point-to-point IPSP.
> > > > > > > > > > > >
> > 
> === message truncated ===
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Make a great connection at Yahoo! Personals.
> http://personals.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]