[CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

["Rakesh Gandhi (rgandhi)" <[e-mail]>]

Dear WG,

We like to request a review from the WG on the changes in version 04 of the draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp compared to version 03. 

The majority of the proposed changes are around the format and how to populate the extended association object as listed below.

Note: Based on the feedbacks received so far, changes for items 4 and 5 below will be reverted.

1. Association-ID:
It was not clear from reading the version 03 of the draft how this field is populated in the extended association object. New version 04 proposes to populate this field from the locally provisioned value. As this value is identically provisioned on both ends, it provides a field to tie the two (forward and reverse) LSPs on end-points.

2. IPv4 association source:
New version 04 adds a tie breaker rule for double sided provisioned LSPs.

3. Global association source:
New version clarifies the usage for this field siting information from RFC6370 and other mentioned drafts. No new rule added.

4. Association Type and Association Flags:
New version proposes to use one association Type for single and double sided provisioned bi-directional LSPs and define association flags for them. These changes will be reverted as they are not necessary. There will not be Association Flags field in the next version.

5. Support for co-routed LSPs:
New version 04 defines a flag and handling for co-routed LSPs. Based on the WG feedback received, these changes will be reverted.

6. Extended Association ID (Address):
New version 04 proposes to use an IP address as extended association ID (address) as an additional identifier. Previous version 03 defines a variable length field but did not mention what parameters can be added there.
A tie breaker rule is defined for double sided provisioned value.

7. Path Protection object:
Version 03 of the draft vaguely mentioned and assumed of using protection object for path protection. New version 04 adds some texts to clarify it, no new rule is added.

8. Auto-tunnel mesh:
New version 04 adds a section to elaborate on a use case for auto-tunnel mesh. This is added as an FYI and can be removed if WG thinks so.

9. Clarification for Inter-AS LSPs:
I believe there was an email exchange between Lou and Fei to clarify the relationship with draft I-D, draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num. A section is added in version-04 to address this. Please review the added text.

Please advise us on above changes. Based on the consensus, we will update the draft accordingly.

Thanks,
Rakesh
 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Wednesday, August 15, 2012 10:53 AM
To: Rakesh Gandhi (rgandhi)
Cc: [e-mail]; [e-mail]
Subject: New Version Notification for draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt


A new version of I-D, draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
has been successfully submitted by Rakesh Gandhi and posted to the IETF repository.

Filename:	 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp
Revision:	 04
Title:		 RSVP-TE Extensions for Associated Bidirectional LSPs
Creation date:	 2012-08-15
WG ID:		 ccamp
Number of pages: 17
URL:             http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
Status:          http://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp
Htmlized:        http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04
Diff:            http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04

Abstract:
   The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654],
   describes that MPLS-TP MUST support associated bidirectional point-
   to-point LSPs.

   This document provides a method to bind two unidirectional Label
   Switched Paths (LSPs) into an associated bidirectional LSP.  The
   association is achieved by defining the new Association Type in the
   Extended ASSOCIATION object.

                                                                                  


The IETF Secretariat