Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message

From: "Bhandari, Jitin (Jitin)" <[email-masked]>
Date: Wed, 1 Nov 2006 15:52:51 -0500

Brian,

No where in the RFC-3332, I understand the interpretation of CIC ranges is limited to Load Distribution. 

When CIC ranges were a part of Routing Key, they can very well be used for routing and be defined as a part of Routing key. Since, OPC-DPC-CIC values uniquely identify a resource on the ASP and can very well be treated is unique routing key from RFC definition. 

I very well understand when you talk about CIC & TID being just an element from Load Sharing perspective but for the same analogy if CIC & TID are for Load distribution, OPC can also be viewed as Load distribution method so as to have multiple ASPs (behind SG) handling parts of SS7 network. It is up-to anyone as how one vision Routing key arbitration at SG for MGC. Limiting the Routing Key definition at RFC level is not fair especially when it was talked about in previous RFC.

My point here is that by getting rid of such parameters at RFC level, we would face many inter-op issues with various vendors in the real work if one has to pick Dynamic Registration Path. We will only end up with many drafts like this one modifying the Registration Request message for handling of SS7 traffic at SG. Inter-op in real world would be a serious issue with such procedures then.

Also, as I mentioned in my previous email, CIC resources being dynamic in nature at MGC, a flow through dynamic provisioning support (from MGC to SG) was provided by having such Keys in the dynamic registration procedure. 

By getting rid of such parameters at RFC level, we are just making Dynamic Registration procedure un-usable.

-Jitin

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Wednesday, November 01, 2006 3:11 PM
To: Bhandari, Jitin (Jitin)
Cc: [email-masked]'
Subject: Re: [Sigtran] RFC 4666 M3UA - Reg Request Message

Jitin,

CIC and TID were only applicable to load distribution and not
routing and were therefore removed from the "routing" key.

See

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

for a equivalent mechanism for controlling load distribution based
on CIC using a "load" key dynamically registered in the REG REQ.

--brian

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

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

---

From: "Barry Nagelberg" <[email-masked]>
Date: Wed, 1 Nov 2006 16:11:03 -0500

All,

I agree with Jitlin - CIC range functionality should be put back into Dynamic Registration. After removing it to comply
to the spec, we had to put it back in because one of our customers demanded it.

In cases such as these, I suggest that try harder to listen to our customers - after all, they are the ones who are
paying for SIGTRAN to be actually implemented and deployed.

Barry Nagelberg
Adax, Inc.

-----Original Message-----
From: Bhandari, Jitin (Jitin) [mailto:[email-masked]]
Sent: Wednesday, November 01, 2006 3:53 PM
To: [email-masked]'
Cc: [email-masked]'
Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message

Brian,

When CIC ranges were a part of Routing Key, they can very well be used for routing and be defined as a part of Routing
key. Since, OPC-DPC-CIC values uniquely identify a resource on the ASP and can very well be treated is unique routing
key from RFC definition.

I very well understand when you talk about CIC & TID being just an element from Load Sharing perspective but for the
same analogy if CIC & TID are for Load distribution, OPC can also be viewed as Load distribution method so as to have
multiple ASPs (behind SG) handling parts of SS7 network. It is up-to anyone as how one vision Routing key arbitration at
SG for MGC. Limiting the Routing Key definition at RFC level is not fair especially when it was talked about in previous
RFC.

My point here is that by getting rid of such parameters at RFC level, we would face many inter-op issues with various
vendors in the real work if one has to pick Dynamic Registration Path. We will only end up with many drafts like this
one modifying the Registration Request message for handling of SS7 traffic at SG. Inter-op in real world would be a
serious issue with such procedures then.

Also, as I mentioned in my previous email, CIC resources being dynamic in nature at MGC, a flow through dynamic
provisioning support (from MGC to SG) was provided by having such Keys in the dynamic registration procedure.

-Jitin

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Wednesday, November 01, 2006 3:11 PM
To: Bhandari, Jitin (Jitin)
Cc: [email-masked]'
Subject: Re: [Sigtran] RFC 4666 M3UA - Reg Request Message

Jitin,

See

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 1 Nov 2006 14:22:24 -0700

Jitin,

There are no procedures for CIC in RFC 3332 either: just the parameter,
leading to non-interoperable implementations.  Although one can conceive
of fashions in which to use it, there are many non-interoperable
interpretations of how that could be done.  I figured that either we
should describe an interoperable solution or remove it.  The WG decided
to remove it and address it in an extension draft.

draft-bidulock-sigtran-loadsel-04.txt is such an extension draft that
describes an interoperable solution and is a good starting point for
providing this functionality and has been avialable for years.  It
seems that implementors have preferred to provide their own proprietary
solutions rather than advancing and contributing to a common standard
solution.

--brian

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Thu, 2 Nov 2006 14:28:37 -0500

It certainly would be a nice feature.  But there are a large number of
ISUP scenarios that would need to be covered.  For example, if you loose
all ASPs handing a certain CIC range, do you BLO?  Anyway, it seems to
me that this is almost too much for M3UA and almost requires a new
extension specifically for ISUP.

Regards,
Lincoln

-----Original Message-----
From: Barry Nagelberg [mailto:[email-masked]] 
Sent: Wednesday, November 01, 2006 4:11 PM
To: [email-masked]
Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message

All,

I agree with Jitlin - CIC range functionality should be put back into
Dynamic Registration. After removing it to comply to the spec, we had to
put it back in because one of our customers demanded it.

In cases such as these, I suggest that try harder to listen to our
customers - after all, they are the ones who are paying for SIGTRAN to
be actually implemented and deployed.

Barry Nagelberg
Adax, Inc.

-----Original Message-----
From: Bhandari, Jitin (Jitin) [mailto:[email-masked]]
Sent: Wednesday, November 01, 2006 3:53 PM
To: [email-masked]'
Cc: [email-masked]'
Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message

Brian,

No where in the RFC-3332, I understand the interpretation of CIC ranges
is limited to Load Distribution.

When CIC ranges were a part of Routing Key, they can very well be used
for routing and be defined as a part of Routing key. Since, OPC-DPC-CIC
values uniquely identify a resource on the ASP and can very well be
treated is unique routing key from RFC definition.

I very well understand when you talk about CIC & TID being just an
element from Load Sharing perspective but for the same analogy if CIC &
TID are for Load distribution, OPC can also be viewed as Load
distribution method so as to have multiple ASPs (behind SG) handling
parts of SS7 network. It is up-to anyone as how one vision Routing key
arbitration at SG for MGC. Limiting the Routing Key definition at RFC
level is not fair especially when it was talked about in previous RFC.

My point here is that by getting rid of such parameters at RFC level, we
would face many inter-op issues with various vendors in the real work if
one has to pick Dynamic Registration Path. We will only end up with many
drafts like this one modifying the Registration Request message for
handling of SS7 traffic at SG. Inter-op in real world would be a serious
issue with such procedures then.

Also, as I mentioned in my previous email, CIC resources being dynamic
in nature at MGC, a flow through dynamic provisioning support (from MGC
to SG) was provided by having such Keys in the dynamic registration
procedure.

By getting rid of such parameters at RFC level, we are just making
Dynamic Registration procedure un-usable.

-Jitin

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Wednesday, November 01, 2006 3:11 PM
To: Bhandari, Jitin (Jitin)
Cc: [email-masked]'
Subject: Re: [Sigtran] RFC 4666 M3UA - Reg Request Message

Jitin,

CIC and TID were only applicable to load distribution and not routing
and were therefore removed from the "routing" key.

See

http://www.ietf.org/internet-drafts/draft-bidulock-sigtran-loadsel-04.tx
t

for a equivalent mechanism for controlling load distribution based on
CIC using a "load" key dynamically registered in the REG REQ.

--brian

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