1 / 6

On the association of GMPLS Recovery LSPs draft-berger-ccamp-assoc-info-00.txt

On the association of GMPLS Recovery LSPs draft-berger-ccamp-assoc-info-00.txt. Lou Berger <lberger@labn.net>. Background. Recovery LSP association -- How does it work? Question raised by Nic Neate Discussed in IETFs 72 & 73 and e-mail

vartan
Télécharger la présentation

On the association of GMPLS Recovery LSPs draft-berger-ccamp-assoc-info-00.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. On the association of GMPLS Recovery LSPsdraft-berger-ccamp-assoc-info-00.txt Lou Berger <lberger@labn.net> CCAMP - 76th IETF

  2. Background • Recovery LSP association -- How does it work? • Question raised by Nic Neate • Discussed in IETFs 72 & 73 and e-mail • At IETF 74: WG agreed to publish individual informational draft so that perceived issue can be closed. • At IETF 75: this draft presented • What does the association object look like?for: • End to end recovery (A-B-C-D-E, A-F-G-H-E) • Segment recovery (B-G-D) A B C D E F G H CCAMP - 76th IETF

  3. Draft Overview • Informational • No new procedures or formats • Is essentially formal write of Adrian’s E-mail on the topic • Subject: Re: Clearing up your misunderstanding of the Association ID • From: "Adrian Farrel" <adrian at olddog.co.uk> • Date: Tue, 18 Nov 2008 22:34:14 -0000 • http://www.ietf.org/mail-archive/web/ccamp/current/msg00644.html • Covers ASSOCIATION Object as defined in RFC 4872 and RFC 4873 • Reviews object definition • Analyzes conformance (RFC2119) language of each • Identifies valid Association ID use cases • Describes receiver processing to handle cases CCAMP - 76th IETF

  4. Association ID – Use Cases • Cases are defined by which is initialized first: • The ASSOCIATION object of the LSP being protected • The ASSOCIATION object of a recovery LSP • When the ASSOCIATION objects are concurrently initiated • Cases differ • In values used in Association ID field • In applicability to end-to-end (E2E) and segment recovery CCAMP - 76th IETF

  5. Resulting Receiver Behavior • The following downstream Path message processing ensures identification of recovery association in all discussed cases: • Covering cases 1 and 2: • Match LSPs with identical ASSOCIATION objects • Also works for Resource Sharing Association Types • When objects match, an end-to-end or segment association of the indicated type exists. • Covering Case 3: • Check only performed on egress • Match identified by comparing an LSP’s LSP ID with the Association ID of other LSPs with identical tunnel sender addresses. When compared values are identical, an end-to-end recovery association exists • Note that as multiple associations are possible all association objects need to examined. CCAMP - 76th IETF

  6. Results • Conclusions from last IETF • No technical disagreement • No update planned • Dimitri proposed rolling into RFC4872/73 BIS • But we don’t have drafts • Proposed next steps • WG or individual draft? • Work requested by WG, but is informational • Submit for publication or Last call? CCAMP - 76th IETF

More Related