Re: CCAMPs....some questions

[Chris Metz <chmetz@cisco.com>]

Neil-
As pointed out the IETF attempts to solve problems and address requirements 
by developing and extending the TCP/IP protocol suite. However in my 
personal point of view it has demonstrated a pragmatic willingness to 
incorporate and accommodate support for networking elements not commonly 
associated with the IP (packet) data plane. We saw this first in MPLS (with 
ATM switches) and now more recently in GMPLS by enabling lambda, TDM, 
packet, etc. user planes.

Thus it seems to me that:

- GMPLS (and the attendant signaling and routing protocol extensions) can 
support IP clients (e.g. routers) and non-IP clients (e.g sonet ADM, etc.) 
with the proviso that the IETF protocol machinery is employed. This means 
running an IP control plane on the client devices and OTN devices (at 
minimum on the interfaces facing towards the client). It also seems to me 
that mechanisms for resolving differences in address family (AF) structures 
can be employed as well but probably is an area for further study.

- GMPLS does not preclude one from defining and implementing administrative 
boundaries between the client and OTN networks. All we need really is the 
ability to filter which objects, based on policy, we wish to pass across a 
specific boundary. The same protocols are used - what differs between an 
O-UNI and peer adjacency is the type and volume of information. So it can 
accommodate the overlay model and multiple address families. Single 
protocol suite handling both overlay and peer network configurations.

I can appreciate your comments on not wanting to artificially limit a 
particular resource. My response to that would be:

- Need to understand better why IPv6 would be required immediately - and a 
costly reconfiguration from IPv4 to IPv6 when it is definitely needed is a 
good reason.

- IETF protocols can accomodate both IPv4 and IPv6. Assuming vendors are on 
the way to delivering both (at some point) it may boil down to an 
operational deployment choice.

Cheers ...

At 02:55 PM 12/20/2000 +0000, neil.2.harrison@bt.com wrote:
>Folks,
>
>At IETF49 Fred (Baker) asked for any comments on the proposed new CCAMPs
>work area within the IETF to be posted to this mailing list.  I have 2
>questions/observations at this stage:
>
>1       During the Monday 11 December 2000 session which Fred chaired on
>CCAMP, I asked the following question:
>Since the Optical Transport Network (OTN) will have clients other than IP
>(eg SDH, ATM, FR) will IETF ensure that the GMPLS work takes the requirement
>to support multiple client layers into account?
>
>Fred answered that IETF was only responsible for IP protocols and an IP
>client layer.  This is fair enough given IETF history and its modus operandi
>to date.  However, since many operators will require the support of multiple
>client layer technologies (as also borne out from OIF/ITU work on
>requirements), and thus requires that GMPLS must embrace an overlay model,
>the answer Fred gave implies that IETF will not able to satisfy our
>requirements.  If true, then we would not be in favour of the CCAMPs area
>(or more generally IETF) developing OTN standards and the work should be
>left to standards bodies who are prepared to address the needs of multiple
>client layer technologies, eg ITU.
>
>Can you please indicate whether my understanding as expressed above is
>correct or not?
>
>
>2       During the Thursday 14 December 2000 MPLS WG meeting I asked the
>following question:
>On what basis has the choice of a 32 bit address for the OTN been made?
>
>My concern here is that (it appears) 32 bit IPv4 addresses have been chosen
>for the OTN without any analysis of size/structure requirements being
>carried out.  Once set, it will almost impossible to change this later.  In
>particular, I don't see why an abstract/non-physical resource (like
>addressing) should be made 'scarce' at the outset.......if exact size
>requirements are not understood at this time, then we should err on the side
>of caution (noting that both v6 and ATM clients have 16 and 20 octet,
>respectively, address sizes).  Further, it will be required that OTN
>addressing is based on a globally agreed format from the start so that
>harmonised interconnection between operators will be possible later.
>
>Since I did not get a satisfactory answer to my original question during the
>MPLS WG meeting, I would like to ask this question again on this list and
>would like an answer that takes into account the concerns expressed above.
>
>Regards, Neil Harrison
>BT/Ignite CTO
>




Chris Metz
Lead IP Architect
Solutions Integration
Service Provider Line of Business
Cisco Systems
email: chmetz@cisco.com
offic phone: 408-525-3275
home office: 914-241-0423
pager: 800-365-4578
Internal URL: http://wwwin-people.cisco.com/chmetz/chmetz.htm