Re: [CCAMP] I-D Action: draft-ietf-ccamp-assoc-ext-04.txt

Lou

Thank you for your clarification, see response in line with <fei>

Regards

Fei

Lou Berger <lberger@labn.net> 
2012-08-16 00:22

收件人
zhang.fei3@zte.com.cn
抄送
ccamp@ietf.org
主题
Re: [CCAMP] I-D Action: draft-ietf-ccamp-assoc-ext-04.txt

Fei,
                 See below.

On 8/14/2012 11:10 PM, zhang.fei3@zte.com.cn wrote:
> 
> Hi Lou
> 
> I can see there are some minor changes when taking a look at the updated
> new version, and want to check with you the intention of listed two
> revisions.
> 
> 1. Section 3 No-GMPLS Recovery Usage
> 
> The sentence "Note that there are times when no matching state is found,
> e.g., when processing an initial LSP or when the ASSOCIATION object
> contains
> otherwise useful information, and such cases do not alter the processing
> defined below." is deleted in the version 04, which indicates that the
> ASSOCIATION object
> can not be used in a single session whith any kinds of Association Types
> or the usage in a single session can be defined as an association type
> specific rules?

Not sure exactly what you're asking, but this change was editorial in
nature only, as processing behavior continues to be specified (see the
2nd to last paragraph in Section 3.1.2 and 3.2.2.)

<fei> I want to check whether the ASSOCIATION object is allowed to be used 
in a signal session,
and find the corresponding description in section 3.1 and 3.2 
"The use of an ASSOCIATION object in a single session is not precluded"
" Note, the use of an ASSOCIATION object in a single session is not 
precluded"
No problem now, thanks.

> 
> 2. The descriptions about Global Association Source in Section 4.1.
>  IPv4 and IPv6 Extended ASSOCIATION Object Format
> 
> Similarly, the sentence "It is expected that the global identifier will
> be derived from the globally unique ASN of the autonomous system hosting
> the Association Source." does not appear in the new version. The
> question here is whether the Global Association Source SHOULD host the
> Association Source or not?  If yeah, it had better being described in
> the document.

So the old text was informative only (and was taken from RFC6370).  The
new text is normative and says use definition from [RFC6370]. So I'm not
sure what is ambiguous in the new text.  What specific change would you
like to see?

<fei> IMHO, the Global Associaiton Source should be the Global_ID that 
hosting
Association Source, how about "the Global_ID as defined in [RFC6370]that 
hosting
the Association Source SHALL be used"? Of course, the current description 
is 
correct and includes this possibility.

Lou

> 
> 
> Best regards
> 
> Fei
> 
> 
> *Lou Berger <lberger@labn.net>*
> 发件人:  ccamp-bounces@ietf.org
> 
> 2012-08-14 22:10
> 
> 
> 收件人
>                ccamp@ietf.org
> 抄送
> 
> 主题
>                Re: [CCAMP] I-D Action: draft-ietf-ccamp-assoc-ext-04.txt
> 
> 
> 
> 
> 
> 
> 
> 
> 
> The authors believe that this revision addresses the comments raised by
> Adrian and discussed on the list. (It also includes few other editorial
> nits identified by the authors.)
> 
> Please note, as discussed, there has been one substantive technical
> change (MUST --> SHOULD):
> 
>  3.2.1. Resv Message Format
> OLD
>  Relative ordering of ASSOCIATION objects of the same type
>  MUST be preserved by transit nodes.
> NEW
>  Relative ordering of ASSOCIATION objects of the same type
>  *SHOULD* be preserved by transit nodes.
> 
> Lou (and co-authors)
> 
> On 8/14/2012 9:45 AM, internet-drafts@ietf.org wrote:
>>
>> 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 Association Object Extensions
>>                  Author(s)       : Lou Berger
>>                           Francois Le Faucheur
>>                           Ashok Narayanan
>>                  Filename        : draft-ietf-ccamp-assoc-ext-04.txt
>>                  Pages           : 16
>>                  Date            : 2012-08-14
>>
>> Abstract:
>>    The RSVP ASSOCIATION object was defined in the context of GMPLS
>>    (Generalized Multi-Protocol Label Switching) controlled label
>>    switched paths (LSPs).  In this context, the object is used to
>>    associate recovery LSPs with the LSP they are protecting.  This
>>    object also has broader applicability as a mechanism to associate
>>    RSVP state, and this document defines how the ASSOCIATION object
>>    can be more generally applied.  This document also defines
>>    Extended ASSOCIATION objects which, in particular, can be used in
>>    the context of the Transport Profile of Multiprotocol Label
>>    Switching (MPLS-TP).  This document updates RFC 2205, RFC 3209,
>>    and RFC 3473. It also modifies the definition of the Association
>>    ID field defined in RFC 4872.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-assoc-ext
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-ccamp-assoc-ext-04
>>
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-assoc-ext-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
>>
>>
>>
>>
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp
> 
> 