Re: [EME] First cut at eme requirements

On Dec 5, 2006, at 8:20 AM, Paul Francis wrote:

>
> So I guess what is meant by "does not disrupt" is key here.   
> Clearly we want
> a solution that doesn't completely disrupt communications when a  
> middle box
> crashes or paths change.  At a minimum, this means enough state at  
> the end
> systems that they can re-establish communications and, for  
> instance, continue
> a transport stream.  I took this minimum amount of robustness as a  
> given, but
> no harm in codifying it in the requirements doc.
>
> But if by "does not disrupt" you really mean does not disrupt in  
> any way
> (i.e. a voice call continues with nary a glitch), then obviously  
> more of a
> challenge.  There are several levels at which we could try to  
> achieve this:
>
> 1.  Design the protocols in such a way that we don't prevent the  
> deployment
> of redundant hot-failover, fast-reroute kinds of solutions in the
> infrastructure, should one wish to deploy this way.
> 2.  Keep this kind of requirement in mind, and design for it to the  
> extent
> that it doesn't overly complicate the protocol, but otherwise be  
> willing to
> forgo strong non-disruption.
> 3.  Make strong non-disruption a hard requirement.
>
> My feeling is that we should make a good effort to achieve 1 and 2,  
> but stop
> short of 3.

I don't think we want 3, either.  In hindsight, "does not disrupt" is  
a poor choice of words.  Tolerance to path change probably  
distinguishes one EME protocol from another.  Some EME protocols may  
be able to support the operational needs of more types of EME  
applications than others.  This is starting to sound more like an  
observation than a requirement to me, but as an example, an EME  
protocol might enable a middlebox to participate in the end-to-end  
security association in some way.  In this case, it might be okay for  
the endpoint and a middlebox to do an authenticated Diffie-Hellman  
once per session but no more.  So long as the middlebox that is  
incident to the new path is in the same security domain as the  
previous one, redundant or hot-failover is easily done.  If they are  
not in the same security domain, then endpoint policy probably would  
require that the new middlebox be completely authenticated.  In this  
case, a protocol that accomplishes the original goal without a  
relatively-slow crypto operation in response to path change would be  
preferred.

Mark
>
> PF
>
> -----Original Message-----
> From: Mark Baugher [mailto:mbaugher@cisco.com]
> Sent: Monday, December 04, 2006 6:24 PM
> To: Paul Francis
> Cc: eme
> Subject: Re: [EME] First cut at eme requirements
>
>
> On Dec 4, 2006, at 8:38 AM, Paul Francis wrote:
>
>>
>> Good question.  Probably we should have a statement on scale (i.e.
>> global).
>> As for the other two, I want to avoid "obvious" kinds of requirement
>> (i.e.
>> "the system must be robust").  Having said that, I'm certainly aware
>> that one can construct quite specific robustness statements ("the
>> system must be able to tolerate the loss of up to three servers with
>> zero measureable performance
>> degradation") that can have a major impact on system design.
>>
>> But am open to discussion on this.  Do you have any thoughts on how
>> such requirements would be crafted?
>
> Here's what I had in mind: To the extent that the middle box is  
> providing
> services to endpoints and is incident to the path between (or  
> among) the
> endpoints, what happens to end-to-end connectivity when the path  
> changes to
> use other middle boxes?  I think that a robust solution would not  
> disrupt the
> end-to-end communication as needed state is established in  
> different middle
> boxes.
>
> Mark
>
>>
>> PF
>>
>>
>>
>> -----Original Message-----
>> From: Mark Baugher [mailto:mbaugher@cisco.com]
>> Sent: Friday, December 01, 2006 6:47 PM
>> To: Paul Francis
>> Cc: eme
>> Subject: Re: [EME] First cut at eme requirements
>>
>> What are your thoughts on robustness, scalability and fault-recovery
>> requirements?
>>
>> Mark
>>
>> On Nov 28, 2006, at 7:30 AM, Paul Francis wrote:
>>
>>>
>>> Gang,
>>>
>>> Attached is a rough draft of a requirements document for EME.
>>> This is
>>> meant to be the union of the requirements that Handley and I
>>> presented at the BOF in Montreal.  The goal here is to be ambitious
>>> but realistic, and to try to limit ourselves to basic and important
>>> requirements.  This really is a rough draft, and is meant to  
>>> motivate
>>> and focus discussion.
>>>
>>> Mark W, could you post on the wiki when you get a chance?
>>>
>>> Thanks,
>>>
>>> PF (and Saikat)
>>> <eme-requirements.txt>
>>> _______________________________________________
>>> EME mailing list
>>> EME@irtf.org
>>> https://www1.ietf.org/mailman/listinfo/eme

_______________________________________________
EME mailing list
EME@irtf.org
https://www1.ietf.org/mailman/listinfo/eme