Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

Lou Berger <lberger@labn.net> Fri, 17 August 2012 12:38 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 EB5BD21F8539 for <ccamp@ietfa.amsl.com>; Fri, 17 Aug 2012 05:38:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.211
X-Spam-Level:
X-Spam-Status: No, score=-99.211 tagged_above=-999 required=5 tests=[AWL=0.938, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, 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 Vuvawp5ZjtiD for <ccamp@ietfa.amsl.com>; Fri, 17 Aug 2012 05:38:13 -0700 (PDT)
Received: from oproxy11-pub.bluehost.com (oproxy11-pub.bluehost.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id BDC9B21F847D for <ccamp@ietf.org>; Fri, 17 Aug 2012 05:38:12 -0700 (PDT)
Received: (qmail 17072 invoked by uid 0); 17 Aug 2012 12:37:50 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy11.bluehost.com with SMTP; 17 Aug 2012 12:37:50 -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=2G22sESVEmINIpwfr3jkjB9SiiHkcJjUKS4xl0rbRpE=; b=1bDY6YslVwTiEankzo3BtLQAfMGqH0PRFLQNfCWSdSeJXtOlf6WOiNPDdPL9XdHPA7BInxRwTNM8KQhTKEFBaIsElW9DmP8aF0IId7F3xhoNbFQ69PnA7U5C6i2ngBwo;
Received: from box313.bluehost.com ([69.89.31.113]:47331 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from <lberger@labn.net>) id 1T2LoE-0006CE-6o; Fri, 17 Aug 2012 06:37:50 -0600
Message-ID: <502E3B1C.4030200@labn.net>
Date: Fri, 17 Aug 2012 08:37:48 -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: zhang.fei3@zte.com.cn
References: <OFECE3928A.B1472469-ON48257A5D.0005EB19-48257A5D.00073948@zte.com.cn>
In-Reply-To: <OFECE3928A.B1472469-ON48257A5D.0005EB19-48257A5D.00073948@zte.com.cn>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: 8bit
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] I-D Action: 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, 17 Aug 2012 12:38:14 -0000

Fei,
	Okay, perhaps I read too much into the reference to FRR in the
discussion and current text.  I'm still trying to understand the
rational for the changes and the issues being addressed.

Any light you, or anyone else, can shed on this would be most appreciate.

Lou

On 8/16/2012 9:19 PM, zhang.fei3@zte.com.cn wrote:
> 
> Lou
> 
> Regarding B.1 and B.2
> 
> 2) Support for FRR bypass tunnels for piggybacked on the TP
> bidirectional LSP mechanisms
> 
> B.1) Articulate the FRR/GMPLS-related issue you'd like to address?
> 
> B.2) Articulate why this issue should be solved in a TP-specific and not
> GMPLS generic fashion?
> 
> I do not think we introduce the FRR bypass tunnels in this draft, which
> is used for local protection (RFC4090).
> 
> Do you see them in section 3.2.4 or section 3.2.6, I personally think
> they are GMPLS generic fashion and are totally informational.
> 
> If the descriptions mislead you, please give us some guidance and we are
> happy to revise them.
> 
> 
> Best regards
> 
> Fei
> 
> 
> *Lou Berger <lberger@labn.net>*
> 
> 2012-08-17 05:10
> 
> 	
> 收件人
> 	"Rakesh Gandhi (rgandhi)" <rgandhi@cisco.com>
> 抄送
> 	"ccamp@ietf.org" <ccamp@ietf.org>, "zhang.fei3@zte.com.cn"
> <zhang.fei3@zte.com.cn>
> 主题
> 	Re: [CCAMP] I-D Action:      
>  draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
> 
> 
> 	
> 
> 
> 
> 
> 
> Rakesh,
>                 Such major changes (in scope and functionality) to WG
> drafts are
> usually discussed with the WG prior to the authors/editors just
> publishing the changes.  But, this is a judgment call by the document
> editors in how, quoting rfc2418, they "ensur[e] that the contents of the
> document accurately reflect the decisions that have been made by the
> working group."
> 
> So let's jump into discussing the changes.
> 
> As I see it this draft introduces several major functional changes that
> have not been discussed by the WG.  Correct me if I get them wrong, but
> I believe they include:
> 1) Introduction of a second method for signaling Co-routed LSPs
> 2) Support for FRR bypass tunnels for piggybacked on the TP
> bidirectional LSP mechanisms.
> 
>   There are also other changes, but I'll defer discussing them
>   until the discussion on the above is concluded.
> 
> Is this correct?
> 
> Assuming yes, I have questions about both rational and specific
> mechanisms.  For now let's look at the former, so please:
> 
> A) Articulate the issues/limitations with using the RFC3473 defined
> mechanisms for (co-routed) bidirectional LSPs that you'd like to see
> addressed.
> 
> B.1) Articulate the FRR/GMPLS-related issue you'd like to address?
> 
> B.2) Articulate why this issue should be solved in a TP-specific and not
> GMPLS generic fashion?
> 
> Thanks,
> Lou
> 
> On 8/16/2012 4:26 PM, Rakesh Gandhi (rgandhi) wrote:
>> Hi Lou,
>>
>> Yes.
>>
>> Please advise if you think detailed email is required.
>> We believe latest draft summarizes the changes well and we could start
> review/discussions from there.
>>
>> Thanks,
>> Rakesh
>>
>>
>> -----Original Message-----
>> From: Lou Berger [mailto:lberger@labn.net]
>> Sent: Thursday, August 16, 2012 4:00 PM
>> To: Rakesh Gandhi (rgandhi)
>> Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn
>> Subject: Re: [CCAMP] I-D Action:
> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>
>> Rakesh,
>>                  Is this the start of the thread that I requested in
> http://www.ietf.org/mail-archive/web/ccamp/current/msg13729.html
>>
>> In particular, is it the response to:
>>> I'd like to ask that someone (Rakesh, Fei, etc.) review each of the
>>> proposed change and the rational for each change (in one or in
>>> separate e-mails). The WG discussion can then really begin on the
>>> proposed changes. (Which are quite substantial both in scope and
>>> implication.)
>>
>> Lou
>>
>> On 8/16/2012 3:19 PM, Rakesh Gandhi (rgandhi) wrote:
>>> Hi All,
>>>
>>> We have uploaded a new version of this draft with following changes:
>>  
>> 1.  Added a section on Signaling of Co-routed LSPs
>>
>> 2.  Added clarification on Signaling of Associated Bidirectional
> Protection LSPs
>>
>> 3.  Added a section on Signaling of Auto-tunnel Mesh-group LSPs
>>
>> 4.   Added clarification on Signaling of Inter-domain Associated
>  Bidirectional LSPs
>>
>> 5.  The Extended ASSOCIATION object format with Association Type
> "Associated Bidirectional LSP". Clarified on how to populate different
> fields in this object.
>>
>>  
>>> We believe that some of these changes were necessary to avoid the
> interoperability issues due to potentially different interpretations.
>>>
>>> Your review comments are welcome.
>>>
>>> Thanks,
>>> Rakesh
>>>
>>> -----Original Message-----
>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf
>>> Of internet-drafts@ietf.org
>>> Sent: Wednesday, August 15, 2012 10:53 AM
>>> To: i-d-announce@ietf.org
>>> Cc: ccamp@ietf.org
>>> Subject: [CCAMP] I-D Action:
>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>>>  This draft is a work item of the Common Control and Measurement
> Plane Working Group of the IETF.
>>>
>>>                  Title           : RSVP-TE Extensions for Associated
> Bidirectional LSPs
>>>                  Author(s)       : Fei Zhang
>>>                           Ruiquan Jing
>>>                           Rakesh Gandhi
>>>                  Filename        :
> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>                  Pages           : 17
>>>                  Date            : 2012-08-15
>>>
>>> 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 datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte-ext-a
>>> ssociated-lsp
>>>
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associa
>>> ted-lsp-04
>>>
>>> A diff from the previous version is available at:
>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-mpls-tp-rsvpte-ext-a
>>> ssociated-lsp-04
>>>
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> CCAMP mailing list
>>> CCAMP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>
>>>
>>>
>>>
>>
>>
>>
>>
> 
>