RE: Traffic distribution semantics

Ilie,

> -----Original Message-----
> From: Ilie Glib [mailto:[email protected]]
> Sent: Tuesday, February 28, 2006 4:13 AM
> To: Barry Nagelberg
> Cc: [email protected]
> Subject: Re: [Sigtran] Traffic distribution semantics
>
>
> Hello Folks,
>
> I would like to ask about the consequences of the proposed
> clarification on the IPSP - IPSP scenario.
>
> My understanding was that IPSPs when routing outgoing traffic behave
> like SGPs and keep the AS states as SGPs do. At the same time I
> thought that xxUA adaptation layers in IPSPs are independent in
> different IPSPs serving the same AS. Thus these layers do not need to
> coordinate their states. (Applications/Users may need to coordinate
> their states, but it does not matter in this context)
>
> With the proposed clarification the M3UA layers on IPSPs serving the
> same traffic range become dependent on each other and have to
> coordinate their states. It is a BIG change to the standard, in my
> view. Moreover I do not see a stringent need for this change.
[TOLGA]I also think this type of operation -using global-AS state for
traffic distribution semantics- is rather unnecessary and seems to be an
arbitrary choice because I have yet to see a technical argument in its
favor. OTOH, using individual AS states in each SGP allows *all* ASPTM/ASPSM
to be run in each SGP individually, which makes perfect sense and does not
violate the principle of having those procedures between individual
ASPs/SGPs.

As I gather, Greg put some text, because of the my comments 5 years ago,
which I would say not I don't agree at all right now (I was arguing at that
time if AS state is not coordinated, what is the use of concept of SG. Two
points here:
a)At that time, I just was asking about sending NTFYs based on global-AS
state, not using a global state for ASPTM procedures (and now I think even
this is not an issue, because ASP failure information is conveyed with
NTFY("ASP Failure")).

b)If ASPSM/ASPTM is per SGP, concept of SG still makes perfectly sense due
to SSNM, because SG defines a group of SGPs which are visible under a single
MTP3 PC to the network.

Just wanted to share my opinion with you.
>
> Opinions?
>
> Regards
>
> Ilie
>
>
>
>
>
> On 2/27/06, Barry Nagelberg <[email protected]> wrote:
> > Tolga,
> >
> > Both #1 & #2 below will be a non-issue once we fix the RFC to
> clarify that the AS state is kept at a global level across
> > the entire SG.
> >
> > I believe that there is a consensus on the mailing list, at
> least from Brian and Lincoln, that this clarification is
> > necessary.
> >
> > Barry Nagelberg
> > Adax, Inc.
> >
> > -----Original Message-----
> > From: Tolga Asveren [mailto:[email protected]]
> > Sent: Monday, February 27, 2006 11:39 AM
> > To: [email protected]
> > Subject: RE: [Sigtran] Traffic distribution semantics
> >
> >
> > Barry,
> >
> > If it is really implementation dependent, I 100% percently
> agree with you.
> > The reason why I thought it could have some interoperability
> issues is as
> > follows:
> >
> > 1)Traffic mode allows to effect the message distribution to ASPs. For
> > example, if one ASP overrides the other one on one SGP, but not
> the other
> > one, the traffic they are going to receive will be different,
> depending on
> > whether the individual or global state is used in SGPs to distribute the
> > traffic.
> >
> > 2)I believe it makes sense to send the NTFY for AS state
> changes based on
> > the state used for traffic distribution purposes, i.e. if
> global state is
> > used based on global state changes, if local state is used
> based on local
> > state changes. So, depending on SG is implemented, the NTFYs received by
> > ASPs will be different.
> >
> > IMO, neither 1) nor 2) are part of core interoperability, none
> of the main
> > procedures will be broken. OTOH, it may create certain issues
> in real life
> > deployments. So, I personally am also not thinking strongly
> that those are
> > huge problems but tend to think it could be nice to have a common
> > understanding.
> >
> >     Thanks,
> >     Tolga
> >
> > > -----Original Message-----
> > > From: Barry Nagelberg [mailto:[email protected]]
> > > Sent: Monday, February 27, 2006 11:00 AM
> > > To: [email protected]
> > > Subject: RE: [Sigtran] Traffic distribution semantics
> > >
> > >
> > > Tolga,
> > >
> > > This subject is implementation dependent and doesn't belong
> in the RFC.
> > >
> > > Barry Nagelberg
> > > Adax, Inc.
> > >
> > > -----Original Message-----
> > > From: Tolga Asveren [mailto:[email protected]]
> > > Sent: Monday, February 27, 2006 10:18 AM
> > > To: [email protected]
> > > Subject: [Sigtran] Traffic distribution semantics
> > >
> > >
> > > After much discussion in "M3UA Notify Message" thread, I got
> more confused
> > > and became unsure regarding what needs to be done (I wanted
> to start a new
> > > thread because I doubt many people followed it and I can't blame
> > > anybody, it
> > > probably should be an off-line discussion for most of the time)
> > >
> > > The question to be answered is who is the owner of the traffic
> > > distribution,
> > > SG or SGP -here as traffic distribution, I refer to traffic
> distribution
> > > from M3UA point of view, selecting an ASP depending on loadshare
> > > or override
> > > traffic modes-. Practically it means, do we distribute traffic to
> > > ASPs based
> > > on the "global ASP states" kept SG-wide or the "local ASP
> states" kept in
> > > each SGP individually? If global ASP state is used, SG would be
> > > the owner of
> > > traffic distribution, if local state is used, SGP would be
> the owner of
> > > traffic distribution.
> > >
> > > I believe there are two main parameters to be considered:
> > > a)Are traffic characteristics different on SGPs belonging to
> the same SG
> > > b)The architectural robustness/elegance
> > >
> > > For a), the question to be answered is are messages coming
> from different
> > > SGPs -in the context of this discussion, all SGPs in
> > > consideration are part
> > > of the same SG- treated in a different way at an ASP/have different
> > > preference. At the first thought, my answer was "No" but I am not
> > > ruling out
> > > the possibility that things like geographical location could be a
> > > parameter
> > > here, where it would be desirable/preferrable to receive traffic from
> > > certain SGPs and not so preferred from other ones, for
> example due to the
> > > cost of IP routing.
> > >
> > > For b), the question of ownership of traffic distribution to
> ASP question
> > > leads to who is the owner of ASPTM procedures. It doesn't sound
> > > very clean,
> > > to have different owners for traffic distribution and ASPTM. Actually
> > > traffic distribution itself is an ASPTM procedure.
> Considering this, one
> > > would expect all logical execution associated with ASPTM to
> happen at the
> > > same entity. I would expect ASPSM to be executed at same entity
> > > as well from
> > > architectual sanity point of view. Practically this means, if SG
> > > is owner of
> > > the traffic distibution, why is it not owner of ASPTM (and
> possibly ASPSM)
> > > as well? Why is ASPAC sent to all SGPs, rather than just to one
> > > of them? One
> > > could even ask why is ASPUP sent to all SGPs, rather than to only one?
> > >
> > > I believe, from "necessity" point of view, we need to
> consider the answer
> > > for a). If the answer for a) is "characteristics are not different for
> > > messages coming from different SGPs", then for b) both
> options are open.
> > > There is no exact need to send ASPAC to all SGPs. In such a
> case I would
> > > expect all  ASPTM procedures -including traffic distribution- to
> > > be executed
> > > based on the states kept per SG or per SGP but not in a
> mix-match way. In
> > > this situation, my preference would be using states kept in each SGP,
> > > providing a more simplistic architecture, where all ASPSM/ASPTM
> > > is executed
> > > in the context of a single SGP -please note this does mean disallowing
> > > internal routing or not creating a uniqie SPMC view-.
> > >
> > > If the answer to a) is "Yes", then it seems preferrable to
> have traffic
> > > distribution logic to use states kept in individual SGPs, because
> > > this would
> > > allow ASPs, to force different choices on different SGPs,
> > > depending on their
> > > needs. In this case I would expect all ASPTM to use states kept in
> > > individual SGPs.
> > >
> > > Any comments/ideas?
> > >
> > >
> > >     Thanks,
> > >     Tolga
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Sigtran mailing list
> > > [email protected]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> > >
> > > _______________________________________________
> > > Sigtran mailing list
> > > [email protected]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> > >
> >
> >
> >
> > _______________________________________________
> > Sigtran mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> >
> >
> > _______________________________________________
> > Sigtran mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> >
>
>
> --
> Ilie
>
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran
>