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

zhang.fei3@zte.com.cn Sun, 26 August 2012 03:44 UTC

Return-Path: <zhang.fei3@zte.com.cn>
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 5120121F8513; Sat, 25 Aug 2012 20:44:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.001
X-Spam-Level:
X-Spam-Status: No, score=-96.001 tagged_above=-999 required=5 tests=[AWL=-1.043, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_BAD_ID=2.837, 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 JfBCTYrJbl7n; Sat, 25 Aug 2012 20:44:00 -0700 (PDT)
Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 139A421F8512; Sat, 25 Aug 2012 20:43:58 -0700 (PDT)
Received: from [10.30.3.21] by mx5.zte.com.cn with surfront esmtp id 232553673712530(version=TLSv1/SSLv3 cipher=SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA bits=128 verify=NO); Sun, 26 Aug 2012 11:37:40 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q7Q3hoRd032055; Sun, 26 Aug 2012 11:43:50 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn)
In-Reply-To: <5037C010.7010605@labn.net>
To: Lou Berger <lberger@labn.net>
MIME-Version: 1.0
X-KeepSent: 784D37F1:E1BDC4D4-48257A66:00127BF4; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: <OF784D37F1.E1BDC4D4-ON48257A66.00127BF4-48257A66.0014687B@zte.com.cn>
From: zhang.fei3@zte.com.cn
Date: Sun, 26 Aug 2012 11:43:41 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-08-26 11:43:40, Serialize complete at 2012-08-26 11:43:40
Content-Type: multipart/alternative; boundary="=_alternative 0014687948257A66_="
X-MAIL: mse02.zte.com.cn q7Q3hoRd032055
Cc: "ccamp@ietf.org" <ccamp@ietf.org>, ccamp-bounces@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: Sun, 26 Aug 2012 03:44:01 -0000

Hi Lou, 

Thanks for your detailed review, snipped the others, see inline with <fei>

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.

<Fei> Sure, this part is also informational and there is no new mechanism 
introduced here. :)

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...

<Fei> For the singled sided provisioning model, the initial LSP source 
address (Association Source)and global_ID are pushed into the EA objects, 
so the ingress can learn the global ID of the peer node by the defined 
Association Type "LSP Identifiers" which is carried in the Path message 
and back in the Resv messages.

For the doubled sided provisioning model, since the lower IP address 
(Association Source) wins the tie breaker, the Association object with 
Association Type "LSP Identifiers" can be pushed into the Path message by 
the lower IP address initial LSP can carry back the global_ID of the 
higher IP address in the Resv message.

In other words, the Association object with Association Tyep "LSP 
Identifiers" are always pushed by the Association Source into the Path 
message can carried back in the Resv message with the peer node's 
global_ID in both provisioning model if necessary.

Do you think the currently description needs more clarification words?

Thanks

Fei



Lou Berger <lberger@labn.net> 
发件人:  ccamp-bounces@ietf.org
2012-08-25 01:55

收件人
"Rakesh Gandhi (rgandhi)" <rgandhi@cisco.com>
抄送
"ccamp@ietf.org" <ccamp@ietf.org>
主题
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?

> 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?

> 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?


> 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...

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
> 
> 
> 
> 
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp