CCAMP Liaisons and Communications

1. CCAMP Liaisons and Communications Adrian Farrel adrian@olddog.co.ukDeborah Brungard dbrungard@att.com68th IETF – Prague – March 2007

2. Relationships • The IETF has a formal liaison relationship with the ITU-T • Relevant correspondence is delegated to the competent working group(s) • Liaisons are handled with guidance from the designated liaison personnel • General liaison to the ITU-T : Scott Bradner • Liaison to the ITU-T on optical control plane : Adrian Farrel • Liaison to the ITU-T on MPLS : Loa Andersson • WG chairs draft/coordinate liaisons and responses • CCAMP has a correspondence relationship with the OIF • WG chairs draft/coordinate correspondence and responses • All correspondence is tracked at www.olddog.co.uk/ccamp.htm • Formal liaisons also tracked at https://datatracker.ietf.org/public/liaisons.cgi • We have a duty to share information and respond to questions

3. Several Responses Needed • ITU-T • Ongoing discussion on ASON routing solution • Request to liaise MLN and Call work • Latest version of work plan for Optical transport Networks • OIF • Further discussion of VLAN ID distribution • MEF requirements • Signalling interworking cookbook • Purpose now is to discuss these to give guidance to chairs on drafting responses • Very happy to delegate!

4. OIF UNI - MEF Work • Request was for Traffic Parameters • We have draft-ietf-ccamp-ethernet-traffic-parameters-01.txt • We sent the 00 version and exchanged some comments • Believe this work addresses all OIF requirements • Item closed, but discussions led to…

5. OIF VLAN Identifiers • Some confusion about exact requirements • Latest correspondence contains deployment scenarios to assist our comprehension • Aggregation of VLAN IDs is done in control plane at A, but it is not clear if a single (point-to-point) aggregated connection is the expected forwarding in the data plane at B LSPs UNI A B VLAN ID Single Path message Single Path message

6. VLAN-ID Question • OIF asks how can a single Path message indicate multiple VLAN I-Ds are represented in a single service? Can OIF use a compound label? • Answer seems to be that you should do control plane and data plane aggregation at the same point: Either • Send multiple Path messages (standard hierarchical approach) • Perform data aggregation at UNI client (S-VLAN/MAC in MAC?) • Otherwise, maybe this is a Call functionality? • No information provided on UNI TSPEC expectations (e.g. granularity of C-VLAN within EVC) in Liaison • Any outcome of ad hoc discussions yesterday?

7. OIF Signalling Interworking Cookbook • Intention is to show how GMPLS and other variants (OIF UNI/E-NNI and ASON UNI/E-NNI) can be interworked • Our comments are solicited • Cookbook objectives seem unclear (ignores GMPLS work on UNI, ENNI, ASON) • Describes “ASON domains” but there is no such thing as an ASON I-NNI protocol specification (ASON is a “domain agnostic” architecture) • Interworking should be about four issues: • How to carry UNI information across the network • How to present UNI (call) information at E-NNIs • How to handle different UNIs at each side of the network • Now to handle different E-NNIs at each side of a subnetwork • Can we help by describing how to map OIF UNI parameters to GMPLS signalling?

8. Optical Transport Plane Work Plan • This was liaised for information • We are invited to comment by 30th April • Table 5-1 lists known standardisation activity around Ethernet in various SDOs • No mention of GELS. Time to let them know? • Table 7-1 lists relevant standards • Long list of RFCs, but not complete • Send a complete list and ask for it to be included? • Suggest that timed-out I-Ds should not be listed? • Table 7-4 lists ASON control plane standards • Send list of RFCs and request them to be included? • Table 8-1 lists known overlaps • Is this incomplete? • Two items of overlap with IETF are listed as for “Ongoing collaboration by company representatives” • This is good, but what does it say about the liaison relationship?

9. Request to Liaise Calls • Recent liaison (just in) requests us to liaise draft-ietf-ccamp-gmpls-rsvp-te-call-04.txt “before it is published as an RFC” and by April 2nd • I-D is past IETF last call. Is it too late? • Motivation for request is that I-D claims to address requirements in RFC 4139 and ITU-T owns ASON • I-D explicitly defers describing how GMPLS protocols are applied to satisfy ASON to a separate I-D • That I-D has expired and needs considerable work • Liaise it instead?

10. Request to Liaise VCAT Work • Recent liaison (just in) requests that we liaise draft-ietf-ccamp-gmpls-vcat-lcas-01.txt by April 2nd • Motivation is “This draft uses mechanisms defined by ITU-T SG 15 in Recommendations G.7041 and G.7042 and is also applicable to an ASON network.” • Clearly does not use mechanisms in G.7041 or G.7042 (but does enable control plane support) • Definitely applicable to an ASON network • We can liaise this I-D with no issues • Note that a new revision will be along soon that will make review of this revision a waste of time

11. Ongoing Exchanges on ASON Routing • Liaison just in requests response by April 6th • Remarkably short notice! • Long list of issues • Asks us to supply details of our reasoning in selecting OSPF loop prevention mechanisms rather than applying ISIS mechanisms to OSPF • We could supply this reasoning, but to what purpose? • We note that we previously asked if the ITU-T had any technical issues with our choice and received no answer. • Asks for further explanation of why we declined to change “an Li may be advertised by only one Ri at any time” to “a TE link is only advertised by one Ri at a time.” • Restates that we should use “MUST” not “optional” in describing the inclusion of timeslot accounting information (section 4.2) • This seems to be a misunderstanding of context • New revision of I-D clarifies the text • We can liaise back to thank them for prompting us to clarify

12. More on ASON Routing • Section 5.2 request we use MUST in “This sub-TLV is optional and SHOULD only be included as part of the top level Link TLV if the Router_ID is advertising on behalf of more than one TE_Router_ID.” • This seems to fail to notice that the first TE_Router_ID is already encoded elsewhere • Explain how this works? • Request liaison of any work on multi-layer networks • We should do this especially for the MLN requirements and evaluation that are soon to have last call • Very many of our I-Ds and some in PCE are applicable to multi-layer networks. Liaise them all? • Set respond-by date to coincide with end of WG last call? • Request explanation of how redistribution of information continues when a redistribution point fails • Simply send an explanation?

13. And Another Question on Calls • Old liaison said… • The G.8080 architecture may be employed to support various call control realization approaches. It should be noted that the architecture does not dictate any particular implementation and we would request that any solution not impose such limitations. We observe that Section 3.2 of <draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt> explicitly prohibits logical call/connection control separation; i.e., call communications “piggy-backing” on connection communications. • New liaison says… • ASON requires full logical separation of the call and connection which may be implemented with separate or piggybacked call and connection signalling. • Seems to support our solution • Do we need to say anything else?