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

From: [email-masked]
Date: Thu, 22 Apr 2010 10:59:44 +0800

Hi, Tony and all,

I renamed the draft as draft-ietf-isis-purge-tlv-00.txt and submitted it to IETF. Its status is Initial Version Approval Requested.
The current XML source is in the attachment. Thanks for Tony and Bruno.

--------------------------------------------------------------------------------

Zhenqiang Li
13911635816
Department of Network Technology
China Mobile Research Institute
2010-04-22

--------------------------------------------------------------------------------

发件人： Tony Li
发送时间： 2010-04-22 05:19:58
收件人： Jie Dong; [email-masked]; [email-masked]; [email-masked]; [email-masked]
抄送： 
主题： Re: [Isis-wg] draft-wei-isis-tlv-03 (Purge Originator Id)

It sounds like there is general agreement that this would be useful.

I'll volunteer to make the document changes if someone would be so kind as
to send me the current XML source.

Thanks,
Tony

On 4/20/10 6:44 PM, "Jie Dong"  <[email-masked] > wrote:

> 
> Hi Bruno, all
> 
> I have no objections if there are some benefits of adding the hostname.
> 
> 
> Best regards,
> Jie
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]
> > Sent: Tuesday, April 20, 2010 6:18 PM
> > To: [email-masked]; [email-masked];
> > [email-masked]; [email-masked]
> > Subject: RE: [Isis-wg] draft-wei-isis-tlv-03 (Purge Originator Id)
> > 
> > Hi Jie, all
> > 
> > > Hostname would be helpful for network management and operation, thus
> > > rfc5301 defined the mechanism of dynamic hostname exchange.
> > >  
> > > On the other hand, if ISs already have the mapping from
> > System ID to 
> > > hostname, IMO it may be optional for purge packet to carry this
> > > information.
> > 
> > Some monitoring systems passively record ISIS messages.
> > Indeed, they could record the System ID - hostname mapping
> > from previous LSP, then use this database to enhance the
> > purge originator info. But it seems it would be easier for
> > them to have the name embedded in the purge message.
> > Not to mention for tools such as wireshark (and most probably
> > for logs and debugging tools)
> > 
> > Obviously, the decision to add the hostname is up to you and the WG.
> > IMHO, I see benefits (at least the above) and fail to see any
> > cost. Do you see any drawback?
> > 
> > Best regards,
> > Bruno 
> >  
> > > 
> > > Best regards,
> > > Jie
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: [email-masked]
> > > > [mailto:[email-masked]] On Behalf Of
> > > > [email-masked]
> > > > Sent: Tuesday, April 20, 2010 4:56 PM
> > > > To: [email-masked]; [email-masked];
> > > > [email-masked]
> > > > Subject: [Isis-wg] draft-wei-isis-tlv-03 (Purge Originator Id)
> > > > 
> > > > Hi Fang, Yue, Zhenqiang, Tony, Jie, all,
> > > > 
> > > > As the goal is to help the troubleshooting, and specifically to
> > > > locate the source IS, what about also adding the dynamic
> > hostname of 
> > > > the purge originator in addition to the system ID? (cf
> > existing TLV 
> > > > type 137)
> > > > 
> > > > Thanks,
> > > > Regards,
> > > > Bruno
> > > > 
> > > > _______________________________________________
> > > > Isis-wg mailing list
> > > > [email-masked]
> > > > https://www.ietf.org/mailman/listinfo/isis-wg
> > 
> 
> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg

---

From: Tony Li <[email-masked]>
Date: Wed, 21 Apr 2010 22:54:58 -0700

> 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.

Tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 21 Apr 2010 23:25:02 -0700

> 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.
> 
> 

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

---

From: Tony Li <[email-masked]>
Date: Wed, 21 Apr 2010 23:39:23 -0700

Hi Les,

> But hopefully we can comment on 01 anyway?? :-)

Of course!  ;-)

> become a standards document.

Well, the point was to help document some of the field failures that we've
seen and motivate the changes.
 
> 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?

> the system ID ALWAYS be there. (This is unenforceable of course)

Works for me.  Other folks?

> process are introduced by this draft.

Can't hurt.  I'm certain that this will break some conformance testers
regardless.  

Any other comments?

Tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 21 Apr 2010 23:41:22 -0700

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.

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

   Les

> 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]

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 21 Apr 2010 23:46:32 -0700

> Sent: Wednesday, April 21, 2010 11:39 PM
> To: Les Ginsberg (ginsberg); [email-masked]; Jie Dong;

I think the introduction as is provides a good description of the
motivations.

> Compromise: condense the text and move to the introduction?

Well, you have my vote (don't need it) - but if the consensus is to keep
some of this then I would be happier(sic) with your compromise proposal.

> > have a unique systemID but hostnames are optional I would prefer
that
> if
> > I think there needs to be language which makes clear that the
absence
> or

Indeed.
My concern is that someone will start rejecting purges if they don't
have the new info - which would clearly be wrong and incompatible.

   Les

---

From: mike shand <[email-masked]>
Date: Thu, 22 Apr 2010 11:00:01 +0100

> purged LSP with the additional TLVs i.e. store it (including the body)
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.
> 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?
>> but I think it has drawbacks when it is included in what is intended
>>      
> to
>    
>> even remotely suggest that. If you want to know when it is OK to
>>      
> purge,
>    
>> look at the base spec.
>>
>> are anecdotal and could be translated as "there are some weird bugs
>>      
> out
>    
>> SHOULD only be used in addition to the system ID TLV". As every IS
>>      
> MUST
>    
>> 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
>    

-- 
For corporate legal information go to:
www.cisco.com/web/about/doing_business/legal/cri

---

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

> Behalf Of Mike Shand (mshand)
> Sent: Thursday, April 22, 2010 3:00 AM
> To: [email-masked]

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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 22 Apr 2010 13:39:32 -0700

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

that
absence

---

From: Dave Katz <[email-masked]>
Date: Fri, 23 Apr 2010 11:57:41 -0600

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

---

From: Tony Li <[email-masked]>
Date: Fri, 23 Apr 2010 16:50:14 -0700

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" <[email-masked]> 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
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 23 Apr 2010 16:54:01 -0700

> From: Dave Katz [mailto:[email-masked]]
> Sent: Friday, April 23, 2010 10:58 AM
> To: Les Ginsberg (ginsberg)
> Cc: Tony Li; [email-masked]; Jie Dong;
> unambiguously says that the inserting system is also the originator of
> the purge (otherwise you need a flag.)

That is the intent.
That's why the legal values for the length can only be: (1*systemid
length) or (2*systemid length)

If you have one, then you are the originator of the purge.
If you have two, you are proxying for whomever first sent you the purge

We have "lots of room" so adding a flag could certainly be accommodated,
but it does not seem to add any value.

   Les

> >> Well, the point was to help document some of the field failures
that
> >> we've

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 23 Apr 2010 17:15:18 -0700

Tony -

This version looks good to me.

I will argue - though not very strenuously - for the removal of the
"Number of system IDs carried in this TLV" field. It raises the
unnecessary question of what the receiver should do if the length is
valid but does not == (number of system IDs * system ID length). But as
the TLV is only informational (i.e. a malformed purge originator TLV
should not cause the purged LSP to be ignored/discarded) this is not a
major issue.

Thanx for the quick turnaround.

   Les

> From: Tony Li [mailto:[email-masked]]
> Sent: Friday, April 23, 2010 4:50 PM
> To: Dave Katz; Les Ginsberg (ginsberg)
> Cc: [email-masked]; Jie Dong; bruno.decraene@orange-
> 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
> 
> 
> 
> >> The usefulness of the extensions defined in this draft depend upon
> >> the extent to which they are deployed - which no doubt will take
> >> 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
> >> purge, it would at least provide a pointer to the portion of the
> >> network in which the purge originated.
> >>
Value
> >> - System ID of the system inserting the TLV (Required) System ID of
> >> the system from which the purge was received (Optional)
> >>
> >> ???
> >>
> >>   Les
> >>
> >>> 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
> >>> True, but without the background, these changes would seem like
> >>> something straight out of the Oort cloud.
> >>>
> >>> Can't hurt.  I'm certain that this will break some conformance
> >>> testers regardless.
> >>>
> >>> Any other comments?
> >>>
> >>> Tony
> >>>
> >>>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 23 Apr 2010 17:41:41 -0700

As an editorial nit, I suspect the reference to "TC1" in the
introduction is a bit cryptic for the uninitiated. Perhaps adding the
following to the references:

ISO/IEC 10589:1992/ Cor.1:1993
Information technology -- Telecommunications and information exchange
between systems -- Intermediate system to Intermediate system
intra-domain routeing information exchange protocol for use in
conjunction with the protocol for providing the connectionless-mode
Network Service (ISO 8473) -- Technical Corrigendum 1

would help?

(Then again...maybe not. :-) )

   Les

> Sent: Friday, April 23, 2010 5:15 PM
> To: Tony Li; Dave Katz
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> > > unambiguously says that the inserting system is also the
originator
> > of
> > >>>> an implementation chooses to include the extra info in the
purge

---

From: Tony Li <[email-masked]>
Date: Fri, 23 Apr 2010 18:00:06 -0700

Sure, why not?

Tony

---

From: Dave Katz <[email-masked]>
Date: Sat, 24 Apr 2010 17:21:28 -0700

I don't much care either way, so long as the semantics are well-defined.

--Dave

On Apr 23, 2010, at 4:54 PM, Les Ginsberg (ginsberg) wrote:

>> TLV)
>> testers