Subject: [Isis-wg] I-D Action:draft-ietf-isis-purge-tlv-02.txt

From: [email-masked]
Date: Mon, 7 Jun 2010 17:00:02 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IS-IS for IP Internets Working Group of the IETF.

	Title           : Purge Originator Identification TLV for IS-IS
	Author(s)       : F. Wei, et al.
	Filename        : draft-ietf-isis-purge-tlv-02.txt
	Pages           : 6
	Date            : 2010-06-07

At present an IS-IS purge does not contain any information
identifying the Intermediate System (IS) that generates the purge.
This makes it difficult to locate the source IS.

To address this issue, this document defines a TLV to be added to
purges to record the system ID of the IS generating it.  Since normal
LSP flooding does not change LSP contents, this TLV should propagate
with the purge.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-isis-purge-tlv-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Jonathan Hardwick <[email-masked]>
Date: Tue, 8 Jun 2010 16:11:16 +0100

Hi there

A few comments and suggestions on this draft.

_Section 3_

Please could you define the "proxy mode" behavior explicitly?  It sounds like the intended behavior is "an IS that receives a purge without the Purge Origination Identifier TLV SHOULD add this TLV and include the system ID of the IS that it received the purge from."  You should also say that an IS doing this MUST recalculate the Authentication TLV on the purge as per section 5.

I think it's better to remove the explicit "number of system IDs" field in the new TLV.  It can be inferred from the length field.

Since the new TLV is intended for diagnostics, would a purge reason code be a useful extra parameter?

_Section 6_

What is the difference between sentence 2 and sentence 3?

Sentence 3 does not quite scan.  Suggested rewording: "Purges with the Purge Originator Identification TLV or the Dynamic Hostname TLV MUST be accepted and processed as a normal purge."

Best regards
Jon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 08 June 2010 01:00
To: [email-masked]
Cc: [email-masked]
Subject: [Isis-wg] I-D Action:draft-ietf-isis-purge-tlv-02.txt

At present an IS-IS purge does not contain any information identifying the Intermediate System (IS) that generates the purge.
This makes it difficult to locate the source IS.

To address this issue, this document defines a TLV to be added to purges to record the system ID of the IS generating it.  Since normal LSP flooding does not change LSP contents, this TLV should propagate with the purge.

Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.

---

From: Tony Li <[email-masked]>
Date: Tue, 08 Jun 2010 11:34:34 -0700

Hi Jonathan,

Thank you for your comments.

> _Section 3_
> 
> Please could you define the "proxy mode" behavior explicitly?  It sounds like
> the intended behavior is "an IS that receives a purge without the Purge
> Origination Identifier TLV SHOULD add this TLV and include the system ID of
> the IS that it received the purge from."

Hmmm.... Well, that's what the second half of that sentence was supposed to
be doing.  I'll reword this to clarify.

> You should also say that an IS doing
> this MUST recalculate the Authentication TLV on the purge as per section 5.

I'm not sure I see what the benefit here is.  The text in section 5 is still
normative and is not so distant from section 3 that developers will miss it.

> I think it's better to remove the explicit "number of system IDs" field in the
> new TLV.  It can be inferred from the length field.

It can be, but that overloads semantics.  Is this a big deal?

> Since the new TLV is intended for diagnostics, would a purge reason code be a

IMHO, not particularly.  Once you can isolate the system that generated the
purge, you can examine its logs.  If that doesn't suffice, you'll want to
examine its code.  ;-)

> What is the difference between sentence 2 and sentence 3?

Fixed.

> Sentence 3 does not quite scan.  Suggested rewording: "Purges with the Purge
> Originator Identification TLV or the Dynamic Hostname TLV MUST be accepted and
> processed as a normal purge."

As you noted, the sentence was redundant anyway.  Removed it entirely.

Thanks again,
Tony

---

From: Jonathan Hardwick <[email-masked]>
Date: Thu, 10 Jun 2010 00:56:56 +0100

Hi Tony,

Thanks for the quick reply - please see comments marked JEH> below.  Minor stuff only.

Regards
Jon 

-----Original Message-----
From: Tony Li [mailto:[email-masked]] 
Sent: 08 June 2010 19:35
To: Jonathan Hardwick; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Isis-wg] I-D Action:draft-ietf-isis-purge-tlv-02.txt

<snip>

> this MUST recalculate the Authentication TLV on the purge as per section 5.

I'm not sure I see what the benefit here is.  The text in section 5 is still normative and is not so distant from section 3 that developers will miss it.

JEH> I read the text in section 5 to be a description of how the purge is constructed from the original LSP by the IS generating the purge. Section 3 requires an IS to modify a purge and recalculate the Authentication TLV. This recalculation is somewhat irregular so I thought it deserved a special mention somewhere. I don't feel particularly strongly though, since you'd quickly catch this in testing if you forgot to do it.

> I think it's better to remove the explicit "number of system IDs" 
> field in the new TLV.  It can be inferred from the length field.

JEH> I take the point about overloading, but the flip side is that you introduce error cases where the TLV length and number of system IDs do not agree.  I'd rather not have that, but it's not a big deal.

> code be a useful extra parameter?

IMHO, not particularly.  Once you can isolate the system that generated the purge, you can examine its logs.  If that doesn't suffice, you'll want to examine its code.  ;-)

JEH> Fair enough, very true.

---

From: Tony Li <[email-masked]>
Date: Wed, 09 Jun 2010 17:38:12 -0700

Hi Jon,

> JEH> I read the text in section 5 to be a description of how the purge is
> constructed from the original LSP by the IS generating the purge. Section 3
> requires an IS to modify a purge and recalculate the Authentication TLV. This
> recalculation is somewhat irregular so I thought it deserved a special mention
> somewhere. I don't feel particularly strongly though, since you'd quickly
> catch this in testing if you forgot to do it.

Thanks, yes, there's a possibility for confusion here.  How about we extend
the text in section 5 to apply to purge modifications as well?

Tony

---

From: Jonathan Hardwick <[email-masked]>
Date: Thu, 10 Jun 2010 21:07:25 +0100

Hi Tony,

Yes, a change to section 5 sounds fine.  Perhaps change it to read "...the purge LSP is constructed or modified as follows.  First, the contents of the LSP are removed..."

Regards
Jon 

-----Original Message-----
From: Tony Li [mailto:[email-masked]] 
Sent: 10 June 2010 01:38
To: Jonathan Hardwick; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Isis-wg] I-D Action:draft-ietf-isis-purge-tlv-02.txt

Hi Jon,

> JEH> I read the text in section 5 to be a description of how the purge 
> JEH> is
> constructed from the original LSP by the IS generating the purge. 
> Section 3 requires an IS to modify a purge and recalculate the 
> Authentication TLV. This recalculation is somewhat irregular so I 
> thought it deserved a special mention somewhere. I don't feel 
> particularly strongly though, since you'd quickly catch this in testing if you forgot to do it.

Thanks, yes, there's a possibility for confusion here.  How about we extend the text in section 5 to apply to purge modifications as well?

Tony

---

From: Tony Li <[email-masked]>
Date: Thu, 10 Jun 2010 13:23:11 -0700

Exactly my thinking, down to word choice.  ;-)

Thanks much for the comments.  Anyone else?

Tony

On 6/10/10 1:07 PM, "Jonathan Hardwick" <[email-masked]>
wrote:

> Hi Tony,
> 
> Yes, a change to section 5 sounds fine.  Perhaps change it to read "...the
> purge LSP is constructed or modified as follows.  First, the contents of the
> LSP are removed..."
> 
> Regards
> Jon 
> 
> To: Jonathan Hardwick; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Cc: [email-masked]

---

From: Hannes Gredler <[email-masked]>
Date: Mon, 21 Jun 2010 17:53:00 +0200

hi tony,

i was just wondering about the reasoning why there is a hard clipping
of sysid's to two (originator and peer). are there any hard feelings
lifting that restriction such that one can see the accumulated
flooding path of the purge ?

/hannes

On Thu, Jun 10, 2010 at 01:23:11PM -0700, Tony Li wrote:
| 
| 
| Exactly my thinking, down to word choice.  ;-)
| 
| Thanks much for the comments.  Anyone else?
| 
| Tony
| 
| 
| 
| On 6/10/10 1:07 PM, "Jonathan Hardwick" <[email-masked]>
| wrote:
| 
| > Hi Tony,
| > 
| > Yes, a change to section 5 sounds fine.  Perhaps change it to read "...the
| > purge LSP is constructed or modified as follows.  First, the contents of the
| > LSP are removed..."
| > 
| > Regards
| > Jon 
| > 
| > -----Original Message-----
| > From: Tony Li [mailto:[email-masked]]
| > Sent: 10 June 2010 01:38
| > To: Jonathan Hardwick; [email-masked]; [email-masked];
| > [email-masked]; [email-masked]
| > Cc: [email-masked]
| > Subject: Re: [Isis-wg] I-D Action:draft-ietf-isis-purge-tlv-02.txt
| > 
| > 
| > Hi Jon,
| > 
| > 
| >> JEH> I read the text in section 5 to be a description of how the purge
| >> JEH> is
| >> constructed from the original LSP by the IS generating the purge.
| >> Section 3 requires an IS to modify a purge and recalculate the
| >> Authentication TLV. This recalculation is somewhat irregular so I
| >> thought it deserved a special mention somewhere. I don't feel
| >> particularly strongly though, since you'd quickly catch this in testing if
| >> you forgot to do it.
| > 
| > 
| > Thanks, yes, there's a possibility for confusion here.  How about we extend
| > the text in section 5 to apply to purge modifications as well?
| > 
| > 
| > Tony
| > 
| > 
| 
| 
| _______________________________________________
| Isis-wg mailing list
| [email-masked]
| https://www.ietf.org/mailman/listinfo/isis-wg

---

From: Tony Li <[email-masked]>
Date: Mon, 21 Jun 2010 08:59:00 -0700

Hi Hannes,

Seems like an order of magnitude increase in complexity.  What's the commensurate benefit?

Tony

---

From: Hannes Gredler <[email-masked]>
Date: Mon, 21 Jun 2010 18:31:18 +0200

short answer - there isn't;

i am just trying to assess whats the reasoning for "more than one"
sysid ? lets go by the spec:

---

   This document defines a TLV to be included in purges.  If an IS
   generates a purge, it SHOULD include this TLV in the purge with its
   own system ID.  If an IS receives a purge that does not include this
   TLV, then it SHOULD add this TLV with both its own system ID and the
   system ID of the IS that it received the purge from.

---

IOW - if the contents of the Purge Originator Identification TLV !=
  the system-id of the received LSP-ID then the purge has been received
  by a neighbor that does not support this extension. if the sysid is equal
  then this is the true originator of the purge. so IMO there is not need
  for more than one sysid to be carried in the TLV.

/hannes

On Mon, Jun 21, 2010 at 08:59:00AM -0700, Tony Li wrote:
| 
| Hi Hannes,
| 
| Seems like an order of magnitude increase in complexity.  What's the commensurate benefit?
| 
| Tony
| 
| 
| 
| On Jun 21, 2010, at 8:53 AM, Hannes Gredler wrote:
| 
| > hi tony,
| > 
| > i was just wondering about the reasoning why there is a hard clipping
| > of sysid's to two (originator and peer). are there any hard feelings
| > lifting that restriction such that one can see the accumulated
| > flooding path of the purge ?
| > 
| > /hannes
| > 
| > On Thu, Jun 10, 2010 at 01:23:11PM -0700, Tony Li wrote:
| > | 
| > | 
| > | Exactly my thinking, down to word choice.  ;-)
| > | 
| > | Thanks much for the comments.  Anyone else?
| > | 
| > | Tony
| > | 
| > | 
| > | 
| > | On 6/10/10 1:07 PM, "Jonathan Hardwick" <[email-masked]>
| > | wrote:
| > | 
| > | > Hi Tony,
| > | > 
| > | > Yes, a change to section 5 sounds fine.  Perhaps change it to read "...the
| > | > purge LSP is constructed or modified as follows.  First, the contents of the
| > | > LSP are removed..."
| > | > 
| > | > Regards
| > | > Jon 
| > | > 
| > | > -----Original Message-----
| > | > From: Tony Li [mailto:[email-masked]]
| > | > Sent: 10 June 2010 01:38
| > | > To: Jonathan Hardwick; [email-masked]; [email-masked];
| > | > [email-masked]; [email-masked]
| > | > Cc: [email-masked]
| > | > Subject: Re: [Isis-wg] I-D Action:draft-ietf-isis-purge-tlv-02.txt
| > | > 
| > | > 
| > | > Hi Jon,
| > | > 
| > | > 
| > | >> JEH> I read the text in section 5 to be a description of how the purge
| > | >> JEH> is
| > | >> constructed from the original LSP by the IS generating the purge.
| > | >> Section 3 requires an IS to modify a purge and recalculate the
| > | >> Authentication TLV. This recalculation is somewhat irregular so I
| > | >> thought it deserved a special mention somewhere. I don't feel
| > | >> particularly strongly though, since you'd quickly catch this in testing if
| > | >> you forgot to do it.
| > | > 
| > | > 
| > | > Thanks, yes, there's a possibility for confusion here.  How about we extend
| > | > the text in section 5 to apply to purge modifications as well?
| > | > 
| > | > 
| > | > Tony
| > | > 
| > | > 
| > | 
| > | 
| > | _______________________________________________
| > | Isis-wg mailing list
| > | [email-masked]
| > | https://www.ietf.org/mailman/listinfo/isis-wg
|

---

From: Tony Li <[email-masked]>
Date: Mon, 21 Jun 2010 10:19:22 -0700

Hannes,

In the case where the purge is not originated by an IS that supports this TLV, then two system ID's are added: one to record which system added the TLV, and the second to say where it came from.  Both of these seem valuable.  The point is to backtrack the purge to its source so that we can analyze why it was generated.

Tony

---

From: Hannes Gredler <[email-masked]>
Date: Mon, 21 Jun 2010 19:45:12 +0200

tony,

isn't it that all "leaf-style" TLVs extract the
anchoring system-ID from the LSP-ID which they
ride on (kind alike IP reach).

IOW: can't the system who has added the TLV, be computed by extracting
it from the LSP-ID of the underlying fragment ?

e.g. consider a LSP 1921.6800.1001.00-00 containing
           {TLV 13: 1921.6801.0002}

here 1921.6801.0002 is the neighbor that does not support the purge
extensions and 1921.6800.1001 is the system that has added it.

so the first system-ID isn't really necessary.

/hannes

---

From: Tony Li <[email-masked]>
Date: Mon, 21 Jun 2010 11:06:51 -0700

Hi Hannes,

> ride on (kind alike IP reach).

In the case of purges, the LSP-ID may have nothing to do with the system that generated the purge, or the previous hop in the path of the purge.

> so the first system-ID isn't really necessary.

I'm somewhat confused by your example.  A system that forwards a purge cannot change the LSP-ID of the fragment.  That would result in it purging its own fragments.

Tony

---

From: Hannes Gredler <[email-masked]>
Date: Mon, 21 Jun 2010 21:00:57 +0200

On Mon, Jun 21, 2010 at 11:06:51AM -0700, Tony Li wrote:
| > isn't it that all "leaf-style" TLVs extract the
| > anchoring system-ID from the LSP-ID which they
| > ride on (kind alike IP reach).
| 
| 
| In the case of purges, the LSP-ID may have nothing to do with the system that generated the purge, or the previous hop in the path of the purge.

ohh, ohh - i was confused - i haven't considered the case where both the purging
and purged node do not support the extension(s) *and* therefore rely on a 3rd party "helper".
which has no sysid in "common" with the underlying purge.

thanks, for clarifying.

/hannes