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

Lou Berger <lberger@labn.net> Fri, 24 August 2012 20:40 UTC

Return-Path: <lberger@labn.net>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51CB521F8596 for <ccamp@ietfa.amsl.com>; Fri, 24 Aug 2012 13:40:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.406
X-Spam-Level:
X-Spam-Status: No, score=-99.406 tagged_above=-999 required=5 tests=[AWL=0.755, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51BGrYTZCgFi for <ccamp@ietfa.amsl.com>; Fri, 24 Aug 2012 13:40:56 -0700 (PDT)
Received: from oproxy11-pub.bluehost.com (unknown [IPv6:2605:dc00:100:2::a3]) by ietfa.amsl.com (Postfix) with SMTP id B4DB221F858E for <ccamp@ietf.org>; Fri, 24 Aug 2012 13:40:48 -0700 (PDT)
Received: (qmail 771 invoked by uid 0); 24 Aug 2012 20:40:47 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy11.bluehost.com with SMTP; 24 Aug 2012 20:40:47 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=BgcTZQSSSKilXP/wBX+z/Y7YCWGUsJZwkPLC+SrMFt0=; b=aWYWa1S7fSmP8DmCQy9v41QvxbKCoCJ1hGmjI82+05H1j1wOUoyFWZqYK3MzRpErRNfpEstm7uGoYgVgCmt5JlEabnFElbdKsl1wl2OCBV016+8uLottAKZr57LwW1V8;
Received: from box313.bluehost.com ([69.89.31.113]:56680 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from <lberger@labn.net>) id 1T50gR-00076k-JY; Fri, 24 Aug 2012 14:40:47 -0600
Message-ID: <5037E6C4.5050507@labn.net>
Date: Fri, 24 Aug 2012 16:40:36 -0400
From: Lou Berger <lberger@labn.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: "Rakesh Gandhi (rgandhi)" <rgandhi@cisco.com>
References: <B7D2A316AA32B6469D9670B6A81B7C24071272@xmb-aln-x07.cisco.com> <5037C010.7010605@labn.net> <B7D2A316AA32B6469D9670B6A81B7C240721E2@xmb-aln-x07.cisco.com>
In-Reply-To: <B7D2A316AA32B6469D9670B6A81B7C240721E2@xmb-aln-x07.cisco.com>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Cc: "ccamp@ietf.org" <ccamp@ietf.org>
Subject: Re: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Aug 2012 20:40:57 -0000

Rakesh,

See below.

On 8/24/2012 2:31 PM, Rakesh Gandhi (rgandhi) wrote:
> Hi Lou,
> 
> Thanks for your review. Please see inline..<RG>..
> 
> -----Original Message-----
> From: Lou Berger [mailto:lberger@labn.net] 
> Sent: Friday, August 24, 2012 1:55 PM
> To: Rakesh Gandhi (rgandhi)
> Cc: ccamp@ietf.org
> Subject: Re: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
> 
> Rakesh,
> 
> Speaking as a WG participant, and ignoring changes 4 and 5 as you plan to revert these:
> 
> On 8/23/2012 12:20 PM, Rakesh Gandhi (rgandhi) wrote:
>> 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 and 5 removed form mail as to 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.
>>
> 
> Assuming changes 1, 2, and 6, how is uniqueness (of the association ID
> field) guaranteed?
> 
> <RG> 1, 2 and 6 <association-id, source, destination> together uniquely represent a bidirectional LSPs in a network. In this proposal association ID can be shared by multiple tunnels on the same source node.
> 

Sure, but who picks the association-id such that uniqueness is assured
in the double sided provisioning case?

If assuming this is always provisioned, then how does the provisioning
entity, which may be one or more people at a CLI, pick the
association-id such that it is unique across the tuple <association-id,
ingress, egress>?  (neither a single provision device nor polling the
ingress and egress are really reasonable solutions.)

Wouldn't it be better for the Association Source and Association ID to
be administratively set? e.g., to the IP address and value selected by
the provisioning source. (Extended Association ID could also be used if
desired, but I'm not sure it really adds 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.
>>
> 
> I think providing informative text on interactions of this document with the various defined recovery (4872 and 4872) and reroute (4090) mechanisms is a really good idea.  That said, I found this section a bit opaque.  Ignoring the wordsmithing, what specific points are you trying to make?
> 
> <RG> It just highlights that for a bi-directional tunnel, there can be a working bidirectional LSPs and protecting bidirectional LSPs. That's all.
> 

I think the proposed text is really confusing and doesn't cover the full
scope (in particular 4872 is about recovery which is both protection and
restoration, it doesn't cover 4873 or 4090). Can you propose (one the
list) some alternate text?

> 
>> 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.
>>
> 
> How is the association id field value selected in this case?
> 
> <RG> Proposal allows that single association-id can be provisioned for a mesh-group. 
I don't think you have text that supports this.  The closest you come is:
   A node provisioned to
   build a mesh of associated bidirectional LSPs may use identical
   association ID for the given mesh-group member peers.

which doesn't say that the "identical association ID" MUST be provisioned.

Lou

>> So when a node initiates multiple auto-tunnels in a mesh-group, as per previous definition, a tunnel can be uniquely identified with <association-id, source, destination>, i.e. extended association object.
> 



> 
>> 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.
>>
> 
> Well I (as chair) had asked in Vancouver that the authors of rsvpte-ext-tunnel-num propose some language *on the list* that would merge the functionality defined in that document into the WG document.
> The mailing list discussion concluded with Fei stating that he want to keep the drafts separate, which certainly is his call (as one is an individual draft).  So to be clear, I have not requested any references to rsvpte-ext-tunnel-num in the WG draft.
> 
> This section does highlight the issue of how remote global_ID can be learned in the interdomain case.  I think the stated solution doesn't work with your current assignment approach, e.g., consider the case when the lower IP address is the egress of the initial LSP...
> 
> <RG> I will let Fei address this comment.
> 
> Thanks,
> Rakesh
> 
> 
> Lou
> 
> 
>> Please advise us on above changes. Based on the consensus, we will update the draft accordingly.
>>
>> Thanks,
>> Rakesh
>>  
>>
>> -----Original Message-----
>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
>> Sent: Wednesday, August 15, 2012 10:53 AM
>> To: Rakesh Gandhi (rgandhi)
>> Cc: zhang.fei3@zte.com.cn; jingrq@ctbri.com.cn
>> 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
>>
>> _______________________________________________
>> CCAMP mailing list
>> CCAMP@ietf.org
>> https://www.ietf.org/mailman/listinfo/ccamp
>>
>>
>>
>>
> 
> 
> 
>