1. CCAMP Liaisons and Communications
Adrian Farrel Deborah Brungard 68th 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
Formal liaisons also tracked at
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?