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

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

• Jun-Hyun, Moon
• Computer Communications LAB.,
• Kawangwoon University
• imp_at_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
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 LSPs)
  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 gt tunnel for Ethernet payload
  transport w/o necessarily using MPLS PWs 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 RFCs
• Get agreement on GPIDs 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 ?)
• gt 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
Motivation and Contribution

• Resource within bundled TE link is specification
  by TE Link ID, Component interface ID, Label
  value

• 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

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 PR 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