Subject: [Sigtran] SUA: Message distribution among Load Shared ASPs (IPSP case)

From: "Saurabh Jain" <[email-masked]>
Date: Fri, 23 Jun 2006 09:34:20 +0530

Hi,

In SUA RFC 3868,   In Section 4.7.3.  Routing and message distribution at
the SG
The following two subsection are specific only to Message distribution at SG
    4.7.3.1.  TCAP traffic
    4.7.3.2.  SCCP Connection Oriented traffic

RFC does not talk about message distribution for IPSP nodes. (the
corresponding section for IPSP Considerations is missing)
This would mean that DRN and TID label are applicable only between ASP and
SGP and would not be sent between two IPSP nodes.
I want to confirm if, section for IPSP considerations has been left out in
RFC by mistake, or is there any specific reason due to which message
distribution(based on TID/DRN labels) among loadsharing ASPs is not required
in case of IPSP nodes.

NOTE:  Section 4.3.  AS and ASP State Maintenance   states that apart from
section 4.3.1, 4.3.2, 4.3.3, The remaining sections contain specific IPSP
Considerations subsections.

rgds
Saurabh
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 23 Jun 2006 01:00:18 -0600

Saurabh,

Saurabh Jain wrote:                           (Fri, 23 Jun 2006 09:34:20)
>    This would mean that DRN and TID label are applicable only between ASP
>    and SGP and would not be sent between two IPSP nodes.

In an RFC when it doesn't say anything it does not mean that you cannot
do a thing, it means that you can.  You are trying to read requirements in
between the lines where none exist.

>    I  want  to  confirm if, section for IPSP considerations has been left
>    out  in  RFC  by mistake, or is there any specific reason due to which
>    message  distribution(based  on TID/DRN labels) among loadsharing ASPs
>    is not required in case of IPSP nodes.

Again, because it is missing means only that there are no special IPSP
considerations for TID/DRN labels.  It does _not_ mean that an IPSP cannot
use them.

>    NOTE:   Section 4.3.  AS and ASP State Maintenance   states that apart
>    from  section  4.3.1,  4.3.2,  4.3.3,  The  remaining sections contain
>    specific IPSP Considerations subsections.

And for distribution there are no specific IPSP considerations...

The point is rather moot as TID/DRN label mechanisms are broken anyway.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Saurabh Jain" <[email-masked]>
Date: Thu, 29 Jun 2006 13:35:52 +0530

Hi Brian,

I would like to understand your comment that TID/DRN label mechanisms are
broken.
Can you please share the reason for this.

The latest SUA implementor guide
draft-ietf-sigtran-sua-implementor-guide-03.txt  is still containing section
which provides clarifications on TID and DRN label.

rgds
Saurabh

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 29 Jun 2006 03:42:00 -0600

Saurabh,

Saurabh Jain wrote:                              (Thu, 29 Jun 2006 13:35:52)
> 
>    Hi Brian,
> 
> 
> 
>    I  would like to understand your comment that TID/DRN label mechanisms
>    are broken.

They cannot work in the multiple SG as STP scenario, cannot support
relay, requires modification to the SCCP or TCAP stack, has no error
recovery mechansims, can easily be specified in a logically impossible
configuration (that cannot be detected by the SG), requires paritioning
of a scarce numbering space (i.e. cannot scale), breaks TCAP error
recovery mechanisms, and a host of other reasons.

>    Can you please share the reason for this.

See "SUA-09: SCCP Connections and TCAP Transactions" from Jan 2002.
See "SUA v16: TID and DRM labels" from Feb 2004.

>    draft-ietf-sigtran-sua-implementor-guide-03.txt   is  still containing
>    section which provides clarifications on TID and DRN label.

And it contains neither change.
See "Clarification on TID" from Oct 2005.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Haresign Lincoln" <[email-masked]>
Date: Thu, 29 Jun 2006 09:55:47 -0400

Saurabh,

I think if the TID problem is fixed (it was correct in the original
spec, broken in one of the earlier implementor's guides, and appears to
be fixed in the latest).  

Brian,

Perhaps I'm missing something.  Why would it not work in the multiple SG
scenario?  I'm assuming here that the ASP would use the same TID
parameter in the ASPAC message going towards both SGs.

Regards,
Lincoln

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Thursday, June 29, 2006 5:42 AM
To: Saurabh Jain
Cc: [email-masked]
Subject: Re: [Sigtran] SUA: Message distribution among Load Shared ASPs
(IPSPcase)

Saurabh,

Saurabh Jain wrote:                              (Thu, 29 Jun 2006
13:35:52)

--brian

--
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 29 Jun 2006 11:00:53 -0600

Lincoln,

Haresign Lincoln wrote:                   (Thu, 29 Jun 2006 09:55:47)
> parameter in the ASPAC message going towards both SGs.

TID would require implementnation of both TCAP message decoding and
transaction state machines at the STP/SG.  This is not appropriate.  Nor
are STPs normally equipped with general purpose TCAP protocol stacks.
TUA provides this capablity at the SG.  There is much discussion on this
topic on the archives dating all the way back to about 2001.

(Also, consider the SUA equivalent problem of your M3UA problem with
SI-based routing: one ASP supporting a TID range looses communication
with one STP/SG only.  Are all of the messages lost?  What can the SG
do?  It cannot send P-Abort because there is no message for a failed TID
range.  Shoud it send the message to the other STP?  What if the ASP for
a TID range is isolated from both?  With the associated STP send the
message back forming a loop?  In the M3UA case the STP can track UPU,
but there is no equivalent for a TID range.)

DRN is very broken for STP/SG.  It currently requires the coupling of
connection sections at the SG, an unacceptable restriction (SS7 does not
require coupling of connection sections at the STP and it is in fact not
normally done).  The counter-proposal before WGLC on SUA was a
registration mechanism whereby connection references could be registered
by the ASP on a connection by connection basis with both SG/STP so that
coupling of connection sections at the STP would not be the only way to
support protocol classes 2 and 3.  Without this support, SUA is
incapable of providing seamless or transparent interworking for protocol
classes 2 and 3.  Again, there is also much discussion on this topic
dating back to 2001.

(Note that coupling is also unnecessarily required at every IPSP relay
point.)

Both are quite broken.  DRN can be fixed.  TID cannot.  Labels should be
done away (or at least made strictly OPTIONAL) for the all scenarios and
support for error situations need to be added to make them even workable
as an option.  See the threads.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Haresign Lincoln" <[email-masked]>
Date: Thu, 29 Jun 2006 13:14:44 -0400

Brian,

One way to implement this for TID so it works (sort of) is as follows.

The ASP (within the AS) assigns it's own unique value.  For example,
let's say it has a bit mask of 8 bits (allowing for up to 2**8 unique
ASPs).  And it specifies a range in the part of the TID that is built by
the ASP (local TID).  

When a BEGIN arrives at the SG, it can be routed to any ASP (perhaps in
a round robin fashion).  For a CONTINUE or END, the TID would be parsed
and correctly routed to the ASP that is handling that call.

Downsides:

1) If an ASP dies (or becomes inaccessible), then yes all calls in
progress for that ASP are lost.  Although if I'm an endpoint and I
crash, same thing.  In the case of SG-ASP, loss of an ASP only results
in loss of a subset of calls.

2) The SG needs to parse part of the TCAP message (TID and message
type).  This isn't really a TCAP stack, only a little decoding in the
inbound direction.

I think this provides a valuable feature in SUA for message distribution
within an AS.

Regards,
Lincoln

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Thursday, June 29, 2006 1:01 PM
To: Haresign Lincoln
Cc: Saurabh Jain; [email-masked]
Subject: Re: [Sigtran] SUA: Message distribution among Load Shared ASPs
(IPSPcase)

Lincoln,

> 
> Perhaps I'm missing something.  Why would it not work in the multiple 
> SG scenario?  I'm assuming here that the ASP would use the same TID 

--brian

--
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 29 Jun 2006 11:42:05 -0600

Lincoln,

Did you not read the discussions on the archive?

Haresign Lincoln wrote:                         (Thu, 29 Jun 2006 13:14:44)
> and correctly routed to the ASP that is handling that call.

That would only work for the most trivial of services and is rather
uninteresting.  The purpose was to permit an ASP to maintain a set of
transaction states largely local.  For an _interesting_ service application,
such as GSM MAP, it is also necessary to send all linked transactions to the
same ASP (not just CONTINUE/QWOP), requiring parsing of the application
context or operation and the linked id at the SG.  In fact better transaction
state locality can be acheived by distributing over the ASPs serving the AS
based on Sequence (SLS value) because the GSM entity will assign the same
sequence value to CONTINUE/QWOP (because they require protocol class 1) as
well as linked operations (per GSM MAP specifications).  Understand?  Another
example, a CS/AIN SSP sends UNIDIRECTIONAL messages to an SCP to indicate call
release.  This UNIDIRECTIONAL, of course, contains no TID, but it does contain
a correlation id (which would have to be parse).  However, CS/AIN, just as
GSM/MAP, sends the UNIDIRECTIONAL message with the same Sequnce Control (SLS)
as the transaction to which it correlates.  Good transaction state locality,
as well as best load balancing, can most easily be provided by distribution
based on SLS.

> in loss of a subset of calls.

Apples and oranges.  From RFC 3332:

"  For carrier grade networks, the failure or isolation of a particular
"  signalling process should not cause stable calls or transactions to
"  be lost.  This implies that signalling processes need, in some cases,
"  to share the call/transaction state or be able to pass the call state
"  information between each other.  In the case of ASPs performing call
"  processing, coordination may also be required with the related Media
"  Gateway to transfer the MGC control for a particular trunk
"  termination. However, this sharing or communication of
"  call/transaction state information is outside the scope of this
"  document.

You are not going to get away with requiring the SG to provide complete
locality of state and better locality is afforded in practical applications
by load balancing based on SLS/Sequnce than is afforded by TID Label and
it does not require TCAP decoders, Application Part contexts and ASE, nor
TCAP/TCAP-User state machines.  It is immediately avaiable in the MTP/SCCP
portions of the received message.

> type).  This isn't really a TCAP stack, only a little decoding in the

Linked IDs, and application contexts or operations are not trivial.  Also,
you need to consider that TCAP is not the only SCCP user and SCCP need not
be aware of the nature of its users.  If your TID assignment for distribution
goes against SLS assignment rules for, say GSM MAP, one ASP losing
connectivity to an SG will result in failure of all transactions in the
TID range because the SS7 network will always deliver them to the SG to
which the ASP with the TID range has failed.

> I think this provides a valuable feature in SUA for message distribution

SLS is far better.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Haresign Lincoln" <[email-masked]>
Date: Thu, 29 Jun 2006 14:16:44 -0400

Brian,

For many of the CAMEL/INAP, GSM, and IS41 applications that we deploy,
there is an ongoing dialog (sometimes class 0, sometimes class 1) that
perfectly suits this use of TID routing.  SLS does not solve the problem
of class 0 and there are many applications with ongoing class 0 dialogs.
Also, SLS has other problems (see last paragraph).

I agree that TID does not solve the problem of calls spanning multiple
dialogs, however it's not designed to solve that problem.  It does solve
a set of problems (just like other features in the spec solve other
problems) and therefore it is a valid technology that should be used
where appropriate.

I'm not trying to make the argument that TID routing is the endall
solution for all applications.  I'm only answering Jain Saurabh that
this is a valid technolgy with a practical use that is being deployed in
networks to solve certain problems.  I won't go so far as to judge
whether these applications are trivial/uninteresting.  But I do know
that there is a fairly large market for these applications and this use
of the TID feature in SUA safely satisfies that area.  Obviously, TID
routing will only be used for ASPs that want that type of service.  If
you are running a non-TCAP application or an application with calls
spanning multiple dialogs, it would not send TID in the ASPAC and
another technique must be used.

I don't think SLS is a very good mechanism for routing all calls within
a dialog to the same ASP (at least not in ANSI networks).  While the
initiator of the call will always assign the same SLS value for class 0,
if there is a failure in the network, and the number of STPs that you
are routing through changes, the SLS value at the end point will change
since the STPs are rotating the SLS.  

The problem of call state being preserved is easily solved if you
implement a more redundant system..  When an ASP dies, a notify is sent
out, and another standby ASP can send an ASPAC with the TID value of the
failed ASP thereby solving your stated requirement from RFC3332 below.

Regards,
Lincoln

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Thursday, June 29, 2006 1:42 PM
To: Haresign Lincoln
Cc: Saurabh Jain; [email-masked]
Subject: Re: [Sigtran] SUA: Message distribution among Load Shared ASPs
(IPSPcase)

Lincoln,

Haresign Lincoln wrote:                         (Thu, 29 Jun 2006
13:14:44)
> ASPs).  And it specifies a range in the part of the TID that is built 
> by the ASP (local TID).
> 
> When a BEGIN arrives at the SG, it can be routed to any ASP (perhaps 
> in a round robin fashion).  For a CONTINUE or END, the TID would be 
> parsed and correctly routed to the ASP that is handling that call.

That would only work for the most trivial of services and is rather
uninteresting.  The purpose was to permit an ASP to maintain a set of
transaction states largely local.  For an _interesting_ service
application, such as GSM MAP, it is also necessary to send all linked
transactions to the same ASP (not just CONTINUE/QWOP), requiring parsing
of the application context or operation and the linked id at the SG.  In
fact better transaction state locality can be acheived by distributing
over the ASPs serving the AS based on Sequence (SLS value) because the
GSM entity will assign the same sequence value to CONTINUE/QWOP (because
they require protocol class 1) as well as linked operations (per GSM MAP
specifications).  Understand?  Another example, a CS/AIN SSP sends
UNIDIRECTIONAL messages to an SCP to indicate call release.  This
UNIDIRECTIONAL, of course, contains no TID, but it does contain a
correlation id (which would have to be parse).  However, CS/AIN, just as
GSM/MAP, sends the UNIDIRECTIONAL message with the same Sequnce Control
(SLS) as the transaction to which it correlates.  Good transaction state
locality, as well as best load balancing, can most easily be provided by
distribution based on SLS.

"  For carrier grade networks, the failure or isolation of a particular
"  signalling process should not cause stable calls or transactions to "
be lost.  This implies that signalling processes need, in some cases, "
to share the call/transaction state or be able to pass the call state "
information between each other.  In the case of ASPs performing call "
processing, coordination may also be required with the related Media "
Gateway to transfer the MGC control for a particular trunk "
termination. However, this sharing or communication of "
call/transaction state information is outside the scope of this "
document.

You are not going to get away with requiring the SG to provide complete
locality of state and better locality is afforded in practical
applications by load balancing based on SLS/Sequnce than is afforded by
TID Label and it does not require TCAP decoders, Application Part
contexts and ASE, nor TCAP/TCAP-User state machines.  It is immediately
avaiable in the MTP/SCCP portions of the received message.

> type).  This isn't really a TCAP stack, only a little decoding in the 

Linked IDs, and application contexts or operations are not trivial.
Also, you need to consider that TCAP is not the only SCCP user and SCCP
need not be aware of the nature of its users.  If your TID assignment
for distribution goes against SLS assignment rules for, say GSM MAP, one
ASP losing connectivity to an SG will result in failure of all
transactions in the TID range because the SS7 network will always
deliver them to the SG to which the ASP with the TID range has failed.

> 
> I think this provides a valuable feature in SUA for message 
> distribution within an AS.

SLS is far better.

--brian

--
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 29 Jun 2006 12:52:50 -0600

Lincoln,

Haresign Lincoln wrote:                     (Thu, 29 Jun 2006 14:16:44)
> another technique must be used.

You miss the current fundamental design principle for the SG/ASP relation
in load-share mode: each ASP must be prepared to receive any message as
the load sharing algorithm is completely at the discretion of the SG.  TID
label passes decision of the load sharing algorithm to the ASP from the SG.

There is a draft for doing that properly that includes TID and DRN values
for SUA as well as SLS values for M3UA.  The major difference is it includes
proceedures for registration and notification.  Then, if an ASP serving a
load selection fails within an AS, the SG pends on the load selection and
other ASPs serving the AS are notified as to the failed load selection range
so that they can agree which will pick up the load.

See
http://www.openss7.org/internet-drafts/draft-bidulock-sigtran-loadsel-04.txt

This draft was resubmitted on Monday, but missed the cutoff so it will not
hit the IETF servers until some time after the meeting on or about July 10th.

See also
http://www.openss7.org/internet-drafts/draft-bidulock-sigtran-loadgrp-04.txt
for a way to both stripe and mirror.

> since the STPs are rotating the SLS.  

You should know that not even the SS7 network can handle dual simultanous
associated STP failures:  the result would be TFP rather than routing
through a different number of STPs.

> failed ASP thereby solving your stated requirement from RFC3332 below.

The state machine at the SG does not pend on TID range, only on the entire
routing key.  It has no choice but to send those messages immediately to
some other ASP.

Again, see http://www.openss7.org/internet-drafts/draft-bidulock-sigtran-loadsel-04.txt

These drafts provide a complete mechanism, state transitions, registration,
error and notification procedures and represent a usable mechanism.  The TID
label in the SUA RFC was pushed in at the last moment and is half-baked to
say the least.  Along with then procedres are mechanisms for avoiding message
missordering and loss in
http://www.openss7.org/internet-drafts/draft-bidulock-sigtran-corid-06.txt

These drafts have been around for 4 years.  Perhaps you should take a look
at them sometime.

Without the complete set of procedures, someone might thing that they can get
away without sharing state between APS at all.  Without implementing the
LOADSEL draft, if your ASP design has much difficulty moving state between
ASPs, I suggest you move distribute messages between ASPs using your own TCAP
decoders and message distributors, that can more easily use things like TID
and linked ids and properly handle P-Aborts for malformed messages.  If a
message arrives at the wrong ASP, instead of moving the state to recieving
ASP, transfer the message to the ASP that owns the state.  It is something
that you will need to do anyway as the group concensus was that the TID label
procedure must be OPTIONAL.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 29 Jun 2006 13:06:15 -0600

Lincoln,

Brian F. G. Bidulock wrote:                  (Thu, 29 Jun 2006 12:52:50)

> http://www.openss7.org/internet-drafts/draft-bidulock-sigtran-corid-06.txt

Pardon me, that should be:

http://www.openss7.org/internet-drafts/draft-bidulock-sigtran-corid-04.txt

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Haresign Lincoln" <[email-masked]>
Date: Thu, 29 Jun 2006 15:25:46 -0400

Brian,

I would be happy to review your documents if/when they are distributed
throught the IETF as drafts (I think I said this about six months or so
ago).  In the interim, since TID routing is the only existing approved
solution, there's certainly no reason why people can't use/adopt it.  

There are a couple reason that immediately come to mind why SLS is not a
good mechanism.  The first is fact that SLS can change in an ANSI
network.  For example, if point code A is connected to point code B via
LINKSET F (direct F linkset) as well as LINKSET A1 and A2 (combined
linkset to a pair of STPs).  

Initially the call is going through LINKSET F (with no SLS rotation) and
when LS F fails, it goes through the STPs and now the SLS is rotated.
There are no TFPs, no STP failures, just a backhoe.

The second reason SLS is not good is that you are limited to either 16
or 32 ASPs (8 in some japanese networks).

Regards,
Lincoln

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Thursday, June 29, 2006 2:53 PM
To: Haresign Lincoln
Cc: Saurabh Jain; [email-masked]
Subject: Re: [Sigtran] SUA: Message distribution among Load Shared ASPs
(IPSPcase)

Lincoln,

> perfectly suits this use of TID routing.  SLS does not solve the 
> problem of class 0 and there are many applications with ongoing class
0 dialogs.

> dialogs, however it's not designed to solve that problem.  It does 
> solve a set of problems (just like other features in the spec solve 
> other
> this is a valid technolgy with a practical use that is being deployed 
> in networks to solve certain problems.  I won't go so far as to judge 
> that there is a fairly large market for these applications and this 
> use of the TID feature in SUA safely satisfies that area.  Obviously, 
> TID routing will only be used for ASPs that want that type of service.

> If you are running a non-TCAP application or an application with calls

> another technique must be used.

You miss the current fundamental design principle for the SG/ASP
relation in load-share mode: each ASP must be prepared to receive any
message as the load sharing algorithm is completely at the discretion of
the SG.  TID label passes decision of the load sharing algorithm to the
ASP from the SG.

There is a draft for doing that properly that includes TID and DRN
values for SUA as well as SLS values for M3UA.  The major difference is
it includes proceedures for registration and notification.  Then, if an
ASP serving a load selection fails within an AS, the SG pends on the
load selection and other ASPs serving the AS are notified as to the
failed load selection range so that they can agree which will pick up
the load.

See
http://www.openss7.org/internet-drafts/draft-bidulock-sigtran-loadsel-04
.txt

This draft was resubmitted on Monday, but missed the cutoff so it will
not hit the IETF servers until some time after the meeting on or about
July 10th.

See also
http://www.openss7.org/internet-drafts/draft-bidulock-sigtran-loadgrp-04
.txt
for a way to both stripe and mirror.

> 
> I don't think SLS is a very good mechanism for routing all calls 
> within a dialog to the same ASP (at least not in ANSI networks).  
> While the initiator of the call will always assign the same SLS value 
> for class 0, if there is a failure in the network, and the number of 
> STPs that you are routing through changes, the SLS value at the end 
> point will change since the STPs are rotating the SLS.

You should know that not even the SS7 network can handle dual
simultanous associated STP failures:  the result would be TFP rather
than routing through a different number of STPs.

> implement a more redundant system..  When an ASP dies, a notify is 
> sent out, and another standby ASP can send an ASPAC with the TID value

> of the failed ASP thereby solving your stated requirement from RFC3332
below.

The state machine at the SG does not pend on TID range, only on the
entire routing key.  It has no choice but to send those messages
immediately to some other ASP.

Again, see
http://www.openss7.org/internet-drafts/draft-bidulock-sigtran-loadsel-04
.txt

These drafts provide a complete mechanism, state transitions,
registration, error and notification procedures and represent a usable
mechanism.  The TID label in the SUA RFC was pushed in at the last
moment and is half-baked to say the least.  Along with then procedres
are mechanisms for avoiding message missordering and loss in
http://www.openss7.org/internet-drafts/draft-bidulock-sigtran-corid-06.t
xt

These drafts have been around for 4 years.  Perhaps you should take a
look at them sometime.

Without the complete set of procedures, someone might thing that they
can get away without sharing state between APS at all.  Without
implementing the LOADSEL draft, if your ASP design has much difficulty
moving state between ASPs, I suggest you move distribute messages
between ASPs using your own TCAP decoders and message distributors, that
can more easily use things like TID and linked ids and properly handle
P-Aborts for malformed messages.  If a message arrives at the wrong ASP,
instead of moving the state to recieving ASP, transfer the message to
the ASP that owns the state.  It is something that you will need to do
anyway as the group concensus was that the TID label procedure must be
OPTIONAL.

--brian

--
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 29 Jun 2006 13:41:55 -0600

Haresign,

Haresign Lincoln wrote:                                           (Thu, 29 Jun 2006 15:25:46)
> solution, there's certainly no reason why people can't use/adopt it.  

That last version of the drafts were published on the IETF servers in October
2005 and did not expire until May (just last month).  As six months was
obviously not sufficient time for you to review the drafts, they will appear
again for six months.  These drafts, in more or less their current form have
been available on the IETF servers on and off for 4 revisions (2 years each).
If you wait another 7 months to look at them on the IETF servers, they will
expire again.

> linkset to a pair of STPs).  

LOADSEL supports more than SLS (SI, CIC, TID, DLR, Address Range, and an
unlimited set of pre-arranged load selections).  Read the draft.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/