Lsp trace over mpls tunnels
This presentation is the property of its rightful owner.
Sponsored Links
1 / 12

LSP-Trace over MPLS tunnels PowerPoint PPT Presentation


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

LSP-Trace over MPLS tunnels. draft-nitinb-lsp-ping-over-mpls-tunnel-01 Nitin BahadurJuniper Networks Kireeti KompellaJuniper Networks George SwallowCisco Systems IETF 70, MPLS WG, Vancouver. E. A. B. C. D. RSVP. RSVP. LDP. LDP. LDP. Tracing a hierarchical LSP.

Download Presentation

LSP-Trace over MPLS tunnels

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


Lsp trace over mpls tunnels

LSP-Trace over MPLS tunnels

draft-nitinb-lsp-ping-over-mpls-tunnel-01

Nitin BahadurJuniper Networks

Kireeti KompellaJuniper Networks

George SwallowCisco Systems

IETF 70, MPLS WG, Vancouver


Tracing a hierarchical lsp

E

A

B

C

D

RSVP

RSVP

LDP

LDP

LDP

Tracing a hierarchical LSP

  • Options available at node B:

  • Do not allow tracing inside RSVP LSP

  • Allow tracing inside RSVP LSP


Problem scenario 1 tracing a hierarchical lsp

A

B

C

D

E

RSVP

RSVP

LDP

LDP

LDP

Problem scenario (1): Tracing a hierarchical LSP

  • Node B’s “effective” next-hop for LDP LSP is node D

    • However the “real” next-hop is node C

  • Node A sends echo request with LDP FEC to node C

  • Node C knows nothing about LDP FEC, so cannot perform FEC validation.

  • Node A cannot tell why it is getting a response from node C


Solution

E

A

B

C

D

RSVP

RSVP

LDP

LDP

LDP

Solution

  • Intermediate node (router B) provides a PUSH FEC stack tlv containing <RSVP> in DSMAP of echo response

  • Ingress (router A) pushes RSVP onto it’s FEC stack in echo request when sending next echo request (to router C)

  • When router D receives echo request with FEC stack containing <RSVP, LDP>, it sends Egress-Ok for RSVP FEC

    • Implicitly conveys that RSVP LSP is over -- pop it

  • Ingress (router A) now pops an entry from (local) FEC stack and resends echo request to router D with LDP FEC


Problem scenario ii tracing a stitched lsp

A

B

C

D

E

F

LDP

LDP

eBGP

RSVP

RSVP

Problem Scenario (II): Tracing a stitched LSP

No current mechanism to perform end-to-end trace of stitched LSPs.

Current trace mechanisms will only trace till router C.


Solution1

A

B

C

D

E

F

LDP

LDP

eBGP

RSVP

RSVP

Solution

  • Intermediate node (router C) provides a POP FEC stack sub-tlv (LDP) and PUSH FEC stack sub-tlv (eBGP) in DSMAP of echo response.

  • Ingress (router A) performs the corresponding stitch operation and sends eBGP FEC in next echo request (to router D)

  • Router D provides a POP FEC stack tlv (eBGP) and PUSH FEC stack sub-tlv (RSVP) in DSMAP of echo response.

  • Ingress (router A) performs the corresponding stitch operation and sends RSVP FEC in next echo request (to router E)

  • Router F responds with EGRESS_OK for the end-to-end LSP.


Solution concept

Solution concept

  • Intermediate routers provide ingress information regarding:

    • start of a new tunnel

    • end of a tunnel

    • tunnel stitch.

  • FEC details can be hidden by sending a NIL FEC, instead of actual FEC being pushed.

  • Analogous to push/pop operations in the data-plane.

  • Main logic at ingress application to correctly traverse the tunnels


Tlv changes proposed

TLV changes proposed …

  • Builds on RFC 4379 (LSP-Ping)

  • Downstream Mapping TLV deprecated

    • Not extensible: can’t have sub-TLVs (blame Kireeti!)

    • Not easy to associate new information in echo response

  • Downstream detailed mapping TLV introduced

    • Similar to previous one

    • Contains sub-TLVs to represent all variable length things

    • New sub-TLVs can be added in future to associate things with DSMAP.

  • Procedures outlined to deal with old and new TLV formats.


Downstream detailed mapping tlv

Downstream Detailed Mapping TLV

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| MTU | Address Type | DS Flags |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Downstream IP Address (4 or 16 octets) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Downstream Interface Address (4 or 16 octets) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Sub-tlv length | Reserved |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+ +

+ List of Sub TLVs +

+ +

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Ddmap sub tlvs

DDMAP Sub-TLVs

Multipath Sub-TLV

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|Multipath Type| Multipath Length | Reserved |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| |

| (Multipath Information) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Label-stack Sub-TLV

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Downstream Label | Protocol |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

. .

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Downstream Label | Protocol |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Ddmap sub tlvs contd

DDMAP Sub-TLVs (contd.)

Stack change sub-TLV

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|Operation Type| Address type| FEC-tlv length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Remote Peer Address (0, 4 or 16 octets |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

. .

. FEC TLV .

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Operation Type # Operation

----------------------- ---------

1 Push

2 Pop


Next steps

Next Steps

  • WG feedback on problem/solution

  • Adopt as WG doc ?


  • Login