Extensions%20to%20G/RSVP-TE%20for%20Point%20to%20Multipoint%20TE%20LSPs%20<draft-raggarwa-mpls-rsvp-te-p2mp-00.txt>

1
Extensions to G/RSVP-TE for Point to Multipoint
TE LSPsltdraft-raggarwa-mpls-rsvp-te-p2mp-00.txtgt

• R.Aggarwal, D.Papadimitriou, and S.Yasukawa
  (Editors) and contributors (L.Berger, I.Bryskin,
  D.Cheng, J.Drake, A.Farrel, M.Jork, H.Kojima,
  K.Kompella, A.Kullberg, J-L Leroux, A.Malis,
  K.Sugisono, G.Swallow, M.Uga, J.-P.Vasseur, and
  L.Wei)

2
Achievements since Seoul (1)

• A single solution framework merge between
• ltdraft-raggarwa-mpls-p2mp-te-02.txtgt
• ltdraft-yasukawa-mpls-p2mp-rsvp-te-04.txtgt
• P2MP TE LSP set of P2P sub-LSPs, each from
  ingress to the leaf
• P2MP TE LSP Identification
• New P2MP SESSION C-Type with P2MP Id as
  destination
• SENDER_TEMPLATE and FILTER_SPEC objects remain
  unchanged
• P2P sub-LSP identification
• P2P SUB-LSP object with leaf destination address
• ltNO_CONSENSUSgt on sub-LSP ID in P2P SUB-LSP or
  sub-Group_ID in SENDER_TEMPLATE object
• Multiple Path messages can be used to signal a
  single P2MP TE LSP
• Each Path message signals one or more P2P
  sub-LSPs
• When multiple P2P sub-LSPs in one Path message
  ERO/RRO compression scheme and processing (one
  sub-ERO per P2P sub-LSP)

3
Achievements since Seoul (2)

• Legacy LSR support method(s)
• LSP stitching
• ( P2P FA-LSP when applicable)
• Fast Reroute (MPLS only) Facility based Detour
  style protection
• Reach consensus on solution requirements
• support full refresh mechanisms (summary refresh
  optional but recommended)
• address message fragmentation (message size gt
  MTU)
• support aggregated state management and
  incremental state updates
• metrics messaging comparison semantic impact
  of protocol extensions including on existing
  implementation
• node capabilities to be assessed and detailed in
  a routing specific document
• Single vs Multiple P2P sub-LSP in single Path
  message
• dedicated section on refresh reduction (gt
  applicability of RFC 2961)
• dedicated section on incremental state updates
  and aggregate state management
• Remaining open issues identified and are under
  discussion (next slides)

4
Open Issue 1 State management

• As part of the state management discussion
• Issue sub-Group ID versus sub-LSP ID
• Sub-Group ID identifier of destination (set)
• Extreme case sub LSP_ID on the other end
  equivalent to the P2MP LSP_ID (ingress control)
• Disambiguate message size (single Path) and group
  Path message together that collectively represent
  the P2MP TE LSP
• Fragmentation and/or Aggregated state but still
  require an ID for sub-tree re-optimization
• Investigate potential usage for incremental
  updates

5
Open Issue 2 Incremental state update

• RSVP RFC2205 and G/RSVP-TE RFC3473/RFC3209
• signaling of resource reservation by full state
  communication and synchronization in each state
  advertisement message
• RFC2205 Path and Resv messages are
  idempotent.
• Refresh Overhead Reduction Extensions RFC2961
• improvements to message handling and scaling of
  state refreshes
• does not modify full state advertisement nature
  of Path/Resv messages
• Full state advertisement in Path/Resv has some
  drawbacks when only portion(s) of previously
  advertised state modified gt processing overhead
  in identifying what state portion has changed
  message overhead of sending full state
• Extend RSVP to reduce message size and state
  processing associated w/ state change (support
  incremental state updates and optimize state
  change processing) - on a hop-by-hop basis and
  particularly when Refresh Reduction is also
  supported

6
Open Issue 2 Incremental state update

• Two documented proposals
• Based on refresh reduction
• incremental State/Message (iPath/iResv,
  iPathTear/iResvTear)
• Evaluation criteria
• is capability provided when refresh reduction is
  NOT supported
• is state management based on session,
  sender_template
• does adding, moving or deleting a sub-set of
  sub-LSPs, necessitate creation of new state and
  separate management of the old states(s) (timed
  out ?)
• how the method solves ( implementation specific)
  these properties gt performance gain vs cost of
  the mechanisms introduced
• Solution direction
• new proposal based on sub-Group ID
  (sender_template encoding to be refined)
• to be further elaborated

7
Open Issue 3 Re-optimization

• Impact of partial re-optimization requires extra
  identifier gt P2P Sub-LSP ID ( scope)
• Refers to the following requirements
• Do we need partial re-optimization ?
• definition of partial re-optimization
  (functional)
• mechanism of partial re-optimization (signaling)
• Do we need partial re-optimization if there is
  data replication during transient ?
• there are mechanisms that are minimizing data
  replication
• from req i-d such mechanism SHOULD be defined
• Is it acceptable to only support full tree
  re-optimization (no data replication) ?

8
Open Issue 4 Re-merging

• Occurs when nodes receives two streams from at
  least two different P_HOPs and data sent to the
  same or multiple outgoing interfaces gt
  differentiate case with and without common
  segment after "re-merging" point
• Data plane impact (blocking issue)
• Control plane issue
• aggregate state on merging point gt if
  Path/Refresh message with an incremental semantic
  then issue disappears
• since same SESSION and SENDER_TSPEC objects gt
  rely on P2P sub LSP_ID
• Example where re-merging would be allowed change
  color/priority in the middle of the P2MP tree
  (per sub-tree due to administrative policies)

9
Open Issue 5 Recovery

• There is general agreement on Fast Reroute
  applicability (MPLS only)
• Facility based protection
• Detour style protection
• Fast Reroute text to be moved in a separate
  document once the base text is mature
• GMPLS remains to be covered

10
Conclusion Next steps

• Building blocks of the single solution are in
  place
• Remaining open issues are being discussed and
  should be resolved within a short timeframe
• Further progress achieved since draft was
  published
• More discussion from the MPLS WG list is also
  expected
• ltdraft-raggarwa-mpls-rsvp-p2mp-te-00.txtgt is a
  reasonable basis for continuing this work
• Consensus to make this document a MPLS WG I-d ?