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 Mike Shand (mshand)
> Sent: Thursday, April 22, 2010 3:00 AM
> To: isis-wg@ietf.org
> Subject: Re: [Isis-wg] draft-wei-isis-tlv-03 (Purge Originator Id)
> 
> 
> 
> On 22/04/2010 07:41, Les Ginsberg (ginsberg) wrote:
> > 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.
> >
> Yes. I think that is what would be expected from the existing spec,
but
> it does no harm to clarify it. I wonder if any existing
implementations
> would take it upon themselves to remove the body from a purge? I hope
> not.
> > If the same purged LSP is received from two different originators,
> the
> > choice of which "copy" to flood is a local matter.
> >
> 
> Hmmm. Would it not be the case that the first one received was always
> the one flooded, since any later ones received would be regarded as
> duplicates?

This is both reasonable and what one would expect if we remain strict to
the "this does not change the update process in any way" statement. So
perhaps this is unnecessary. I was concerned about some overzealous
implementation thinking it was desirable to let the network know about
every purge source.

   Les

> >     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
> >
> >
> 
> --
> For corporate legal information go to:
> www.cisco.com/web/about/doing_business/legal/cri
> 
> _______________________________________________
> Isis-wg mailing list
> Isis-wg@ietf.org
> https://www.ietf.org/mailman/listinfo/isis-wg