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

[Tony Li <[e-mail]>]

Still stuck:

https://datatracker.ietf.org/idst/status.cgi?passed_filename=draft-ietf-isis
-purge-tlv-00

Our Beloved Chair is responsible for informing the secretariat that this was
accepted by the group.

Tony



On 5/13/10 6:49 PM, "李振强" <[e-mail]> wrote:

> Yes, we accepted this as a WG draft. I submitted the 00 version 50 days ago.
> Due to the initial version checking, I did not get any further information
> till now.
> Anybody know who is responsible for the initial version checking? Where should
> I go to check the and move the status forward? Thanks.
> 
> Best Regards,
> 
> 
> 
> 
> Zhenqiang Li
> 13911635816
> Department of Network Technology
> China Mobile Research Institute
> 2010-05-14
> 
> 
> 
> 发件人： Les Ginsberg (ginsberg)
> 发送时间： 2010-05-14 09:23:45
> 收件人： Tony Li; Dave Katz
> 抄送： [e-mail]; Jie Dong; [e-mail];
> [e-mail]; [e-mail]
> 主题： RE: [Isis-wg] draft-wei-isis-tlv-03 (Purge Originator Id)
> 
> Folks -
> 
> Any reason why 
> 
> draft-ietf-isis-purge-tlv-01
> 
> (or at least the 00 version allegedly submitted some time back) is not
> posted? We did accept this as a WG doc did we not??
> 
>    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
>>>> 
>>>