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

[Tony Li <[e-mail]>]

Sure, why not?

Tony



On 4/23/10 5:41 PM, "Les Ginsberg (ginsberg)" <[e-mail]> wrote:

> 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