Extensions to GRSVPTE for Point to Multipoint TE LSPs draftraggarwamplsrsvptep2mp01.txt

1
Extensions to G/RSVP-TE for Point to Multipoint
TE LSPsltdraft-raggarwa-mpls-rsvp-te-p2mp-01.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 San Diego

• Succeed in delivering a consistent merged
  solution
• Resolution on sub-group based state management
  and update (Path and Resv message)
• Devise methods for implicit and explicit teardown
  (PathTear message)
• Revision of the FF and SE flow descriptor lists
  (Resv message)
• Revision of the remerging conditions and
  processing rules
• the change log v00 gt v01.txt has been made
  available on the web page lthttp//www.labn.net/di
  mitrigt

3
State management (1)

• Issue solve incremental updates/aggregate state
  management and potential fragmentation on ERO
  expansion
• Proposal ltsub-group originator ID, sub-group IDgt
  
• Sub-group originator ID TE Router-id of the node
  (ingress, transit) that sets the sub-group ID
  value.
• Sub-group ID identifier (in the context of the
  sub-group originator ID) used to differentiate
  multiple Path messages that signal state for the
  same P2MP LSP Tunnel.
• The ltsub-group originator ID, sub-group IDgt tuple
  is globally unique.

4
State management (2)

• Two ways to encode the above information
• a) Encode the ltsub-group originator ID, sub-group
  IDgt tuple in the P2MP sender template (new
  sender-template C-type value).
• b) Encode the ltsub-group originator ID, sub-group
  IDgt as the first object of the ltP2P_sub_LSP_
  descriptor listgt
• Polling
• all agree on ltsub-group originator ID, sub-group
  IDgt tuple those that favor b) encoding can live
  or are not opposed to solution a) encoding
• gt do we get consensus of the group ?

5
Open Issues (1)

• 1) STYLE usage
• SE vs FF style usage
• conditions for resource sharing
• gt new section needed
• 2) P2MP SENDER_TEMPLATE object and FILTER_SPEC
  object encoding specifics  
• gt Section 24.2
• 3) Review re-merge/cross-over conditions
  re-merging or re-pair (case when data plane is
  not blocking)
• gt Section 23

6
Open Issues (2)

• 4) Re-optimization
• single/subset of P2P sub-LSP within a sub-group
• single/subset of sub-groups
• note requires consensus whether re-optimization
  may be performed on P2P sub-LSP basis or/and on
  sub-tree basis ?
• gt Section 19
• 5) Sub-ERO compression re-organisation (after
  grafting/pruning) device specific mechanisms for
  SERO such re-organisation (or is the current
  proposed text sufficiently tackling the issue ?)
  gt Section 3.4, 10 and 11
• 6) Stitching mechanism detail (P2MP and P2MP,
  P2MP and P2P) in the scope of inter-domain
  effort

7
Next Steps

• revision.1 (i.e. draft-raggarwa-mpls-rsvp-te-p2mp-
  01.txt) will be submitted after meeting as
  working i-d
• see mail on the MPLS WG mailing list
• lthttp//www.cell-relay.com/mhonarc/mpls/current/ms
  g00008.htmlgt
• revision.2 with revisited organization
  terminology before starting over
• to be achieved before starting incorporating new
  discussion point resolutions
• this should be closed by end-november at most
• technical points to be addressed from this rev.2

8
Backup Slides
9
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)

10
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)

11
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

12
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

13
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) ?

14
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)

15
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

16
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 ?