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

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 21 Oct 2002 18:21:06 -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.

> -----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 09:38:31 +0200

Tom,

> 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