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

<draft-raggarwa-mpls-rsvp-te-p2mp-00.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 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)

• 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

• 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

• 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 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 =>

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

Open Issue 3: Re-optimization

Impact of partial re-optimization requires extra identifier => P2P Sub-LSP ID (+ scope)

Refers to the following requirements:

1) Do we need partial re-optimization ? – definition of partial re-optimization (functional) – mechanism of partial re-optimization (signaling)

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

3) Is it acceptable to only support full tree re-optimization (no data replication) ?

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

• 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

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