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

From: [email-masked]
Date: Wed, 05 Sep 2012 14:44:53 -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-05.txt
	Pages           : 17
	Date            : 2012-09-05

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 generalizes 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-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-assoc-ext-05

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Lou Berger <[email-masked]>
Date: Wed, 05 Sep 2012 17:49:40 -0400

All,
	This update addresses comments received during AD and IESG review.
There are quite a few editorial changes thanks to a very careful review
by Dimitri.  The technically substantive changes are the additions of
the following:

   3.3.2. Unknown Association Types

   A node that receives an ASSOCIATION object with an unknown
   ASSOCIATION type MUST forward all received ASSOCIATION objects as
   defined above.  The node MAY also identify associations per the
   defined processing, e.g., to make this information available via a
   management interface.

and

   5. Compatibility

   Per [RFC4872], the ASSOCIATION object uses an object class number of
   the form 11bbbbbb to ensure compatibility with non- supporting nodes.
   Per [RFC2205], such nodes will ignore the object but forward it
   without modification.  This is essentially also the action taken for
   unknown association types as discussed above in Section 3.3.2.
   Operators wishing to use a function supported by particular
   association type should ensure that the type is supported on any node
   which is expected to act on the association.

Lou (as co-author)

On 9/5/2012 5:44 PM, [email-masked] wrote:
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp
> 
> 
> 
>