Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
7.0 CLID RfD (was: Bug or feature? (was (ASCEND) Doing CLID with 7.0.0 (possible ?)))
Re,
On Mon, Dec 07, 1998 at 01:06:44AM +0100, Oliver J. Albrecht wrote:
> In article <a07a3a826129@news.allcon.net> you wrote:
> >> AFAIK, Ascend planned to change the effects of this switch in
> >> that direction, which you see now. The philosophy seems to be "NACK means
> >> NACK". So if you get the CLID from an incoming user and there is no
> >> profile for this number - there is no chance for the user to log in.
>
> >This is nonsense. It breaks the NAS for probably every second ISP in
> >the world. Please remember that ISDN is still a european and especially
> >german domain, IIRC Germany has 30% of all ISDN endpoints worldwide.
> >Ignoring this market by breaking such _basic_ functionality almost
> >every ISP here is using daily and is requiring for proper operations
> >is beyond stupidity.
>
> Unfortunately what Marc wrote is true. I received a call from someone
> with Ascend last week, describing the exact cause that led to this "bug".
> Apparently the feature itself (ID Auth=Prefer) is based on a customer
> request that dates back many releases. The way ID Auth=Prefer was done
> never really met the customers requirements, so someone decided to
> do it "right" in the latest releases. The way I understand it, is that
> the people who changed the feature were not aware of the way it is
> currently being used by many ISP's across Europe.
Looks like that. And I'd say: looks like Ascend. Who has a special
way of implementing things in a strange or incomplete way, probably
for exactly one reason: it is done when some customer says he wants
it. Not that it would be wrong to implement features on customers
demand, my goodness, no - but if one implements something I would
expect it is first analyzed, the problem is isolated, a plan is made
how the feature can be made available in an orthogonal way that fits
both ITU standards, RFC standards and standards-to-come as well as
common sense and telco/ISP market background knowledge. If all this
is done an one knows how such feature would best be fit into the
existing world, it is than analyzed how the feature would best fit
into the existing implementation in a way that doesn't break things
that worked before, keeps old default setups etc. The final step
is actually implementing it. Sad enough, Ascend seems to not think
orthogonal in many cases. Why do I need Nailed/Mpp in order to bundle
two nailed lines ? MP would completely suffice, but it is not done
orthogonal. A box that doesn't implement proper TOS queuing but has
esoteric features like TOS patching is not orthogonal. The multicast
implementation is not orthogonal - at least not to me. Generally
the implementation has arbitrary limitations and missing links that
just don't make sense. Thats what bugs me, and creates the very special
name that Ascend has in the ISP world (besides from pure trivial
bashing, there are really interesting voices about Ascend in the ISP
scene).
Let's come to the point: Id auth and sequencing of different auth
means is one of the features which drop into the missing orthogonaly
hole since supplied. Finally with 5.x and the change from CLID auth
into Id Auth the whole thing became very esoteric to me, even repeated
reading of certain passages in the docs didn't make clear how exactly
it is planned to work. Thus everyone had to "try it out" (to cite a
great scientist) and came to a solution that fit his needs. For us here
in germany who need to authenticate some peers by CLID and others with
inband auth, however those others are very likely to supply (unknown
and irrelevant) CLIDs, too, the solution was "Id auth=Prefer" which
implemented the fallback. Changing this behavior now is just a sign
of missing ortho... - you know.
RfD:
A starting point for implementing the whole mess a bit more orthogonal:
1) Remove Id Auth
2) Introduce new Parameter Auth Sequence (let's call it AS)
AS=Caller
Behaves like Id Auth=Prefer did. Auth by CLID, if it fails for what-
ever reason, refuse call.
AS=Called
Unconditionally route to a profile based on called number. Not very
flexible, but stay tuned.
AS=Inband
Ignore any Numbers. Accept and auth inband.
So far so good. Now let's implement fallbacks:
AS=Caller,Inband
Try to auth by CLID first. Fallback to Inband if CLID fails.
AS=Caller,Called,Inband
An example of merging Called # auth into it. AFAIK this is not
possible with the current TAOS.
AS=Called,Caller,Inband
Another prioritization
AS=Caller,Called
No inband auth if Id auth fails
[... other possibly useful combinations ...]
Now we still have a problem. The change of Id Auth=Prefer to a new
philosophy has some reason. Therefore a new concept needs to be able
to implement a way to fulfill this need. The basic point is, we want
to differ between two ways an auth can fail in: because the auth was
denied or because the question failed. If you know nsswitch.conf on
certain Unixes, they have a [notfound=return] clause to differ between
a name service that doesn't answer (or cannot be asked for some reason)
and a name service that was successfully asked, but returned a NACK.
For ideal orthogonality, I would like to be able to specify this
wherever I want. A good means would be a different punctuation, let's
say a ";" for "fallback only when the service failed" while "," means
"fallback if the query failed for either reason, service unreachable
or service NACKed". To exemplify:
AS=Caller;Inband
Would do what 7.0b7/7.0.0 Id Auth=Prefer do: Auth by Caller Id if
CLID is present. If the auth is NACKed, refuse. If, however, no
CLID is available in the SETUP, fall back to Inband.
AS=Caller;Called,Inband
If a CLID is there at all, it must match or we refuse. However,
if no CLID is there, we either route to some profile based on
the number called, or if the number called has no special profile
or was not presented, we finally go inband anyway.
[... more combos ...]
<warning> This is guesswork I invented just upon typing this mail,
it will not constitute a complete solution. Count it as an RfD about
that, before Ascend hacks another hard to interpret mode into the
Id Auth= parameter (guess they call it german suckers mode ;)
</warning>
Andre.
--
"the big bang: the ultimate hero of low frequency;
the divine intergalactical bassdrum" -- Yello, "solar driftwood"
+-o-+--------------------------------------------------------+-o-+
| o | \\\- Brain Inside -/// | o |
| o | ^^^^^^^^^^^^^^ | o |
| o | Andre' Beck (ABPSoft) AB10-RIPE Xlink PoP Dresden | o |
+-o-+--------------------------------------------------------+-o-+
++ Ascend Users Mailing List ++
To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd: <http://www.nealis.net/ascend/faq>