Extensions to g rsvp te for point to multipoint te lsps draft raggarwa mpls rsvp te p2mp 01 txt
This presentation is the property of its rightful owner.
Sponsored Links
1 / 16

Extensions to G/RSVP-TE for Point to Multipoint TE LSPs PowerPoint PPT Presentation


  • 88 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

Extensions to G/RSVP-TE for Point to Multipoint TE LSPs

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


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>

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)


Achievements since san diego

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>


State management 1

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.


State management 2

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 ?


Open issues 1

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


Open issues 2

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


Next steps

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


Backup slides

Backup Slides


Achievements since seoul 1

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)


Achievements since seoul 2

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)


Open issue 1 state management

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


Open issue 2 incremental state update

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


Open issue 3 re optimization

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


Open issue 4 re merging

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)


Open issue 5 recovery

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


Conclusion next steps

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 ?


  • Login