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

From: Dennis Niermann <[email-masked]>
Date: Fri, 02 Nov 2001 17:36:34 -0600

Hi Tolga,
Some short response below..

[email-masked] wrote:
> 
> Hi Dennis,
> 
> Please see comments below.
> 
>   Tolga
> 
> > -----Original Message-----
> > From:   Dennis Niermann <[email-masked]>
> > Sent:   Friday, November 02, 2001 4:02 PM
> > To:     "sigtran" <[email-masked]>
> > Cc:
> > Subject:     Re: [Fwd: Re: IPSP proposed text (1st approach)]]
> >
> >  Hi Tolga,
> > Here are my reasons for disagreeing with your conclusion that
> > it is better to define the RC as representing a pair of AS's.
> > 1. It makes the definition of AS semantically different for the
> > IPSP-IPSP case (a pair of AS's) versus the ASP-SGP case (where the
> > RC must still represent a single AS because the AS is not paired
> > up with another).
> [TOLGA] More and more I think, because of the point-to-point nature of IPSP
> communication , this is unavoidable. In IPSP-IPSP communication we have two
> endpoints in M3UA domain. The reference corresponding the communication
> between two such endpoints (RC) should be unique. So, RC should be unique
> per AS pair.
> In SG-ASP case, there is only one AS in M3UA domain and the comunciation is
> not point-to-point. In such a case, it is enough to use an RC value based
> on this single AS. Afterall, in SG/ASP case it is only important whether
> the message is sent for an AS1 or from an AS1. In IPSP-IPSP case, it is
> important that it is sent by AS1 to AS2 and vice versa, because of the
> point-to-point nature of this communication. If we don't care about the
> originating AS, it won't be point-to-point (maybe this is also an
> alternative to nt make it point-to-point in that sense? In fact it was not
> clear to me, what was meant by draft, when it says IPSP-IPSP communication
> is point-to-point. Does it mean point-to-point between ASs or does it mean
> that there are no IPSPs, which are acting like routers for other IPSPs (for
> example IPSP1 sends something to IPSP2 not directly but via IPSP3)? )
[DENNIS] I am also not sure what is precisely meant by point-to-point
in this context. I think that it is just a way to say that an M3UA AS is 
communicating with another M3UA AS rather than with a MTP3 user.

> > 2. It changes the semantics of the ASPAC request from its current
> > meaning
> > of "to tell a remote M3UA that this ASP is ready to process signalling
> > traffic for a particular AS" to something else that I am not even sure
> > makes any sense.
> [TOLGA] I agree that it changes but to keep it point-to-point between ASs,
> it seems this is unavoidable. Also, if we add a second RC to DATA, the
> meaning of this second RC will be different than the original one.
[DENNIS] I think that the important thing is to make the behavior at an
IP end node using M3UA to be a similar as possible for talking to a 
MTP3 user via a SG as with another M3UA end node.

> > 3. It breaks the ability to use the registration messages and
> > procedures
> > in their current form since they depend on a RC value to be assigned
> > to a single routing key (one AS).
> [TOLGA] This can be solved by palying a little bit with registeration
> messages but yes it could bebetter if we could do it without a change.

> > 4. I believe that it is much easier to manage and understand RCs
> > assigned
> > to AS's than to pairs of AS's. An RC per AS grows linearly with the
> > number
> > of AS's, whereas an RC per AS-AS pair grows exponentially.
> > It is true that for the simple case of a single AS serviced
> > by a single
> > IPSP that this is all a non-issue since in both the single
> > ended and the
> > double ended case you don't even need to use an RC, it is only
> > interesting
> > when you consider the more complicated cases.
> > Even though between any two pairs of AS's it is point-to-point.
> > It is also true that a given IPSP is certainly going to have
> > associations
> > with many other IPSPs and/or SGPs. And, its AS(s) is going to
> > be paired
> > up with many other ASs.
> [TOLGA] If point-to-point means point-to-point between ASs, then I still
> think this is the correct way.
> > 5. I think that it is a mistake to create specialized behavior and
> > semantics
> > for when communicating with another IPSP versus communicating
> > with a SG.
> [TOLGA] As a final word, probably the key question is, what is meant by
> point-to-point communication? Who are the endpoints of this communiction?
> If we have a clear answer for this question, maybe it will be easier to
> come to a conclusion, which everybody is going to accept.
[DENNIS] I think that the end points are clear, it is the M3UA users, 
aka the ASs.

> 
>          Tolga
> 
> >    Dennis
> > [email-masked] wrote:
> > >
> > > Hi,
> > >
> > > Because of the point-to-point nature of IPSP communciation,
> > it seems to me
> > > now more logical to identify every AS pair with a unique RC. ASs are
> > > corresponding to endnodes of the communication. As the name
> > implies, in
> > > point-to-point communication messages are sent and received
> > between two
> > > points. This can be achieved only by identifying both of
> > the endpoints for
> > > a message, if over a single association traffic of more
> > than one AS pairs
> > > is transferred (if the whole traffic belongs only to one AS
> > pair, then it
> > > is implied by the association itself)
> > >
> > > As pointed out by Dennis, similar result can be achieved by
> > putting two RCs
> > > in DATA (one for source AS one for destination AS) but
> > personally I find
> > > single ended approach more elegant from this point of view.
> > >
> > >     Tolga
> > [snip]
> > ---
> > You are currently subscribed to sigtran as: [email-masked]
> > To unsubscribe send a blank email to
> 
> ---
> 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]