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

> -----Original Message-----
> From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org] On
> Behalf Of lizhenqiang@chinamobile.com
> Sent: Thursday, April 22, 2010 3:14 AM
> To: Les Ginsberg (ginsberg); Tony Li; 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)
> 
> 
> Comment inline, begins with Zhenqiang.
> 
> Zhenqiang Li
> 
> 
> 发件人： Les Ginsberg (ginsberg)
> 发送时间： 2010-04-22 14:41:46
> 收件人： Les Ginsberg (ginsberg); Tony Li; lizhenqiang@chinamobile.com;
> Jie Dong; bruno.decraene@orange-ftgroup.co; isis-wg@ietf.org;
> weifang@chinamobile.com
> 抄送：
> 主题： 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?

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

> 
> 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: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org] On
> > Behalf Of Les Ginsberg (ginsberg)
> > Sent: Wednesday, April 21, 2010 11:25 PM
> > To: 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)
> >
> >
> >
> >  > -----Original Message-----
> >  > From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org]
> On
> >  > Behalf Of Tony Li
> >  > Sent: Wednesday, April 21, 2010 10:55 PM
> >  > To: 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)
> >  >
> >  >
> >  >
> >  >
> >  >  > 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
> > 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