Subject: Re: Bringing the ARCH draft to WG Last Call

From: Martin Stiemerling <[email-masked]>
Date: Thu, 07 Oct 2004 10:25:30 +0200

Hi,

--On Mittwoch, 18. August 2004 6:51 Uhr -0400 Marie-Jose Montpetit 
<[email-masked]> wrote:

| There are a few remainning outstanding issues before the ARCH draft can be
| brought to WGLC. These were briefly discussed at the IETF but need a wider
| discussion on the list.
| 1. Should there be some requirements to allow end to end management of IP
| flows
| this would enable enable operators to better configure, verify and
| distribute policies regarding specific flows; there is heritage there from
| the cable industry

I currently have the problem to understand what exactly the end-to-end 
management of IP flows is in the context of ipdvb. Management means too 
many different things to people.  Could you give me a hint?

| 2. Should address resolution be used to map specific addresses to PIDs
| with special features
| This would allow to combine AR with resource management, load balancing
| and QoS

The Internet-style solution would be AR does AR, no more no less.  All the 
other things belong into different protocols, it should be all IETF-safe 
"Protocol do only things they are intended to do" and Keep it Simple, 
Stupid (KISS).

   Martin

| 3. Should extension headers carry information about the cell content over
| the MPEG-2 section of the network
| There are multiple uses of that including flow management.
|
| In addition we will add a protocol stack to the draft to show where ULE
| is.
|
| Since we would like to finalise this shortly I would appreciate comments
| on these issues and closure before 6/25.
|
| Thanks
|
|
| Marie-Jose Montpetit
|
|

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 08 Oct 2004 11:37:46 +0100

Some thoughts are in-line:

> many different things to people.  Could you give me a hint?

Edge-to-Edge, End-to-End ... These are always confusing terms. My take 
is something like: the ipdvb WG is to look at solutions that enable 
MPEG-2 transmission networks to be more fully integrated into IP 
networks as a subnetwork technology. E-to=E means from IP-router to 
IP-router or end-host to IP-router or IP-router to end-host.

The work includes seamless (where possible) support for IP network 
functions (IPv6, mobility, security, diffserv, MPLS(?), etc etc), more 
integrated operations (i.e. ability to interact/inform MPEG-2 
transmission network components such as encapsulators and receivers - to 
indicate the properties of the IP flows which they are to transport). 
Things to consider include, where policies and decisions made in using 
the MPEG-2 transmission network for specific IP flows (which specific 
PIDs are used, which encapsulation is used, which encaps options, which 
MPEG-2 QoS functions, priority, multicast config, etc).

It may be hard to cover all scenarios with a single set of protocols, 
and we need to be clear of the different usages. Getting the terminology 
correct will also be challenging.

> The Internet-style solution would be AR does AR, no more no less.  All 
> the other things belong into different protocols, it should be all 
> IETF-safe "Protocol do only things they are intended to do" and Keep it 
> Simple, Stupid (KISS).
> 
> 
Aha - but in MPEG-2 I see  "resolution" occurs at three levels

(i)   IP -> resolution to NPA/MAC address (as in ethernet);
(ii)  IP -> resolution to Packet ID (PID);
(iii) IP -> resolution to specific transmission multiplex/phy link.

The WG includes all of these as part of the "resolution" process.
- This was the intended scope of a WG AR draft.

> | on these issues and closure before 6/25.

Gorry

---

From: "Marie-Jose Montpetit" <[email-masked]>
Date: Fri, 8 Oct 2004 06:51:05 -0400

Thanks for your comments see my reply below:

snip/snip
>snip/snip

I think both your comments are related. The common belief here is that an
address resolution protocols in the wider sense (as it relates to the bigger
configuration/management issues) should allow operators to do more than
blindly attach a IP adrress to a MAC address or to a PID in this case. For
example it should enforce security/authentication measures to prevent
unauthorised traffic from even getting one the network and allow some
addresses or flows with specific characteristics to be assigned different
PIDs to guarantee they will get processed the right way. That is not against
the KISS principle, actually could be simpler than current implementations.
I believe it to be good engineering practice to have solution that are
extensible, flexible and open.

Marie-Jose