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

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