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

I don't much care either way, so long as the semantics are well-defined.

--Dave

On Apr 23, 2010, at 4:54 PM, Les Ginsberg (ginsberg) wrote:

> 
> 
>> -----Original Message-----
>> From: Dave Katz [mailto:dkatz@juniper.net]
>> Sent: Friday, April 23, 2010 10:58 AM
>> To: Les Ginsberg (ginsberg)
>> Cc: Tony Li; 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)
>> 
>> 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.)
> 
> That is the intent.
> That's why the legal values for the length can only be: (1*systemid
> length) or (2*systemid length)
> 
> If you have one, then you are the originator of the purge.
> If you have two, you are proxying for whomever first sent you the purge
> 
> We have "lots of room" so adding a flag could certainly be accommodated,
> but it does not seem to add any value.
> 
>   Les
> 
>> 
>> --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
>>> 
> 
> 
> 