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

From: [email-masked]
Date: Thu, 22 Apr 2010 18:14:18 +0800

Comment inline, begins with Zhenqiang.

Zhenqiang Li

发件人： Les Ginsberg (ginsberg)
发送时间： 2010-04-22 14:41:46
收件人： Les Ginsberg (ginsberg); Tony Li; [email-masked]; Jie Dong; [email-masked]; [email-masked]; [email-masked]
抄送： 
主题： RE: [Isis-wg] draft-wei-isis-tlv-03 (Purge Originator Id)

A couple of other comments that come to mind:

We need to define what an implementation SHOULD do when it receives a
purged LSP with the additional TLVs i.e. store it (including the body)
and flood it unchanged.

Zhenqiang: This is the normal processing, isn't it?

If the same purged LSP is received from two different originators, the
choice of which "copy" to flood is a local matter.

   Les

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Les Ginsberg (ginsberg)
> Sent: Wednesday, April 21, 2010 11:25 PM
> To: Tony Li; [email-masked]; Jie Dong;
> [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [Isis-wg] draft-wei-isis-tlv-03 (Purge Originator Id)
> 
> 
> 
>  > -----Original Message-----
>  > From: [email-masked] [mailto:[email-masked]] On
>  > Behalf Of Tony Li
>  > Sent: Wednesday, April 21, 2010 10:55 PM
>  > To: [email-masked]; Jie Dong; bruno.decraene@orange-
>  > ftgroup.co; [email-masked]; [email-masked]
>  > Subject: Re: [Isis-wg] draft-wei-isis-tlv-03 (Purge Originator Id)
>  >
>  >
>  >
>  >
>  >  > I renamed the draft as draft-ietf-isis-purge-tlv-00.txt and
> submitted
>  >  > it to IETF. Its status is Initial Version Approval Requested.
>  >
>  >
>  > As long as that's stuck in the queue, there's not much point in
>  > submitting a
>  > -01 verison.  So here's the document as an attachment.
> 
> But hopefully we can comment on 01 anyway?? :-)
> 
> ****************
> 
> 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.
> 
> The first three points suggest (no doubt unintentionally) that this
> document may in some way be redefining/clarifying the base spec in
> regards to when it is permissible to purge. I don't think we want to
> even remotely suggest that. If you want to know when it is OK to
purge,
> look at the base spec.
> 
> 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.
> 
> ********************
> 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)
> 
> *******************
> 
> 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.
> 
> Thanx.
> 
>    Les
> 
> 
>  >
>  > Tony
> 
> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 22 Apr 2010 07:19:21 -0700

> Behalf Of [email-masked]
> Sent: Thursday, April 22, 2010 3:14 AM
> To: Les Ginsberg (ginsberg); Tony Li; Jie Dong; bruno.decraene@orange-
> 收件人： Les Ginsberg (ginsberg); Tony Li; [email-masked];
> Jie Dong; [email-masked]; [email-masked];
> [email-masked]
> 抄送：

ISO 10589 7.3.16.4 states

<snip>
When the Remaining Lifetime on an LSP in memory becomes zero, the IS shall

a)	set all SRMflags for that LSP, and

b)	retain only the LSP header.
<end snip>

This section is referred to for cases other than lifetime expiration which result in purges - so it would not be surprising to find that implementations today routinely discard the body of a purged LSP if present. As the usefulness of this extension depends in part on retaining the additional TLV information - not only for propogation but presumably also for later inspection - I thought it would be worthwhile to make this behavior clear.

   Les