RE: CCAMPs....some questions

[neil.2.harrison@bt.com]

Thanks Chris...appreciate your comments and nice to meet you last week.

There are 3 critical questions (there are many other questions, but let's
just stick with these here) that have to be answered before a UNI (or indeed
NNI) specification can be credibly produced.  These are:
-	what are the required OTN routable addresses......size/format and
standardisation/administration requirements?
-	how are client layer routable address converted into client layer
names, ie non-routable identifiers....size/format and
standardisation/administration requirements?
-	what is the mechanism [eg DNS-like? (external to OTN)]
service/network that is required to resolve/advertise/discover the
name/address bindings.......and like the control-plane, this implies a need
for some network in its own right?

As far as I can tell, there has been little work to on the above in terms of
defining the problem-space and requirements.........it seems that many have
gone straight to solution-mode.  If we just take the 1st item, ie OTN
addressing, a change from v4 to v6 is actually a wholesale layer network
change, and that why it is so problematic.....in other words, once you set
an addressing schema at day-1 it is a very big problem to move to something
else latter as you too acknowldege.  So why create potential downstream
network problems for the OTN when we can de-risk this now?

neil



> -----Original Message-----
> From:	Chris Metz [SMTP:chmetz@cisco.com]
> Sent:	Thursday, December 21, 2000 5:25 PM
> To:	neil.2.harrison@bt.com
> Cc:	tv-area@ops.ietf.org
> Subject:	Re: CCAMPs....some questions
> 
> 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