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

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: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org] On
>> Behalf Of Tony Li
>> Sent: Wednesday, April 21, 2010 11:39 PM
>> To: Les Ginsberg (ginsberg); lizhenqiang@chinamobile.com; Jie Dong;
>> bruno.decraene@orange-ftgroup.co; isis-wg@ietf.org;
>> weifang@chinamobile.com
>> 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
>> Isis-wg@ietf.org
>> https://www.ietf.org/mailman/listinfo/isis-wg
> _______________________________________________
> Isis-wg mailing list
> Isis-wg@ietf.org
> https://www.ietf.org/mailman/listinfo/isis-wg
> 