Re: [Isis-wg] draft-wei-isis-tlv-03 (Purge Originator Id)

[Tony Li <[e-mail]>]

So I have aversion (perhaps irrational ;-) to overloading semantics into the
length field.  So I've actually added the flag.

I've also addressed a number of comments, both on list and privately, so
this is worth a full read.

Comments?

Tony



On 4/23/10 10:57 AM, "Dave Katz" <[e-mail]> wrote:

> This seems to make sense so long as the absence of the neighbor field
> unambiguously says that the inserting system is also the originator of the
> purge (otherwise you need a flag.)
> 
> --Dave
> 
> On Apr 22, 2010, at 2:39 PM, Les Ginsberg (ginsberg) wrote:
> 
>> One other suggestion.
>> 
>> The usefulness of the extensions defined in this draft depend upon the
>> extent to which they are deployed - which no doubt will take
>> considerable time under the best of circumstances. It seems that we
>> could enhance the usefulness of the extensions even in the case of
>> partial deployment by allowing an IS which supports these extensions to
>> add the new TLV to purges it receives that do not include the new TLV.
>> It could include both its own system ID (to identify who added the TLV)
>> and the system ID of the neighbor from whom the empty purge was
>> received. While this is not guaranteed to pinpoint the source of the
>> purge, it would at least provide a pointer to the portion of the network
>> in which the purge originated.
>> 
>> So the TLV would then look like:
>> 
>> TLV - code to be assigned by IANA
>> Length - Either (1 * systemid length) or (2 *system ID length)
>> Value -
>> System ID of the system inserting the TLV (Required)
>> System ID of the system from which the purge was received (Optional)
>> 
>> ???
>> 
>>   Les
>> 
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]] On
>>> Behalf Of Tony Li
>>> Sent: Wednesday, April 21, 2010 11:39 PM
>>> To: Les Ginsberg (ginsberg); [e-mail]; Jie Dong;
>>> [e-mail]; [e-mail];
>>> [e-mail]
>>> Subject: Re: [Isis-wg] draft-wei-isis-tlv-03 (Purge Originator Id)
>>> 
>>> 
>>> Hi Les,
>>> 
>>>> But hopefully we can comment on 01 anyway?? :-)
>>> 
>>> Of course!  ;-)
>>> 
>>>> I don't see the need for Section 3. It was interesting discussion
>>>> material while we were debating the merits of making this a WG
>>> document,
>>>> but I think it has drawbacks when it is included in what is intended
>>> to
>>>> become a standards document.
>>> 
>>> Well, the point was to help document some of the field failures that
>>> we've
>>> seen and motivate the changes.
>>> 
>>>> In the second set of three points, only the first (which documents
>>> the
>>>> lamentable purge on checksum error experience) has value. The last
>>> two
>>>> are anecdotal and could be translated as "there are some weird bugs
>>> out
>>>> there". Interesting - but unnecessary. The first point could be
>>>> mentioned in the introduction as part of the justification for the
>>>> protocol extensions - but I think even that is unnecessary.
>>> 
>>> True, but without the background, these changes would seem like
>>> something
>>> straight out of the Oort cloud.
>>> 
>>> Compromise: condense the text and move to the introduction?
>>> 
>>> 
>>>> In Section 5 I would like to see language which says "hostname TLV
>>>> SHOULD only be used in addition to the system ID TLV". As every IS
>>> MUST
>>>> have a unique systemID but hostnames are optional I would prefer
>> that
>>> if
>>>> an implementation chooses to include the extra info in the purge
>> that
>>>> the system ID ALWAYS be there. (This is unenforceable of course)
>>> 
>>> 
>>> Works for me.  Other folks?
>>> 
>>> 
>>>> I think there needs to be language which makes clear that the
>> absence
>>> or
>>>> presence of this additional information has no impact on the
>>> acceptance
>>>> of a purged LSP as valid i.e. no changes to the operation of the
>>> Update
>>>> process are introduced by this draft.
>>> 
>>> 
>>> Can't hurt.  I'm certain that this will break some conformance testers
>>> regardless.
>>> 
>>> Any other comments?
>>> 
>>> Tony
>>> 
>>> 
>>> _______________________________________________
>>> Isis-wg mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/isis-wg
>> _______________________________________________
>> Isis-wg mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/isis-wg
>> 
>