1 / 16

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

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

jontae
Télécharger la présentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Extensions to G/RSVP-TE for Point to Multipoint TE LSPs<draft-raggarwa-mpls-rsvp-te-p2mp-01.txt> 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 => v01.txt has been made available on the web page <http://www.labn.net/~dimitri>

  3. State management (1) • Issue: solve incremental updates/aggregate state management and potential fragmentation on ERO expansion • Proposal: <sub-group originator ID, sub-group ID> • 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 <sub-group originator ID, sub-group ID> tuple is globally unique.

  4. State management (2) • Two ways to encode the above information: a) Encode the <sub-group originator ID, sub-group ID> tuple in the P2MP sender template (new sender-template C-type value). b) Encode the <sub-group originator ID, sub-group ID> as the “first” object of the <P2P_sub_LSP_ descriptor list> • Polling: • all agree on <sub-group originator ID, sub-group ID> tuple; those that favor b) encoding can live or are not opposed to solution a) encoding => do we get consensus of the group ?

  5. Open Issues (1) 1) STYLE usage: • SE vs FF style usage • conditions for resource sharing => new section needed 2) P2MP SENDER_TEMPLATE object and FILTER_SPEC object encoding specifics   => Section 24.2 3) Review re-merge/cross-over conditions + re-merging or re-pair (case when data plane is not blocking) => 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 ? => 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 ?) => 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 <http://www.cell-relay.com/mhonarc/mpls/current/msg00008.html> • 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 • <draft-raggarwa-mpls-p2mp-te-02.txt> • <draft-yasukawa-mpls-p2mp-rsvp-te-04.txt> • 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 • <NO_CONSENSUS> 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 > 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 (=> 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 => 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 => 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 => differentiate case with and without common segment after "re-merging" point • Data plane impact (blocking issue) • Control plane issue: • aggregate state on “merging point” => if Path/Refresh message with an incremental semantic then issue disappears • since same SESSION and SENDER_TSPEC objects => 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 • <draft-raggarwa-mpls-rsvp-p2mp-te-00.txt> is a reasonable basis for continuing this work • Consensus to make this document a MPLS WG I-d ?

More Related