CCAMP WG of the 58 th IETF Meeting (Other Draft)

1. CCAMP WG of the 58th IETF Meeting(Other Draft) Jun-Hyun, Moon Computer Communications LAB., Kawangwoon University imp@kw.ac.kr

2. Communicaton of Alarms draft-berger-ccamp-gmpls-alarm-spec-00.txt L. Berger (Movaz), D. Brungard (ATT), I. Bryskin (Movaz) A. Farrel (Old Dog Consulting), D. Papadimitriou (Alcatel) A. Satyanarayana (Movaz)

3. Node 172.16.25.6, IP Interface 1.1.3.2 Severity : Major, Condition: DATALOL Time : NOV 01 21 : 11 : 09 2003 Node 172.16.25.12, IP Interface 1.1.2.1 Severity : Critical, Condition: LOS Time : NOV 01 20 : 52 : 15 2003 The Not-A-Tutorial Slide • Pleased note: • The function described does not replace or modify any existing management plane function • Provides alarm information along full LSP

4. Open Issues • Non-Issues • Enabling/disabling alarm information communication • Uses new Admin_Status Bit • Communication of alarm information • Uses new Alarm_Spec object with same format as Error_Spec, plus new TLVs • Not modifying LSP state • Alarm_Spec sent in path and Resv messages • Compatibility • Two Open Issues • Use of new TLVs in Error_Spec • Error codes for well knows and standard Alarms

5. Issues (Continued) • Should the use of new the TLVs in Error_Spec be allowed? • Four new TLVs • Reference_count • Severity • Timestamp • Error_string • Code points for well known and standard Alarms • To be carried in Error Values using new Error Codes • Identified ITU and Telecordia specs use string not values • Options: • Define string to value mapping for some/every spec • Punt, i.e., stay with using strings

6. New Steps • Resolve open issues • Progress the draft • Does this fit into the charter? • WG document?

7. Generized MPLS Signaling for Layer-2 LSPs draft-papadimitriou-ccamp-gmpls-l2sc-lsp-00.txt D.Papadimitriou (Alcatel), D.Brungard (ATT), M.Vigoureux (Alcatel)

8. Why? • Goal : RFC 3473 support of L2SC LSPs • L2 switching architecture : [X, L2SC], … , [L2SC, L2SC], … , [L2SC, X] where X = Any (in particular, PSC) • Layered switching architectures (FA LSP’s) : [L2SC, Y], … , [Y, L2SC] where Y = Any (in particular, TDM or LSC) • Non-Goal : PW architecture (~ provisioned overlays over PSN)

9. L2SC LSP and Setup Methods • L2SC LSP => “tunnel” for Ethernet payload transport w/o necessarily using MPLS PW’s and other extended p2p LDP signaling • Method for e2e LSP Setup • Direct e2e LSP setup • LSP nesting (FA-LSP in network) • LSP stitching (LSP Segment in network) • LSP shuffling (~ GMPLS VPN)

10. LSP Nesting & Stitching/Shuffling

11. What do we need? • Not that much … since max re-use of existing GMPLS RFC’s • Get agreement on GPID’s e.g. GFP, X.86 • Get agreement on label semantic(s) e.g. Port, Flow, VLAN • Get agreement on bandwidth encoding (any enhancement from current TSPEC ?) => Support from the working group to refine GMPLS procedures for L2SC LSPs?

12. Component Link Recording and Resource Control for GMPLS Link Bundles draft-zamfir-exmplicit-resource-control-bundle-02.txt Anca Zamfir, Zafar Ali (Cisco Systems), D. Papadimitriou (Alcatel)

13. Label Recording Label RRO (RFC 3209 RFC 3473) Explicit Label Selection Label ERO (RFC 3473) Used for LSP splicing but not sufficient MUX/DEMUX capable component link of bundled TE Links Component Link recording Also desirable for diagnostics purposes (and for applications that can make use of this information) Explicit component link selection for application like “LSP splicing” and for selecting component link of desired SRLG attribute Motivation and Contribution • Resource within bundled TE link is specification by [TE Link ID, Component interface ID, Label value]

14. Update from Last IETF • Update the I-D based on WG feedback • Email follow-up on/off the list that show fair interest in RRO extension for component link recording • Component link recording independent of label recording (backward compatibility) using either LSP Attribute or Session_Attribute Flags (to be discussed) • Editorial and text improvement

15. Next Step • Next revision to include more details on motivations and direct applications (add introductory section) • Request the CCAMP WG to accept this I-d as a WG document

16. Expedited Flooding for Restoration inShared-Mesh Transport Networks • draft-rabbat-expedited-flooding-00 • Richard Rabbat (FLA) • Vishal Sharma (Metanoia, Inc.) • Zafar Ali (Cisco) • Observations • This work complementary to P&R team output • Captures all private and ML discussion and resolutions • Highlights time-bounded notification requirements for transport networks • Discusses mitigating factors to ensure no network meltdowns

17. Expedited Flooding • Describes types of failure • Fiber cut • Transponder failure • Node failure • Applies whether one adapts a link-state routing protocol behavior or implementing a new flooding mechanism • Reasoning behind using an expedited flooding protocol • Points out the advantages of flooding • Discusses approach to avoid network meltdowns • Sending messages on first try happens immediately • Retry attempts in the case of failure force a delay (using OSPF hold down timer or timers associated with new mechanism)

18. Expedited Flooding • Next Steps • We have received a lot of feedback on flooding-based notification • Need to advance draft to WG document since fits in charter