1 / 6

Future-Proof TLV Codepoint Space for LSP Ping

Future-Proof TLV Codepoint Space for LSP Ping. Adrian Farrel and George Swallow draft-farrel-mpls-lsp-ping-tlvs-01.txt. LSP Ping – RFC 4379. Messages are built from TLVs TLVs may contain sub-TLVs TLV/sub-TLV Type numbers managed by IANA Valid range for TLVs and sub-TLVs is 0-65535

liberty-holland
Download Presentation

Future-Proof TLV Codepoint Space for LSP Ping

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. Future-Proof TLV Codepoint Space for LSP Ping Adrian Farrel and George Swallow draft-farrel-mpls-lsp-ping-tlvs-01.txt 70th IETF Vancouver December 2007

  2. LSP Ping – RFC 4379 • Messages are built from TLVs • TLVs may contain sub-TLVs • TLV/sub-TLV Type numbers managed by IANA • Valid range for TLVs and sub-TLVs is 0-65535 • Code-spaces are sub-divided… • 0-16383 Standards Action • 16384-31743 Specification Required • 31744-32767 Vendor Private Use - MUST NOT be allocated by IANA • 32768-49161 Standards Action • 49162-64511 Specification Required • 64512-65535 Vendor Private Use - MUST NOT be allocated by IANA 70th IETF Vancouver December 2007

  3. RFC 4379 – Processing Rules • Ranges are subdivided according to MSB • Types LT 32768 are mandatory TLVs • Either MUST be supported by an implementation • Or MUST result in the return code “One or more of the TLVs was not understood” echo response. • Types GTE 32768 are optional TLVs • SHOULD be ignored if the implementation does not understand or support them 70th IETF Vancouver December 2007

  4. Question? • Are the TLV ranges sufficient for forward compatibility? • What if we want to define a new TLV that is: • Used for trace-route • Mandatory at egress • Not important at transit • Can we devise a set of rules that are future-proof? • Subdivide the code-spaces further • Remain backward compatible • Don’t allocate too many bits from the code-space 70th IETF Vancouver December 2007

  5. Proposed TLV Rules • Support for the TLV is mandatory • If the TLV is not recognized the message MUST be dropped and an • LSP Ping error MUST be reported according to the normal protocol procedures. • Support for the TLV is mandatory at an egress LSR, but is optional at a transit LSR. • At an egress LSR, if the TLV is not recognized the message MUST be dropped and an LSP Ping error MUST be reported according to the normal protocol procedures. • At a transit LSR, if the TLV is not recognized, the TLV SHOULD be ignored. The rest of the message MUST be processed as normal. • Support for the TLV is optional at all nodes • At a transit or egress LSR, if the TLV is not recognized, the TLV SHOULD be ignored. • The rest of the message MUST be processed as normal. • Ignore the entire message if TLV is unrecognized • If the TLV is unrecognized the entire message SHOULD be ignored by the LSR. • The LSR MUST NOT perform any processing associated with the message or the other TLVs on the message. • Similar rules for Sub-TLVs • Only needs two bits 70th IETF Vancouver December 2007

  6. Next Steps • Get some community input • Already talking with Nitin (Juniper) • Need to decide if this is needed • (We think so) • Agree the set of actions for unknown TLVs • Move forward quickly • WG status • Last call • Overtake (used by) new LSP Ping I-Ds 70th IETF Vancouver December 2007

More Related