Re: [CCAMP] poll on makingdraft-zhang-mpls-tp-rsvpte-ext-associated-lsp-04 a WG document

Hi Fatai

There are some misunderstanding about the consensus on splitting the 
document [draft-ietf-ccamp-assoc-info-01.txt] to be two parts:
(1)Usage of The RSVP Association Object
(2)RSVP Association Object Extensions

one is "informational usage for GMPLS recovery", another one is for 
"Standards track extensions for non-GMPLS recovery usage and Extended 
association"

So for the second parts, it is about the information model，currently two 
documents related to it.

one is draft-ietf-ccamp-rsvp-resource-sharing-01

the other is draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-04

Furthermore, the recovery defined in RFC4872 and RFC4873 need to be 
reconsidered in MPLS-TP; of course the association type is no need to be 
redefined, but the extended association object should be used.

Do you want to one doucment to merge all of these content, even for the 
future extensions?

Just my two cents, that is a useless suggestion. 

Anyway, we need to hear the opinions from the WG.

Thanks 

Fei

Fatai Zhang <zhangfatai@huawei.com> 
发件人:  ccamp-bounces@ietf.org
2011-04-13 10:02

收件人
Lou Berger <lberger@labn.net>, ccamp@ietf.org
抄送

主题
Re: [CCAMP] poll on makingdraft-zhang-mpls-tp-rsvpte-ext-associated-lsp-04 
a WG document

Hi all,

This draft just introduces a new Association Type, so do we really need 
one more separate draft for this simple thing?

In Prague meeting, we know that there was a consensus on 
[draft-ietf-ccamp-assoc-info-01.txt] to separate it into two drafts: 
(1)Usage of The RSVP Association Object
(2)RSVP Association Object Extensions

So, I think it is appropriate to address MPLS-TP bidirectional LSP 
association in the draft (2), because we know that one of the key drivers 
for Association Object Extensions in [draft-ietf-ccamp-assoc-info-01] is 
for MPLS-TP.

In this way, we can just keep two drafts for the association stuff 
(besides RFC4872 and RFC4873), one is "informational usage for GMPLS 
recovery", another one is for "Standards track extensions for non-GMPLS 
recovery usage and Extended association". Another benefit  of this 
approach is very easy for the readers to track and review the RFCs.

Thanks

Fatai

Huawei Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen 518129 P.R.China
Tel: +86-755-28972912
Fax: +86-755-28972935
----- Original Message ----- 
From: "Lou Berger" <lberger@labn.net>
To: <ccamp@ietf.org>
Sent: Friday, April 01, 2011 5:24 PM
Subject: [CCAMP] poll on 
makingdraft-zhang-mpls-tp-rsvpte-ext-associated-lsp-04 a WG document

> All,
> 
> This is to start a two week poll on making
> draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-04 a ccamp working
> group document. Please send mail to the list indicating "yes/support"
> or "no/do not support".  If indicating no, please state your technical
> reservations with the document.
> 
> The poll ends Friday April 15.
> 
> Much thanks,
> Lou (and Deborah)
> 
> _______________________________________________
> 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