Re: [Teas] comment on draft-ietf-mpls-residence-time

[Gregory Mirsky <[e-mail]>]

Hi Lou,
I've followed on your suggestion to investigate use of already available objects. I’ve looked into LSP_ATTRIBUTES Object [RFC5420]. Per my analysis we can consider two options:
•         introduce RSO sub-objects with RTM_Capability sub-TLVs ordered as defined in the current RTM draft, to be used in LSP_ATTRIBUTES Object;
•         use RRO Attributes sub-object that will be present in RRO Object and define new RTM Capability Flag(s) from IANA Attribute Flags registry. Rules defined in Section 7.3 RFC 5420 would apply.
Number of Attribute flags is variable, thus the latter option is as flexible as the former or current option documented in our draft.
 
Greatly appreciate your consideration, comments, suggestions.

	Regards,
		Greg


-----Original Message-----
From: Lou Berger [mailto:[e-mail]] 
Sent: Sunday, January 31, 2016 10:38 PM
To: [e-mail]; [e-mail]
Subject: comment on draft-ietf-mpls-residence-time

Hi,
	I see you propose defining a new RSVP object class that has application specific scope.  As I'm sure you know the RSVP class-number space is really small so it's best to avoid allocating new object classes whenever possible.  I believe there is an existing object class that you can use for your purposes -- the LSP_ATTRIBUTES object.

Have you considered carrying RTM Hops in 1 (or three,  depending on if you want sub-tlvs or not) new RTM Attribute TLV (or TLVs)?

If not, I think it is worth exploring the viability of this approach or any other approach that doesn't require the allocation of a new class-num.

Lou
(As contributor and TEAS co-chair)