Subject: RE: [midcom] Evaluation: COPS and session initialisation

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 22 Oct 2002 08:51:14 -0400

I think the proposal is that the agent be the one to initiate the session,
as per the requirements, even if it contradicts the COPS-PR design
philosophy.  The confusion arises because, as I read Kwok-Ho's note, the
first half says this is possible but then the second half goes on to discuss
the arrangement you have been expressing concerns about.

> -----Original Message-----
> From: Juergen Quittek [mailto:[email-masked]] 
> Sent: Tuesday, October 22, 2002 3:39 AM
> To: Taylor, Tom-PT [CAR:B602:EXCH]; Chan, Kwok-Ho 
> [BL60:470:EXCH]; Martin Stiemerling
> Cc: Aoun, Cedric [GOLF:MA01:EXCH]; [email-masked]'
> Subject: RE: [midcom] Evaluation: COPS and session initialisation
> 
> 
> Tom,
> 
> -- Tom-PT Taylor wrote on 21 October 2002 18:21 -0400:
> > I think we are agreed on the basic requirement: establishment and 
> > takedown of MIDCOM sessions must not require manual intervention or 
> > maintenance outage of the equipment.  There is the policy aspect of 
> > MIDCOM session and failover management as described in the 
> framework, 
> > but I don't think that is what we are discussing here.
> 
> The point I could not understand so far, is how to meet this 
> requirement (without additional support from additional 
> protocols) when the middlebox (and not the agent) is the 
> party that requests opening a midcom session.
> 
>     Juergen
> 
> 
> >> -----Original Message-----
> >> From: Juergen Quittek [mailto:[email-masked]]
> >> Sent: Monday, October 21, 2002 6:04 PM
> >> To: Taylor, Tom-PT [CAR:B602:EXCH]; Chan, Kwok-Ho [BL60:470:EXCH]; 
> >> Martin Stiemerling
> >> Cc: Aoun, Cedric [GOLF:MA01:EXCH]; [email-masked]'
> >> Subject: RE: [midcom] Evaluation: COPS and session initialisation
> >>
> >>
> >> Tom,
> >>
> >> I'm not sure how "administration" is exactly defined, but
> >> if you don't provide some additional non-midcom support
> >> for automatically configuring the midbox with the list of 
> agents to 
> >> establish connections to, then the administrator might need to 
> >> configure the the middlebox manually.
> >>
> >> This becomes extramely entertaining, if you disable a 
> service, let's 
> >> say IP telephony for asome hours for maintenance. How would after 
> >> maintenence hours the middlebox learn that the agent is up 
> again and 
> >> that a new session should be established. I hope not by manual 
> >> interaction between middlebox and administrator.
> >>
> >>     Juergen
> >>
> >>
> >> -- Tom-PT Taylor wrote on 21 October 2002 17:06 -0400:
> >>
> >> > "Configuration" is just a word.  If you said
> >> "administration" I would
> >> > be more worried, because that implies cost.
> >> >
> >> >> -----Original Message-----
> >> >> From: Juergen Quittek [mailto:[email-masked]]
> >> >> Sent: Monday, October 21, 2002 4:27 PM
> >> >> To: Chan, Kwok-Ho [BL60:470:EXCH]; Martin Stiemerling
> >> >> Cc: Aoun, Cedric [GOLF:MA01:EXCH]; [email-masked]'
> >> >> Subject: Re: [midcom] Evaluation: COPS and session 
> initialisation
> >> >>
> >> >>
> >> >> Kwok,
> >> >>
> >> >> -- Kwok Ho Chan wrote on 21 October 2002 15:08 -0400:
> >> >>
> >> >> > Martin, All:
> >> >> > I will try to answer your question. As we have already
> >> >> identified in the protocol evaluation document,
> >> >> >    "COPS does not meet the directionality part of the
> >> >> requirement.  The definition of COPS
> >> >> >     allows a PEP (Middlebox) to establish communication
> >> with a PDP
> >> >> > (MIDCOM Agent)." But, we added the following explanations:
> >> >> >    "However, nothing explicitly prohibits a PDP from
> >> >> establishing communication with a
> >> >> >     PEP. The PEP could have local policies dictating what
> >> >> action to take when it is
> >> >> >     contacted by an unknown PDP. These actions, defined in
> >> >> the local policies, would
> >> >> >     ensure the proper establishment of an authorized
> >> association. "
> >> >>
> >> >> Yes, I think this is exactly the point. You can create a
> >> framework,
> >> >> for example using policies, for initiating the 
> association between 
> >> >> middlebox and agent. You also can use a new Midcom Session
> >> Initiation
> >> >> Protocol to be used by the agent for telling the
> >> middlebox: "Please
> >> >> contact me for establishing a midcom session".
> >> >>
> >> >> The question is, whether this would be a good choice 
> considering 
> >> >> operational issues. I see service installation, 
> modification and 
> >> >> removal to be much more dynamic than middlebox installation, 
> >> >> modification and removal. Therefore, I consider it an 
> operational 
> >> >> disadvantage having to configure the middlebox each time a
> >> service is
> >> >> installed, is modified (changes the failover sequence), or is 
> >> >> removed.
> >> >>
> >> >>     Juergen
> >> >>
> >> >>
> >> >> > Once the COPS connection is open, it is perfectly within
> >> the COPS
> >> >> > protocol for the PDP to send unsolicited decisions to
> >> the PEP (for
> >> >> > example the midcom agent sending an open pinhole 
> decision to the 
> >> >> > middlebox.
> >> >> >
> >> >> > Also to address the fail over points you made below. The PEP 
> >> >> > (Middlebox) can have local policy indicating the
> >> order by
> >> >> > which it will contact the PDPs (MIDCOM Agents).  This local
> >> >> policy can
> >> >> > actually be installed by the primary SIP server (in the
> >> example you
> >> >> > gave), indicating if communication is lost between it (the
> >> >> primary SIP
> >> >> > server) and the Middlebox, the Middlebox MUST contact
> >> the THIRD SIP
> >> >> > server as the highest priority back-up SIP server, then the
> >> >> SECOND SIP
> >> >> > server if the both the PRIMARY/FIRST SIP server and the
> >> THIRD SIP
> >> >> > server is not available to provide the required services.
> >> >> Notice the
> >> >> > fail over is totally deterministic and also controlled
> >> by Policy of
> >> >> > the controlling domain.
> >> >> >
> >> >> > Also only a single connection  between a Middlebox and a
> >> >> MIDCOM Agent
> >> >> > is maintain at any given time, the one that is being used.
> >> >> >
> >> >> > Also lets say the PRIMARY SIP server 
> degrades/dies/off-load its 
> >> >> > service gracefully (you can also view this as part of load
> >> >> balancing
> >> >> > between multiple SIP servers), the PRIMARY SIP server can
> >> >> REDIRECT the
> >> >> > Middlebox to get its service from a specific other SIP
> >> >> server, in the
> >> >> > example you gave below, this should be the THIRD SIP
> >> >> server. This is
> >> >> > done without any interruption to the functionality the
> >> Middlebox is
> >> >> > providing.
> >> >> >
> >> >> > This is how COPS is intent to be used without any
> >> >> modification to the
> >> >> > current RFCs.
> >> >> >
> >> >> > With the above, one may take a step back and think:
> >> >> > "Is the directional requirement really 'required' ??  Or
> >> is it the
> >> >> > FUNCTIONALITY that is really 'required' ??"
> >> >> >
> >> >> > I have shown how COPS satisfy the fail over and high
> >> availability
> >> >> > FUNCTIONALITIES without talking about the directional 
> >> >> > 'requirement'.
> >> >> >
> >> >> > Hope I have clarify some of the points raised.
> >> >> >
> >> >> > -- Kwok Ho Chan --
> >> >> >
> >> >> >
> >> >> >
> >> >> > At 08:44 PM 10/18/02 +0200, Martin Stiemerling wrote:
> >> >> >>> I think we discussed several times the "session" on
> >> the mailing
> >> >> >>> list. We never closed this on the list, I'm still
> >> hoping we could
> >> >> >>> close this at some point. What do we mean by session?
> >> There is a
> >> >> >>> relation between the Middlebox and the Midcom
> >> >> agent, this
> >> >> >>> relation consists of:
> >> >> >>> -Establishing trust and authorization levels 
> -Establishing a 
> >> >> >>> security association -This relation could have a real
> >> identifier
> >> >> >>> or a pseudo
> >> >> one based on the
> >> >> >>> Midcom agent or Middlebox identity; this could be  used
> >> >> for hand-overs or
> >> >> >>> for softstate cleaning in case the Midcom agent goes down.
> >> >> >>
> >> >> >> Agreed.
> >> >> >>
> >> >> >>> This relation doesn't really need to have a 
> direction for its 
> >> >> >>> establishment, I suggest that we take it out of the
> >> >> directionality
> >> >> >>> of the relation from the requirements document.
> >> >> >>
> >> >> >> The relationsship is from the framework document, section
> >> >> 4. "MIDCOM
> >> >> >> protocol": "MIDCOM shall be a client-server protocol,
> >> initiated by
> >> >> >> the agent." Section 6.2. "Registration and deregistration
> >> >> of MIDCOM
> >> >> >> agents" says: "MIDCOM agent profile may be 
> pre-configured on a 
> >> >> >> middlebox. Subsequent to that, the agent may choose to
> >> initiate a
> >> >> >> MIDCOM session prior to any data traffic."
> >> >> >>
> >> >> >> I always read "initiated" by the agent, that implies for
> >> >> me the agent
> >> >> >> starts the communication with the middlebox. We are
> >> definitely too
> >> >> >> late for deleting this directional component, because
> >> it is in our
> >> >> >> framework RFC.
> >> >> >>
> >> >> >> Another point for not initiating the communication by the
> >> >> middlebox,
> >> >> >> the above mentioned hand-off between agents. Imaging you
> >> >> have three
> >> >> >> SIP proxies, two of them as a fall-back. All three are
> >> >> pre-configured
> >> >> >> to the middlebox. The primary, or in duty, SIP server
> >> has a server
> >> >> >> crash, now the third SIP server takes over. How should the
> >> >> middlebox
> >> >> >> know that the third SIP server is the one in charge 
> and not the 
> >> >> >> second? The middlebox has to know something about 
> the failover 
> >> >> >> mechanism. Furhtermore it has to maintain to all proxies a
> >> >> connection
> >> >> >> at any time, that's polling!
> >> >> >>
> >> >> >> Martin
> >> >> >>
> >> >> >>> In addition COPS-PR could be used in the context of in path 
> >> >> >>> signaling for authorization policy purposes. As some of the 
> >> >> >>> Middleboxes will support both in path signaling (the NSIS WG
> >> >> >>> delivery) and the MIDCOM off path protocol COPS-PR has
> >> the best
> >> >> >>> position to be the MIDCOM protocol. Cedric -----Original
> >> >> >>> Message-----
> >> >> >>> From: Martin Stiemerling
> >> [mailto:[email-masked]]
> >> >> >>> Sent: 17 October 2002 10:45
> >> >> >>> To: [email-masked]
> >> >> >>> Subject: [midcom] Evaluation: COPS and session 
> initialisation
> >> >> >>>
> >> >> >>> Just a poll about the working group opinion:
> >> >> >>> The MIDCOM framework and requirements say that the agent
> >> >> initiates
> >> >> >>> the session to the middlebox. But in the COPS/COPS-PR
> >> >> case the way
> >> >> >>> is vice
> >> >> >>> versa: The middlebox initiates the session to the 
> agent. I see 
> >> >> >>> this a as major difference in the particular
> >> >> architecture. How
> >> >> >>> does the working group feel about this. Is this just a
> >> >> minore point or a
> >> >> >>> real concern.
> >> >> >>> Martin
> >> >> >>> -- Martin Stiemerling
> >> >> >>> NEC Europe Ltd. -- Network Laboratories
> >> [email-masked]
> >> >> >>> IPv4: http://www.ccrle.nec.de  IPv6:
> >> http://www.ipv6.ccrle.nec.de
> >> >> >>>
> >> _______________________________________________
> >> >> >>> midcom mailing list
> >> >> >>> [email-masked] 
> https://www1.ietf.org/mailman/listinfo/midcom
> >> >> >>
> >> >> 
> >>
> >> >> >>
> >> >> >> --
> >> >> >> Martin Stiemerling
> >> >> >>
> >> >> >> NEC Europe Ltd. -- Network Laboratories
> >> [email-masked]
> >> >> >> IPv4: http://www.ccrle.nec.de  IPv6:
> >> http://www.ipv6.ccrle.nec.de
> >> >> >>
> >> >> >>
> >> _______________________________________________
> >> >> >> midcom mailing list
> >> >> >> [email-masked] https://www1.ietf.org/mailman/listinfo/midcom
> >> >> >
> >> >> > _______________________________________________
> >> >> > midcom mailing list
> >> >> > [email-masked] https://www1.ietf.org/mailman/listinfo/midcom
> >> >>
> >> >>
> >> >> _______________________________________________
> >> >> midcom mailing list
> >> >> [email-masked] https://www1.ietf.org/mailman/listinfo/midcom
> >> >>
> >>
> >>
> >>
> 
> 
> 
_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 22 Oct 2002 15:51:09 +0200

Kwok,

Has this unconventional usage of COPS-PR already been discussed earier
in the COPS-PR community? Or was the idea developed just for meeting
the midcom requirements?

    Juergen

---

From: Kwok Ho Chan <[email-masked]>
Date: Tue, 22 Oct 2002 12:22:34 -0400

Juergen, All:
We are not talking about unconventional usage of COPS or COPS-PR.
I am not indicating any change to the current COPS and COPS-PR RFCs.

I am organizing the points made in other E-Mails on this thread and try to
provide some more clarafication.
Thanks!
-- Kwok --

---

From: Kwok Ho Chan <[email-masked]>
Date: Thu, 24 Oct 2002 17:29:21 -0400

Juergen, Martin, all:
Based on the previous E-Mail messages on this thread, I have summarized
the concerns into the following points:

1. (Re-)Configuring the Middlebox everytime a dynamic (service) change occurs.
     With the assumption that for every (re-)configuration, the communication
     between the MIDCOM Agent and Middlebox needs to be establish anew.

2. It is the MIDCOM Agent that knows when service/resource/assistance is
     needed of the Middlebox.  In another word, it is the MIDCOM Agent that
     receives the trigger/event indicating service requirement.
     Because of this, how can the architecture of having Middlebox (PEP)
     contacting MIDCOM (PDP) works?

And these two concerns contributes to the directional requirements of MIDCOM.

Let me try to explain by laying out the operational scenario when COPS is used.
(in this E-Mail you can replace COPS with COPS-PR if you like)

1. Middlebox boots up, knowing it needs to establish communication with
     a MIDCOM Agent, at this time a default MIDCOM Agent.  It uses a default
     MIDCOM Agent address for a specific domain or uses some kind of service
     lookup capability (think of "MIDCOM_Agent" translate to a specific 
address).
     This will allow a Middlebox initiated TCP connection to be established.

2. The MIDCOM Agent the Middlebox contacted can be the correct MIDCOM
     Agent and it will accept the TCP connection request.  Or it may not be
     the correct MIDCOM Agent, at which it will "redirect" the Middlebox to
     contact the correct MIDCOM Agent.  This can be used for load balancing
     between multiple MIDCOM Agents as I have indicated in earlier E-Mail.

     Notice the established TCP connection between the Middlebox and MIDCOM
     Agent is a long-lived TCP connection, to be used for all subsequent
     communication, static or dynamic.  COPS use one and only one TCP
     connection between the Middlebox and the MIDCOM Agent, established
     only once.

     The COPS connection is establish over this TCP connection, with Middlebox
     sending its capability to the MIDCOM Agent.  You can view this capability
     notification as a registration of Middlebox to the MIDCOM Agent indicating
     "I am here and I can provide these services/resources, let me know what
     I can do to help when necessary."

3. When the MIDCOM Agent detected a trigger/event indicating it need some
     services/resources from some Middlebox, it will have a list of 
services/resources
     on specific Middleboxes that the specific MIDCOM Agent have at its 
disposal.
     The MIDCOM Agent at this time communicate to the Middlebox over the
     already established TCP and COPS connection to allocate the Middlebox's
     services/resources as necessary.
     You can view this as configuration/re-configuration/provisioning.  I 
view this
     as what it is functionally doing: allocating resource/service when and 
where
     it is needed.  The notion of static/dynamic is relative, and the mechanism
     here is more effective, efficient the more dynamic the interaction 
becomes.
     Hence this addresses the dynamic-ness concern from the E-Mail thread.

     Notice the communication between the MIDCOM Agent and Middlebox
     is transactional and state-full.  So any transactional success/failure/
     resource_used is known immediately, no polling required.  This provides
     efficient resource usage across the administrative domain (think about 
load
     balancing across multiple Middleboxes).

4. For operating a network, there should be "policies" on what is the correct
     action to take when parts of the network experience outage, problem, etc.
     There should also be "policies" on when and how maintenance is done.
     These "policies" can be carried out by human or be automated.  The
     choose is up to the owner of the network.

     When COPS is used, these "policies" can be pre-installed at the MIDCOM
     Agent and/or Middlebox prior to the actual outage/problem/maintenance
     event occurs.  For example, after the Middlebox established the 
communication
     with the MIDCOM Agent, the MIDCOM Agent can indicate the administrative
     domain's "policies" if the Middlebox loose communication with the MIDCOM
     Agent (these "policies" may indicate the Middlebox should contact a list
     of back-up MIDCOM Agents in a specific prioritized order).  There can also
     be "policies" for partial or full failure of the Middlebox.  For the 
MIDCOM Agent
     maintenance issue in the E-Mail thread, there can be "policies" on 
when the
     Middlebox should try to contact the MIDCOM Agent again with a specific
     frequency, indicated to the Middlebox by the MIDCOM Agent before the
     MIDCOM Agent goes into maintenance mode.  But I would much prefer to use
     a graceful method of redirecting the Middlebox to back-up MIDCOM Agents
     during the primary MIDCOM Agent maintenance period and have the back-up
     MIDCOM Agent redirect the Middlebox back to the primary MIDCOM Agent
     when necessary.  Notice this is all deterministic and under control.

5. When the Middlebox needs to be shut-down (or it fails), the MIDCOM Agent
     knows immediately (within the limit of keep-alive messages), no polling is
     needed to see if the services/resources provided by a Middlebox is 
available
     to the MIDCOM Agent.

With the above explanation, I have indicated that there are two levels
of interaction:
1. Communication Establishment.
     For COPS, it is initiated by the Middlebox.
2. MIDCOM Functional Event Flow.
     For both MIDCOM and COPS, it is from MIDCOM Agent to Middlebox.

IMHO, I believe the MIDCOM Requirement cares about the "MIDCOM Functional
Event Flow" direction, NOT the "Communication Establishment" direction.

Hence COPS meet this requirement fully with the above explanation.

Please provide the need to have the "Communication Establishment" directional
requirement reasoning if you think otherwise.

I hope I have resolved the concerns indicated by this E-Mail thread, and please
let me know if I haven't.

Thank you!
-- Kwok --

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 25 Oct 2002 17:16:34 +0200

Kwok,

>      contacting MIDCOM (PDP) works?

Full agreement on both items.

>      lookup capability (think of "MIDCOM_Agent" translate to a specific address).

I think here is the reason why we find it so hard to agree further: The NAT across
which I'm sending this message had its last reboot on Thu Dec 20 14:19:26 CET 2001.

Since then, several services have been installed or removed in our network, but
the NAT is not something you don't want to touch regularly. It is part of the
mission-critical basic infrastructure.

How would your be if you start with "1. Agent boots up, waiting for a middlebox
to get aware of this fact and to eastablish communication."?

If you install a network, you first establish basic connectivity including
NAT and firewall. At the time these machine boot up, there might be no agent
avaiable or just a subset of the agents that will (at some later point in time)
need to control the middlebox.

Then you start installing services on top of the basic infrastructure.
If you set up - say - SIP-signalled IP telephony service, it would be simple
to configure the SIP server (you have to configue it anyway) to connect to
the middlebox and use midcom for enabling outgoing and incoming calls.

Then you might want to set up a non-SIP video conferencing service and
repeat the steps you made for SIP configuration.

In both cases, it appears to be a disadvantage, if you also had to re-configure
the middlebox telling it the address of the new agent.

>      the correct MIDCOM Agent, at which it will "redirect" the Middlebox to

Do you suggest an agent re-direct to become part of the midcom protocol?

>      connection between the Middlebox and the MIDCOM Agent, established

So, you should not reboot the middlebox, when installing a new service
that uses an additional service specific midcom agent!

>      I can do to help when necessary."

This sounds great, but it would make more sense if you multicast your service offer,
like route advertisements. Then a new agent could receive this and reply: "Hey, I'm
new. Please establish a TCP connection to my IP address 1.2.3.4." ;-)

>      services/resources from some Middlebox, it will have a list of services/resources
>      on specific Middleboxes that the specific MIDCOM Agent have at its disposal.

This seems to be just the very basic MIDCOM usage scenario. Or are you distinguishing
two different agents, the general one and the "specific" one?

>      You can view this as configuration/re-configuration/provisioning.  I view this
>      as what it is functionally doing: allocating resource/service when and where
>      here is more effective, efficient the more dynamic the interaction becomes.

Yes, this is exactly what the midcom protocol should be used for?

>      Hence this addresses the dynamic-ness concern from the E-Mail thread.

I do not understand at all.

>      efficient resource usage across the administrative domain (think about load

I think we know this well from the protocol evaluation.

>      choose is up to the owner of the network.

I think for each netwrok there "are" policies. Sometime they exist just in the
head of the administrators, sometime they are written in English, sometime
they might be implemented in a convetional network management programm, sometime
they are coded in a policy definition language of a policy-based management system.

>      event occurs.  For example, after the Middlebox established the communication
>      be "policies" for partial or full failure of the Middlebox.  For the MIDCOM Agent
>      maintenance issue in the E-Mail thread, there can be "policies" on when the

I am not sure, I fully understand this: Are you saying that there should be one
(master) agent that does midcom configuration, but at the same time, using the
same authenticated connection also does the higher level policy-configuration
of the middlebox?

This master agent then would tell the middlebox to connect to other middleboxes
new installed middleboxes of which the middlebox had no knowledge, so far.
Then the middlebox connects to this other agent.

Essentially you are saying: It is no problem that COPS connects from middlebox
to agent, because if you use COPS anyway for managing your network, then you
can use to tell the middlebox (with non-Midcom means) to which agents to
connect. So COPS for Midcom is no problem, if you use COPS also for Middlebox
administration. This sounds like a Microsoft marketing strategy ;-)
What if you don't want to use COPS for middlebox administration, because
you already use Linux?

>      needed to see if the services/resources provided by a Middlebox is available
>      to the MIDCOM Agent.

What, if the agent needs to be shut down and boots up some time later. According
to my experience (see my second comment), this is the much more frequently
occuring event.

>      For both MIDCOM and COPS, it is from MIDCOM Agent to Middlebox.

If I got you right, this holds only if you use COPS also for administrating
the middlebox.

> let me know if I haven't.

I still have the operational concerns I had before.
But I thank you very much for explaining your issue in such a detail.

    Juergen