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

["Les Ginsberg (ginsberg)" <[e-mail]>]

As an editorial nit, I suspect the reference to "TC1" in the
introduction is a bit cryptic for the uninitiated. Perhaps adding the
following to the references:

ISO/IEC 10589:1992/ Cor.1:1993
Information technology -- Telecommunications and information exchange
between systems -- Intermediate system to Intermediate system
intra-domain routeing information exchange protocol for use in
conjunction with the protocol for providing the connectionless-mode
Network Service (ISO 8473) -- Technical Corrigendum 1

would help?

(Then again...maybe not. :-) )

   Les


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Les Ginsberg (ginsberg)
> Sent: Friday, April 23, 2010 5:15 PM
> To: Tony Li; Dave Katz
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: 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:[e-mail]]
> > Sent: Friday, April 23, 2010 4:50 PM
> > To: Dave Katz; Les Ginsberg (ginsberg)
> > Cc: [e-mail]; Jie Dong; bruno.decraene@orange-
> > ftgroup.co; [e-mail]; [e-mail]
> > 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" <[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
> > >>
> > >
> 
> _______________________________________________
> Isis-wg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/isis-wg