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

Tony -

This version looks good to me.

I will argue - though not very strenuously - for the removal of the
"Number of system IDs carried in this TLV" field. It raises the
unnecessary question of what the receiver should do if the length is
valid but does not == (number of system IDs * system ID length). But as
the TLV is only informational (i.e. a malformed purge originator TLV
should not cause the purged LSP to be ignored/discarded) this is not a
major issue.

Thanx for the quick turnaround.

   Les

> -----Original Message-----
> From: Tony Li [mailto:tony.li@tony.li]
> Sent: Friday, April 23, 2010 4:50 PM
> To: Dave Katz; Les Ginsberg (ginsberg)
> Cc: 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)
> 
> 
> 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" <dkatz@juniper.net> 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: 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
> >>
> >