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

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 31 Oct 2001 08:46:39 -0600

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.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > I believe that the following is legal since an ASP can service
> > > > > > > > > more than one AS and an AS can be serviced by more than one ASP:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >  Figure 4:  IPSP - IPSP, multiple AS's
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >      +------+                                  +------+
> > > > > > > > >      |      |                                  |      |
> > > > > > > > >      | AS   |                                  | AS   |
> > > > > > > > >      | 100:4|                                  | 201  |
> > > > > > > > >      |      | \                              / |      |
> > > > > > > > >      +------+   \  +-----+   IP   +-----+  /   +------+
> > > > > > > > >                   /       \------/       \
> > > > > > > > >      +------+     | IPSP1 |      | IPSP3 |     +------+
> > > > > > > > >      |      +- - -\       /-+   /\       /- - -+      |
> > > > > > > > >      | AS   |      +-----+   \ /  +-----+      | AS   |
> > > > > > > > >      | 100:3|                 \                | 200  |
> > > > > > > > >      |      |      +-----+   / \  +-----+      |      |
> > > > > > > > >      |      +- - -/       \-+   \/       \- - -+      |
> > > > > > > > >      +------+     | IPSP2 |      | IPSP4 |     +------+
> > > > > > > > >                   \       /------\       /
> > > > > > > > >      +------+   /  +---- +        +-----+  \   +------+
> > > > > > > > >      |      | /                              \ |      |
> > > > > > > > >      | AS   |                                  | AS   |
> > > > > > > > >      | 100:5|                                  | 202  |
> > > > > > > > >      |      |                                  |      |
> > > > > > > > >      +------+                                  +------+
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Is it supported for an IPSP to handle AS's with different point codes?
> > > > > > > > > Anyway, let's assume that the AS100:3, AS100:4, and AS100:5 all
> > > > > > > > > use the same point code but have different service indicators.
> > > > > > > > > Doesn't this require IPSP1 and IPSP2 to communicate what traffic
> > > > > > > > > they are handling.  E.g. by IPSP1 activating the RCs for AS100:4 and
> > > > > > > > > AS100:3 and IPSP2 activating the RC for AS100:5. Otherwise, how will
> > > > > > > > > IPSP3 and IPSP4 know where to send traffic?
> > > > > > > > >
> > > > > > > > > Regards,  Dennis
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > ---
> > > > > > > > > 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]
> > > > > > >
> > > > > > > --
> > > > > > > ---------------------------------------------------------------
> > > > > > >  Dennis Niermann              [email-masked]
> > > > > > >  Ericsson Network Systems
> > > > > > >  Richardson, Tx 75081
> > > > > > >
> > > > > > >
> > > > > > > ---
> > > > > > > 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]
> > > > >
> > > > > --
> > > > > ---------------------------------------------------------------
> > > > >  Dennis Niermann              [email-masked]
> > > > >  Ericsson Network Systems
> > > > >  Richardson, Tx 75081
> > > > >
> > > > >
> > > > > ---
> > > > > 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]
> > >
> > > --
> > > ---------------------------------------------------------------
> > >  Dennis Niermann              [email-masked]
> > >  Ericsson Network Systems
> > >  Richardson, Tx 75081
> > >
> > >
> > > ---
> > > 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/
> 
> -- 
> ---------------------------------------------------------------
>  Dennis Niermann              [email-masked]
>  Ericsson Network Systems   
>  Richardson, Tx 75081
> 
> 
> ---
> 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]