Subject: Re: Supplying only a port on a ServiceChangeAddress

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 6 Sep 2000 14:11:38 -0400

OK, I'd say we have consensus on the following:

(1) As oft repeated, the mId designates a peer in a control session.  It
does not change even if the addresses used in the session change.  Different
port addresses could be used to designate different virtual MGs, but this is
a local implementation issue.

I'm assuming here that you mean mId, the thing that goes in every message,
and that there is no arbitrary changing of it - changes get signalled in
ServiceChange.  mId serves to identify which association this message refers
to.  Given those caveats, I agree.

(2) ServiceChangeAddress can be used to change the address to which the peer
sends requests within the existing control session.  The ABNF syntax of
ServiceChangeAddress is VALUE, which permits designation of a port only
within a quoted string.  The difference between this and the ASN.1 syntax is
what started this whole thread, but is irrelevant because the functionality
is still available.  There is the legitimate question of whether the
ServiceChangeAddress functionality is needed.  I'm not sure I have consensus
to deprecate use of ServiceChangeAddress.

I'd like to see if we could develop a consensus, but I can live with it.

I'm still concerned about the difficulty of changing address, or port, with
TCP transport.  We need at least a note of caution in the Implementers
Guide.

(3) ServiceChangeMGgcId is used to redirect the control session.  The ABNF
type of ServiceChangeMgcId is MId, which presumably is why MId is so
carefully developed as an address.

Yes!

There is an open issue regarding TCP.  That is, is everyone prepared to
accept the restriction Bharat wants to place on TCP, to the effect that the
MG is never a listener?

Yes!

Brian

> -----Original Message-----
> From: Flemming Andreasen [ mailto:[email-masked]
<mailto:[email-masked]> ]
> Sent: Wednesday, September 06, 2000 10:39 AM
> To: Rosen, Brian; Taylor, Tom-PT [NORSE:B901:EXCH]; Bharat Kaul
> Cc: [email-masked]
> Subject: Re: Supplying only a port on a ServiceChangeAddress
>
>
> So do we have any consensus resolution on this issue ?
>
> -- Flemming
>
> "Rosen, Brian" wrote:
>
> > Yeah, the mId started life as the thing in the header that let an
> > MGC know which entity it was talking to.  It's always been an
> > address though - desirable as an FQDN and acceptable to be a hard
> > address.
> >
> > The intention of ServiceChangeMid was to be the referral
> address for an
> > association that was not acceptable to the MGC.
> ServiceChangeAddress used
> > to be port, and it was just for changing port numbers, not
> addresses.  We
> > went downhill (IMO) from there.
> >
> > I'm with Flemming, one thing is all we need, but we are
> stuck with 2 for
> > now.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Tom-PT Taylor [ mailto:[email-masked]
<mailto:[email-masked]> ]
> > > Sent: Tuesday, September 05, 2000 3:16 PM
> > > To: [email-masked]
> > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > >
> > >
> > > I think we agree that MId is just an identifier of a peer
> in a control
> > > session.  I still ask myself why we defined it to be an
> > > address rather than
> > > an arbitrary string.  I suspect we changed intentions since
> > > it first showed
> > > up.
> > >
> > > > -----Original Message-----
> > > > From: Flemming Andreasen [ mailto:[email-masked]
<mailto:[email-masked]> ]
> > > > Sent: Tuesday, September 05, 2000 3:12 PM
> > > > To: [email-masked]
> > > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > > >
> > > >
> > > > Bharat Kaul wrote:
> > > >
> > > > > Hi Flemming, Brian and List,
> > > > >
> > > > >   ServiceChangeMGCId should be kept for contacting a new
> > > > MGC or rather
> > > > > establishing new control Session.
> > > > >
> > > > > ServiceChangeAddress is for redirection within a MGC e.g.
> > > > MG contacts MGC at
> > > > > a default port and based on some policy MGC wants to assign
> > > > MG to a specific
> > > > > port, it should send ServiceChangeAddress specifying the
> > > > port.These two
> > > > > semantics seem clear and fair enough.
> > > >
> > > > I quite frankly don't understand the need for having port as
> > > > an identifier and
> > > > then being able to specify another port to override it, while
> > > > keeping the
> > > > identifier port the same.
> > > >
> > > >
> > > > >
> > > > >
> > > > > Port in MID should be just a tool to identify an entity
> > > > uniquely, with one
> > > > > requirement that MID for a control session is consistent
> > > between two
> > > > > entities.
> > > >
> > > > In that case it should be called something different than a
> > > > port, or at least be
> > > > treated as something different.
> > > >
> > > > -- Flemming
> > > >
> > > >
> > > > >
> > > > >
> > > > > - Bharat
> > > > >
> > > > > -----Original Message-----
> > > > > From: Flemming Andreasen [ mailto:[email-masked]
<mailto:[email-masked]> ]
> > > > > Sent: Tuesday, September 05, 2000 8:29 AM
> > > > > To: [email-masked]
> > > > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > > > >
> > > > > Let's take a step back here and ask ourselves what we are
> > > > trying to achieve:
> > > > >
> > > > > 1. We have a need to identify the entity we wish to
> > > communicate with
> > > > > 2. We have a need to communicate with that entity.
> > > > >
> > > > > This is a classical naming issue that doesn't need to
> > > become overly
> > > > > complicated. In order to get from the name in 1 to the
> > > > address (or route) in
> > > > > 2, you need to perform name resolution in the cases where
> > > > the name itself is
> > > > > not an address. For domain names, this name resolution is
> > > > achieved by DNS,
> > > > > for IP-addresses, it should normally be a NOP. By having both
> > > > > ServiceChangeMGGId and ServiceChangeAddress, you are
> > > > effectively providing
> > > > > an alternate name resolution mechanism which overrides DNS
> > > > and allows one
> > > > > IP-address to map to another. We should not be doing that,
> > > > and I also note
> > > > > that this was probably not the authors' intent, since
> > > > ServiceChangeAddress
> > > > > and ServiceChangeMGCId are not both allowed in a
> single command.
> > > > >
> > > > > That still leaves open the question of exactly what
> > > > ServiceChangeAddress
> > > > > then is, and I believe Brian answered that earlier with his
> > > > two proposals.
> > > > > In a perfect world, I would prefer getting rid of
> > > > ServiceChangeAddress, but
> > > > > we may be beyond that. Does it make sense to allow just a
> > > > port number then ?
> > > > > Considering that we already allow for port in mId, port is
> > > > part of the name
> > > > > and for the same reasons as we shouldn't map one IP-address
> > > > to another, we
> > > > > shouldn't map one port to another either IMO. If the MGC
> > > > (or MG) wants the
> > > > > other party to talk to it on another port, it simply sends
> > > > back another
> > > > > ServiceChangeMGCId with that port number in it.
> > > > >
> > > > > -- Flemming
> > > > >
> > > > > "Rosen, Brian" wrote:
> > > > >
> > > > > > It depends on what you want to have happen.
> > > > > >
> > > > > > If you want the MG, on receipt of a reply with a
> > > > ServiceChangeAddress,
> > > > > > to tear down it's current transport connection, create
> > > a new one,
> > > > > > and stand by for messages from the MGC, then I suppose
> > > > you would be
> > > > > > correct.
> > > > > >
> > > > > > If it was TCP (and I guess SCTP), this is pretty weird,
> > > > because the
> > > > > > MG established a full duplex connection, but the
> next message is
> > > > > > almost certainly from the MGC.  The MGC is going to have
> > > > to watch for
> > > > > > this carefully, and not send messages until the new
> > > channel is up.
> > > > > >
> > > > > > Or, the MGC can just use ServiceChangeMid.  The MG will
> > > respond by
> > > > > > tearing down the transport, establishing a new one,
> and sending
> > > > > > a new ServiceChange.  The MGC "fires and forgets" -- the new
> > > > > > ServiceChange, at the "new" address, looks like a
> > > > complete new start.
> > > > > >
> > > > > > Brian
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Christian Groves
> > > > > > To: [email-masked]
> > > > > > Sent: 9/3/00 7:38 PM
> > > > > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > > > > >
> > > > > > G'Day Brian and Flemming,
> > > > > >
> > > > > > I saw that the difference between when you use
> > > > ServiceChangeAddress and
> > > > > > ServiceChangeMid was that the ServiceChangeAddress was
> > > > used when talking
> > > > > > to an already contacted physical MGC. The
> > > > ServiceChangeMid was used to
> > > > > > contact a physically seperate MGC. So I don't see
> the need of
> > > > > > disallowing anything but the port in IP as the MGC may
> > > > have a range of
> > > > > > addresses.
> > > > > >
> > > > > > Cheers, Christian
> > > > > >
> > > > > > "Rosen, Brian" wrote:
> > > > > > >
> > > > > > > I thought you might say that, I've been thinking about it
> > > > > > > since I sent the message.
> > > > > > >
> > > > > > > Posing the question slightly differently, if the
> > > > ServiceChangeAddress
> > > > > > > can do what ServiceChangeMid can do, so why have two
> > > mechanisms?
> > > > > > > The only difference would be the MGs actions.  If you used
> > > > > > > ServiceChangeAddress,
> > > > > > > the MG would not send a new ServiceChange command to
> > > > the new address.
> > > > > > > If you used ServiceChangeMid, it would.  The end result
> > > > would be the
> > > > > > same.
> > > > > > >
> > > > > > > We can:
> > > > > > >         Explicitly disallow ServiceChangeAddress from
> > > > being used to
> > > > > > >                 change anything but IP Port when
> used with IP
> > > > > > >         Get rid of one of the two of them
> > > > > > >
> > > > > > > I favor the former, as that is easiest, is most
> > > consistent with
> > > > > > > history, and makes the most sense to me.  I'll
> note that what
> > > > > > > we call ServiceChangeAddress used to be "port".  It got
> > > > > > > changed when we realized "port" wouldn't make
> sense if it was
> > > > > > > not an IP transport.
> > > > > > >
> > > > > > > Brian
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Flemming Andreasen [ mailto:[email-masked]
<mailto:[email-masked]> ]
> > > > > > > > Sent: Tuesday, August 29, 2000 7:37 PM
> > > > > > > > To: Rosen, Brian
> > > > > > > > Cc: [email-masked]
> > > > > > > > Subject: Re: Supplying only a port on a
> ServiceChangeAddress
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > "Rosen, Brian" wrote:
> > > > > > > >
> > > > > > > > > I think the issue is that you can have the same MGC
> > > > have multiple
> > > > > > > > > IP addresses.  You accept the association, but
> > > > change the address.
> > > > > > > > > Say, a pool of servers appearing to be one MGC.
> > > > > > > >
> > > > > > > > I'm not sure I fully understand what an
> association is then.
> > > > > > > > What's the
> > > > > > > > difference/relationship between the association
> > > > address and the
> > > > > > > > ServiceChangeMgcId (which may itself contain an
> address or
> > > > > > indirectly
> > > > > > > > refer to a number of addresses through DNS) ?
> > > > > > > >
> > > > > > > > -- Flemming
> > > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Brian
> > > > > > > > >
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: Flemming Andreasen [ mailto:[email-masked]
<mailto:[email-masked]> ]
> > > > > > > > > > Sent: Tuesday, August 29, 2000 6:38 PM
> > > > > > > > > > To: Rosen, Brian
> > > > > > > > > > Cc: [email-masked]
> > > > > > > > > > Subject: Re: Supplying only a port on a
> > > > ServiceChangeAddress
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > "Rosen, Brian" wrote:
> > > > > > > > > >
> > > > > > > > > > > Suppose all you want to specify in a
> > > > ServiceChangeAddress
> > > > > > > > > > is a port number
> > > > > > > > > > > that is, the IP address doesn't change, but the
> > > > port does.
> > > > > > > > > > >
> > > > > > > > > > > The ABNF sez:
> > > > > > > > > > > serviceChangeAddress =
> > > > ServiceChangeAddressToken EQUAL VALUE
> > > > > > > > > > >
> > > > > > > > > > > This is because it could be IP, ATM, FR, MPLS....
> > > > > > > > > > >
> > > > > > > > > > > The example shows just a port number.
> > > > > > > > > >
> > > > > > > > > > Actually, I thought that's all that would be
> > > > allowed in the
> > > > > > > > > > case of IP. If
> > > > > > > > > > not, how can it be within the "context of the
> > > association
> > > > > > > > > > currently being
> > > > > > > > > > negotiated", and how would it then relate to
> > > > ServiceChangeMgcId
> > > > > > ?
> > > > > > > > > >
> > > > > > > > > > -- Flemming
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Should that be legal?  Should you have to
> > > specify the IP
> > > > > > address
> > > > > > > > > > > as x.x.x.x:p?
> > > > > > > > > > >
> > > > > > > > > > > Brian
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Flemming Andreasen
> > > > > > > > > > Cisco Systems
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Flemming Andreasen
> > > > > > > > Cisco Systems
> > > > > > > >
> > > > > > > >
> > > > >
> > > > > --
> > > > > Flemming Andreasen
> > > > > Cisco Systems
> > > >
> > > > --
> > > > Flemming Andreasen
> > > > Cisco Systems
> > > >
> > >
>
> --
> Flemming Andreasen
> Cisco Systems
>
>
>

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 6 Sep 2000 15:59:42 -0400

"Rosen, Brian" wrote:

>      (1) As oft repeated, the mId designates a peer in a control
>      session.  It does not change even if the addresses used in
>      the session change.  Different port addresses could be used
>      to designate different virtual MGs, but this is a local
>      implementation issue.
>
>      I'm assuming here that you mean mId, the thing that goes in
>      every message, and that there is no arbitrary changing of it
>      - changes get signalled in ServiceChange.  mId serves to
>      identify which association this message refers to.  Given
>      those caveats, I agree.
>

I agree too (but with some assumptions as to when and how that address
can change)

>
>
>      (2) ServiceChangeAddress can be used to change the address
>      to which the peer sends requests within the existing control
>      session.  The ABNF syntax of ServiceChangeAddress is VALUE,
>      which permits designation of a port only within a quoted
>      string.  The difference between this and the ASN.1 syntax is
>      what started this whole thread, but is irrelevant because
>      the functionality is still available.  There is the
>      legitimate question of whether the ServiceChangeAddress
>      functionality is needed.  I'm not sure I have consensus to
>      deprecate use of ServiceChangeAddress.
>
I say we dump it. If that's unacceptable, we restrict it to port numbers
only (for IP transport) - no IP addresses here please.

>
>
>      I'm still concerned about the difficulty of changing
>      address, or port, with TCP transport.  We need at least a
>      note of caution in the Implementers Guide.
>
>      (3) ServiceChangeMGgcId is used to redirect the control
>      session.  The ABNF type of ServiceChangeMgcId is MId, which
>      presumably is why MId is so carefully developed as an
>      address.
>
>      Yes!
>
Agree

>
>
>      There is an open issue regarding TCP.  That is, is everyone
>      prepared to accept the restriction Bharat wants to place on
>      TCP, to the effect that the MG is never a listener?
>
>      Yes!
>

Given the current protocol specification/operation that seems
reasonable. If we were to accept ServiceChange initiated from the MGC,
it would obviously change.

-- Flemming

>      > From: Flemming Andreasen [mailto:[email-masked]]
>      > > > From: Tom-PT Taylor [mailto:[email-masked]]
>
>      > > > > From: Flemming Andreasen [mailto:[email-masked]]
>
>      > > > > > From: Flemming Andreasen
>      [mailto:[email-masked]]
>      > > > > > > > > From: Flemming Andreasen
>      [mailto:[email-masked]]
>      > > > > > > > > > > From: Flemming Andreasen
>      [mailto:[email-masked]]
--
Flemming Andreasen
Cisco Systems

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 6 Sep 2000 16:24:52 -0400

Kevin Boyle wrote:

> Flemming Andreasen wrote:
>
>>
>>
>> "Rosen, Brian" wrote:
>>
>> >
>> >
>> >      (1) As oft repeated, the mId designates a peer in a
>> >      control session.  It does not change even if the
>> >      addresses used in the session change.  Different port
>> >      addresses could be used to designate different virtual
>> >      MGs, but this is a local implementation issue.
>> >
>> >      I'm assuming here that you mean mId, the thing that goes
>> >      in every message, and that there is no arbitrary changing
>> >      of it - changes get signalled in ServiceChange.  mId
>> >      serves to identify which association this message refers
>> I agree too (but with some assumptions as to when and how that
>> address can change)
>>
>> >
>> >
>> >      (2) ServiceChangeAddress can be used to change the
>> >      address to which the peer sends requests within the
>> >      existing control session.  The ABNF syntax of
>> >      ServiceChangeAddress is VALUE, which permits designation
>> >      of a port only within a quoted string.  The difference
>> >      between this and the ASN.1 syntax is what started this
>> >      whole thread, but is irrelevant because the functionality
>> >      is still available.  There is the legitimate question of
>> >      whether the ServiceChangeAddress functionality is
>> >      needed.  I'm not sure I have consensus to deprecate use
>> >      of ServiceChangeAddress.
>> >
>> I say we dump it. If that's unacceptable, we restrict it to port
>> numbers only (for IP transport) - no IP addresses here please.
>>
>> >
>> >
>> >      session.  The ABNF type of ServiceChangeMgcId is MId,
>> >      which presumably is why MId is so carefully developed as
>> >      an address.
>> >
>> >      Yes!
>> >
>> Agree
>>
>> >
>> >
>> >      There is an open issue regarding TCP.  That is, is
>> >      everyone prepared to accept the restriction Bharat wants
>> >      to place on TCP, to the effect that the MG is never a
>> >      listener?
>> >
>> >      Yes!
>> >
>>
>> reasonable. If we were to accept ServiceChange initiated from the
>> MGC, it would obviously change.
>>
>
> ServiceChange *can* be initiated by the MGC.  Section 11.5 talks about
> exactly this scenario in the "Handoff" case.
>

Sorry - I meant control association establishment

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: Kevin Boyle <[email-masked]>
Date: Wed, 6 Sep 2000 16:07:27 -0400

"Rosen, Brian" wrote:

OK,
I'd say we have consensus on the following:

(1) As oft repeated, the mId designates a peer in a control
session.  It does not change even if the addresses used in the session
change.  Different port addresses could be used to designate different
virtual MGs, but this is a local implementation issue.

I'm
assuming here that you mean mId, the thing that goes in every message,
and that there is no arbitrary changing of it - changes get signalled in
ServiceChange.  mId serves to identify which association this message
refers to.  Given those caveats,
I agree.

(2) ServiceChangeAddress can be used to change the address
to which the peer sends requests within the existing control session.
The ABNF syntax of ServiceChangeAddress is VALUE, which permits designation
of a port only within a quoted string.  The difference between this
and the ASN.1 syntax is what started this whole thread, but is irrelevant
because the functionality is still available.  There is the legitimate
question of whether the ServiceChangeAddress functionality is needed.
I'm not sure I have consensus to deprecate use of ServiceChangeAddress.

I'd
like to see if we could develop a consensus, but I can live with it.

I'm
still concerned about the difficulty of changing address, or port, with
TCP transport.  We need at least a note of caution in the Implementers
Guide.

(3) ServiceChangeMGgcId is used to redirect the control
session.  The ABNF type of ServiceChangeMgcId is MId, which presumably
is why MId is so carefully developed as an address.

Yes!

Agree

There is an open issue regarding TCP.  That is, is
everyone prepared to accept the restriction Bharat wants to place on TCP,
to the effect that the MG is never a listener?

Yes!

Given the current protocol specification/operation that seems reasonable.
If we were to accept ServiceChange initiated from the MGC, it would obviously
change.

- Kevin

-- Flemming

Brian

[ major clippage! ]

--

Flemming Andreasen

Cisco Systems