Re: [Gen-art] Gen-ART review of draft-ietf-mpls-gach-adv-06

[Stewart Bryant <[e-mail]>]

On 27/03/2013 21:41, Martin Thomson wrote:
> Hi Stewart,
>
> Looks like you have most of this in hand.  A few comments.
>
> On 27 March 2013 13:11, Stewart Bryant <[e-mail]> wrote:
>>>> In Section 4.4, how does the duration interact with the lifetime?
>>>> What happens when the duration is longer than lifetime such that the
>>>> TLV is expunged before the duration is up?
>> Well that would normally be a silly thing to do, but we do not propose to
>> stop
>> it lest it be something an application actually wants.
>>
>> This would be functionally equivalent to issuing a short term note
>> that was only transiently valid, or issuing some sort of synchronization
>> message. I can't think why you would want to do it, but why would we
>> stop it?
> There was an implicit question here.  Namely:  Do you want to codify
> anything regarding expectations on this?  Can I rely on an
> attribute/action with a long duration after the retention interval has
> expired?
That is surely an application issue.

The TX advertizes a parameter, and says how long it assumes it to be valid.
What the application does with it is up to the application.

>
>>>> Section 5.2 states:
>>>>      [...] If one
>>>>      of the received TLV objects has the same Type as a previously
>>>>      received TLV then the data from the new object SHALL replace the data
>>>>      associated with that Type unless the X specification dictates a
>>>>      different behavior.
>>>>
>>>> This leads to different retention characteristics depending on some
>>>> arbitrary application-specific requirements.  It also complicates
>>>> implementations.  Is there a strong motivation for the "unless the X
>>>> specification dictates a different behavior" part of this statement?
>> Yes, on the one hand we do not wish to constrain the applications, and
>> on the other we trust the application developers and the IETF review
>> process (required for a code point) to stop silly behaviour.
> I don't find that answer particularly satisfactory.  If I were to
> build a generic implementation of this, I wouldn't want to allow for
> this feature because it's a fairly large complication.  That's what
> I'm trying to get to: what motivation can you provide to an
> implementer to support this feature?  And in case I'm not being clear,
> what would you want to put in the draft?
> .
>
A case where data might not be replaced would be a case where it was logged.
For example I might report the temperature of my optical interface and
want a small history, or I might want a small history of alarm events.
Alternatively if the event rate was too fast for the RX process some
types might be fifoed.

Our point was to specify the normal behaviour, but permit an application
to request a variation.  Given that this is an advertisment protocol,
the normative behaviour is the TX side and the RX side is largely 
illustrative,
because what the RX does with any of this is optional, so I do not think 
there
is an issue here.

- Stewart