Re: [Ieprep] on the ieprep charter

[Fred Baker <[e-mail]>]

I think it is possible to over-constrain the working group outputs,  
and so would not go into that level of detail in the charter. For  
example, we might decide in the course of working the issue that the  
division isn't worthwhile, and then find that we have to change the  
charter to ignore it.

The important thing to me is that the charter should describe us  
providing a signaling solution that is
  - applicable to a variety of implementations, including preemptive  
and non-preemptive,
  - appropriate throughout the Internet, not just in the subset that  
happens to be relevant
    to the US Government, whether civil or military, and
  - addresses both inter-provider and provider/customer connectivity.

I think it should also very clearly require both application layer  
CAC (eg, "who are you" and "what are you authorized to do" for some  
appropriate set of definitions) and network layer CAC (eg, at this  
instant, does the network have resources to address your  
requirements, and if not what is it going to do about that). Since  
the two questions are very different, there should be no assumption  
that only one needs to be solved or that one solution solves both.

What the charter should, perhaps, address, is the status of multicast  
in this. We all agree we need unicast solutions. RSVP assumes that  
multicast is also a requirement, while NSIS presumes that it can be  
summarily set aside. In civilian networks where multicast is not  
widely deployed as a service, the point may be moot. I am told that  
in your organization and others in coalition with it, there are  
places where multicast is the predominant traffic type, however. So  
we have to decide whether we need to address that.

On Jul 27, 2006, at 12:37 PM, Robert G. Cole wrote:
> Is this something that is or should be captured within the text of  
> the IEPREP charter, i.e., objectives for paritioning work into  
> protocols at UNIs and NNIs and behaviors (where appropriate) within  
> network interiors?
>
> Bob
>
> Fred Baker wrote:
>> On Jul 27, 2006, at 11:40 AM, Robert G. Cole wrote:
>>> "There is enough similarities in the needs of these broad  
>>> industry  segements with respect to communications requirements/ 
>>> needs in  emergency situations that:
>>>
>>> a) Protocols can be enhanced (or in some cases developed) to  
>>> handle  the similarities, while
>>>
>>> b) Differences are relegated to implementations or behavior   
>>> descriptions."
>> Yes, that is my opinion. Just an opinion, mind you. But I should   
>> think that a common UNI and NNI signaling mechanism could be   
>> described that enabled every implementation (regardless of nation  
>> or  type of network) to classify requests in an appropriate  
>> manner  (routine or whatever other level might apply, and whether  
>> the  customer was authorized to make the request) and then  
>> implement what  needs to be done. In some networks, for some  
>> services such as VoIP  and Video/IP, that will include preemption;  
>> in other networks, the  same services will include trunk queuing  
>> or other approaches. For  other services, such as preferring some  
>> elastic traffic over others  and the transitive trust issues in  
>> delivering an email within a short  stated interval, other  
>> considerations may also come into play.
>>
>> Note that I carefully separated that into three broad categories:   
>> UNI, NNI, and everything else. "everything else" is within a  
>> network,  and I think that is the network's problem although I may  
>> have some  suggestions. NNI may be able to be handled by SLAs,  
>> although one  could argue that the entire discussion here is  
>> regarding edge  conditions in SLAs. It is the UNI that concerns me  
>> the most, as it  tends to be the place where the biggest problems  
>> occur, and where  problems occur at NNIs they can be treated as a  
>> variety of aggregated  UNI. It is the NNI and the UNI that are  
>> most in view in RFC 4542.
>>
>> One thing to consider is that the intra-network case and the NNI  
>> case  are somewhat specialized( we are simply looking at IP  
>> traffic,  usually in an aggregated form), while the UNI crosses a  
>> variety of  types of products including SMTP servers, telephones  
>> and telephone  middleware, etc ad nauseum. I think the UNI is the  
>> most interesting  and important case.

_______________________________________________
Ieprep mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ieprep