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

From: [email-masked]
Date: Tue, 14 Aug 2012 06:45:19 -0700

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/

---

From: Lou Berger <[email-masked]>
Date: Tue, 14 Aug 2012 10:10:16 -0400

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, [email-masked] wrote:
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp
> 
> 
> 
>

---

From: [email-masked]
Date: Wed, 15 Aug 2012 11:10:33 +0800

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?

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.

Best regards

Fei

Lou Berger <[email-masked]> 
发件人:  [email-masked]
2012-08-14 22:10

收件人
[email-masked]
抄送

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

Lou (and co-authors)

---

From: Lou Berger <[email-masked]>
Date: Wed, 15 Aug 2012 12:22:47 -0400

Fei,
	See below.

> or the usage in a single session can be defined as an association type

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

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

Lou

> 
> 
> Best regards
> 
> Fei
> 
> 
> *Lou Berger <[email-masked]>*

---

From: [email-masked]
Date: Thu, 16 Aug 2012 14:06:45 +0800

Lou

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

Regards

Fei

2012-08-16 00:22

收件人
[email-masked]
抄送
[email-masked]
主题

Fei,
                 See below.

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

<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

---

From: Lou Berger <[email-masked]>
Date: Thu, 16 Aug 2012 10:57:14 -0400

Fei,
	I still don't understand the point you're trying to address (in your
proposed language).  Given that you said that you can live with the
published text, shall we just not worry about this?  If not, can you
rephrase the issue in the current text that you'd like to address?

Thanks,
Lou

On 8/16/2012 2:06 AM, [email-masked] wrote:
> <fei> I want to check whether the ASSOCIATION object is allowed to be
> used in a signal session,
> the Association Source SHALL be used"? Of course, the current
> description is

---

From: [email-masked]
Date: Fri, 17 Aug 2012 08:57:49 +0800

Lou

After a second thinking, I agree that the published text has no problem.

Thanks

Fei

2012-08-16 22:57

收件人
[email-masked]
抄送
[email-masked]
主题

Fei,
                 I still don't understand the point you're trying to 
address (in your
proposed language).  Given that you said that you can live with the
published text, shall we just not worry about this?  If not, can you
rephrase the issue in the current text that you'd like to address?

Thanks,
Lou