CCAMP Liaisons and Communications

Slides:



Advertisements
Similar presentations
Intra-Carrier Solutions Enabled by the OIF NNI Erning Ye Nortel Networks.
Advertisements

CCAMP WG, IETF 80th, Prague, Czech Republic draft-gonzalezdedios-subwavelength-framework-00 Framework for GMPLS and path computation support of sub-wavelength.
RSVP-TE Extensions for SRLG Configuration of FA
76th IETF Hiroshima, November CCAMP Working Group Status Chairs: Lou Berger Deborah Brungard.
G : DCM Signaling Mechanism Using GMPLS RSVP-TE ITU-T Workshop on IP-Optical, Chitose, Japan 7/11/2002 Dimitrios Pendarakis, Tellium, Inc. ITU-T.
All Rights Reserved © Alcatel-Lucent 2006, ##### Scalability of IP/MPLS networks Lieven Levrau 30 th April, 2008 France Telecom, Cisco Systems, uawei Technologies,
Problem Statement and Architecture for Information Exchange Between Interconnected Traffic Engineered Networks draft-farrel-interconnected-te-info-exchange-03.txt.
Ethernet TSPEC and MEF Parameters draft-ietf-mef-ethernet-traffic-parameters-01.txt
69th IETF Chicago, July 2007 CCAMP Working Group Charter and Liaisons.
Extensions to OSPF-TE for Inter-AS TE draft-ietf-ccamp-ospf-interas-te-extension-01.txt Mach Renhai
ITU/OIF Liaison Report Lyndon Ong Ciena March 24, 2006.
Contribution Number: oif Working Group: Architecture & Signaling Title: Project proposal for interworking of G RFC 3473 network domains.
WG Document Status 192nd IETF TEAS Working Group.
1 CCAMP Working Group Status Chairs: Lou Berger Deborah Brungard Secretary: Dan King 80th IETF CCAMP WG.
WSON Summary Young Lee Document Relationships Information Gen-constraints Encode WSON Encode Signal Compatibility OSPF Gen-constraints.
Framework for G.709 Optical Transport Network (OTN) draft-ietf-ccamp-gmpls-g709-framework-05 CCAMP WG, IETF 82 nd Taipei.
MPLS-TP - 77th IETF1 MPLS-TP Control Plane Framework draft-abfb-mpls-tp-control-plane- framework-02.txt Contributors: Loa Andersson Lou Berger Luyuan Fang.
1 Requirements for GMPLS-based multi-region and multi-layer networks (MRN/MLN) draft-ietf-ccamp-gmpls-mln-reqs-01.txt CCAMP WG, IETF 66 Jul. 10, 2006 Kohei.
79th IETF CCAMP WG1 CCAMP Working Group Status Chairs: Lou Berger Deborah Brungard.
ITU-T Study Group 15 Communications to IETF CCAMP Working Group Wesam Alanqar ITU-T SG15 Representative to IETF CCAMP
70th IETF Vancouver, December 2007 CCAMP Working Group Status Chairs: Deborah Brungard : Adrian Farrel :
OIF Liaison on Routing IETF 75 – Stockholm – Jul ‘09 L. Ong (Ciena)
IETF 80: NETEXT Working Group – Logical Interface Support for IP Hosts 1 Logical Interface Support for IP Hosts Telemaco Melia, Sri Gundavelli, Carlos.
64th IETF Vancouver November 2005 ASON-Compatible Signaling.
ITU Liaison on T-MPLS Stewart Bryant
CCAMP Working Group Online Agenda and Slides at: Data tracker:
Ning So Andrew Malis Dave McDysan Lucy Yong Fredric Jounay Yuji Kamite
Transmission of IP Packets over IEEE 802
draft-jounay-pwe3-dynamic-pw-update-00.txt IETF 70 PWE3 Working Group
Connecting MPLS-SPRING Islands over IP Networks
ID Tracker States: An Internet Draft’s Path Through the IESG
GMPLS Signaling Extensions for G
Zhenbin Li, Li Zhang(Huawei Technologies)
Applicability Statement for Layer 1 Virtual Private Networks (L1VPNs) Basic Mode draft-takeda-l1vpn-applicability-basic-mode-00.txt Deborah Brungard (AT&T)
Open issues with PANA Protocol
Daniel King, Old Dog Consulting Adrian Farrel, Old Dog Consulting
draft-ietf-idr-ls-distribution-02
Service Provider Requirements for Ethernet Control with GMPLS
CCAMP Working Group Status
FlexE - Channel Control Work in the IETF
DS-TE protocol Extensions DS-TE Russian Dolls Model (RDM) DS-TE Maximum Allocation Model (MAM) draft-ietf-tewg-diff-te-proto-04.txt draft-ietf-tewg-diff-te-russian-03.txt.
Tomohiro Otani Kenji Kumaki Satoru Okamoto Wataru Imajuku
Requirements for Ring Protection in MPLS-TP
ASON routing implementation and testing ASON routing extensions
Architecture for Scheduled Use of Resources draft-zhuang-teas-scheduled-resources-00 Yan Zhuang Qin Wu
Daniel King, Old Dog Consulting Adrian Farrel, Old Dog Consulting
Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G
PCEP Extensions For Transporting Traffic Engineering (TE) Data
Point-to-Multipoint Pseudo-Wire Encapsulation draft-raggarwa-pwe3-p2mp-pw-encaps-00.txt R. Aggarwal (Juniper)
MPLS-TP Survivability Framework
IETF 78th Maastricht, Netherlands, July 2010
Daniel King, Old Dog Consulting Adrian Farrel, Old Dog Consulting
CCAMP WG Meeting IETF 58 - Minneapolis - Nov’03
Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with GMPLS draft-ietf-ccamp-gmpls-vcat-lcas-02.txt Greg Bernstein.
Igor Bryskin - Adrian Farrel -
FlexE - Channel Control Work in the IETF
ITU-T Study Group 15 Update to IETF CCAMP
Protection & Restoration Design Team - CCAMP WG
GMPLS Signaling Extensions for the Evolving G.709 OTN Control
Guard Bands requirements for GMPLS controlled optical networks
OSPF Extensions for ASON Routing draft-ietf-ccamp-gmpls-ason-routing-ospf-03.txt IETF67 - Prague - Mar’07 Dimitri.
Zhenbin Li, Shunwan Zhuang Huawei Technologies
IETF South Korea PCEP Link-State extensions for Segment Routing draft-li-pce-pcep-ls-sr-extension-01 Zhenbin Li (Huawei) Xia Chen (Huawei) Nan.
OSPF WG Status IETF 98, Chicago
1 Multi-Protocol Label Switching (MPLS). 2 MPLS Overview A forwarding scheme designed to speed up IP packet forwarding (RFC 3031) Idea: use a fixed length.
Technical Issues with draft-ietf-mpls-bfd-directed
BPSec: AD Review Comments and Responses
Editors: Bala’zs Varga, Jouni Korhonen
ISIS Extensions for FlexE Link Advertisement
DetNet Data Plane Solutions draft-ietf-detnet-dp-sol-ip-02  draft-ietf-detnet-dp-sol-mpls-02  Bala’zs Varga, Jouni Korhonen, Janos Farkas, Lou Berger,
Presentation transcript:

CCAMP Liaisons and Communications Adrian Farrel adrian@olddog.co.uk Deborah Brungard dbrungard@att.com 68th IETF – Prague – March 2007

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

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!

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…

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

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?

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?

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?

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?

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

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

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?

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?