Subject: RE: FW: [Isis-wg] I-D ACTION:draft-ietf-isis-interoperable-00.txt

From: mike shand <[email-masked]>
Date: Fri, 14 Jun 2002 08:33:31 +0100

At 15:50 13/06/2002 -0400, Don Goodspeed wrote:
>3. Also in section 6.1, the second sentence reads:
>   "When an LSP has been in the network for RemainingLifeTime, it is
>removed ..."
>Should this be:
>   "... in the network for RemainingLifeTime without being regenerated
>..." ?

This is a classic case of an attempt to give a simple description which 
glosses over some of the detail. Neither statement is without its problems. 
It all depends on what is meant by "an LSP". DO we mean a single instance 
of the LSP with a particular sequence number, or do we envisage that the 
same "LSP" exists for ever, but with different sequence numbers.

IN any case, it is not quite right to say when it has been in the network 
for RemainingLifeTime, since RemainingLifeTime is a monotonically 
decreasing value. What we really mean is when an LSP with a particular 
sequence number has been in the network for a period of time such that the 
RemainingLifetime value has been decreased to zero (since it isn't really 
an exact period of time, since it is required to decrement remainingLiftime 
at each forwarding). Even that isn't correct, since it doean't actually get 
deleted at that point. We wait another minute, or even another maxage.

However, this is all somewhat irrelevant and overkill in the context. We 
don't want to end up re-writing the complete description of what happens.

         Mike

_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://spider.juniper.net/mailman/listinfo/isis-wg

---

From: Jeff Parker <[email-masked]>
Date: Fri, 14 Jun 2002 11:39:55 -0400

Don -
	Thanks for the suggestions.  I have updated my copy
of the document (too large to send to this list as is)
and I've included the significant diffs below.  Most
of the meat is in the first two differences, where
we discuss the Attach Flag, and the chunk where we
discuss MaxAge and maxLSPGen.  The current context
of those sections appears next.

	The rest of the mail includes edits to make
references to 10589 uniform (briefly, the first
citation in a section gets a footnote, and I've
tried to catch all references to 'protocol' and
[1]), and ends with Don's original note.  The
order of the remaining diffs is arbitrary.  
Other, smaller, changes (date, acks, spelling)
are surpressed.  

	Enough changes have accumulated to warrant
a fresh spin, but I'll wait to hear reaction to
the first two paragraphs below.  

- jeff parker

///////// Significant Diffs   ///////////////////

21,28c21,31
< Each LSP contains a RemainingLifeTime field which is
< set to the MaxAge of the generating IS. 
< When an LSP has been in
< the network for RemainingLifeTime, it is removed, ensuring that
< corrupted or otherwise invalid LSPs do not remain in the network
< for too long. 
< The rate at which LSPs are regenerated is determined by the value 
< of maximumLSPGenerationInterval.
---
> Each LSP contains a RemainingLifetime field which is
> initially set to the MaxAge value on the generating IS. 
> The value stored in this field is decremented to mark the
> passage of time and the number of times it has been forwarded.  
> When the value of a foreign LSP becomes 0, an IS initiates
> a aging and purging process which will flush the LSP from the
> network.  
> This ensures that that corrupted or otherwise invalid 
> LSPs do not remain in the network indefinitely.
> The rate at which LSPs are regenerated by the originating IS
> is determined by the value of maximumLSPGenerationInterval.

10,12c10,13
< Some implementations allow the attachedFlag to be set 
< on Intermediate Systems routing IP traffic under restricted conditions, 
< such as the existence of a default route in the local routing table.
---
> Some implementations also allow the attachedFlag to be set 
> on Intermediate Systems routing IP traffic when there
> is a default route in the local routing table, or when 
> some other state is reached that implies a connection
> to the rest of the network.

///// Context ///////////////

6.1 MaxAge

   Each LSP contains a RemainingLifetime field which is initially set to
   the MaxAge value on the generating IS. The value stored in this field
   is decremented to mark the passage of time and the number of times it
   has been forwarded. When the value of a foreign LSP becomes 0, an IS
   initiates a aging and purging process which will flush the LSP from
   the network. This ensures that that corrupted or otherwise invalid
   LSPs do not remain in the network indefinitely.  The rate at which
   LSPs are regenerated by the originating IS is determined by the value
   of maximumLSPGenerationInterval.

   MaxAge is defined in ISO 10589 as an Architectural constant of 20
   minutes, and it is recommended that maximumLSPGenerationInterval be
   set to 15 minutes.  These times have proven to be too short in some
   networks, as they result in a steady flow of LSP updates even when
   nothing is changing. To reduce the rate of generation, some implemen-
   tations allow these times to be set by the network operator.
...
14. The Attached Bit

   In section 7.2.9.2 of ISO 10589 [1], an algorithm is described to
   determining when the attachedFlag should be set on an intermediate
   system. Some implementations also allow the attachedFlag to be set on
   Intermediate Systems routing IP traffic when there is a default route
   in the local routing table, when some other state is reached that
   implies a connection to the rest of the network.

/////////////// What Protocol Is this? ISO 10589 Citations ///////////////

21c21
< ISO 10589 requires that all Intermediate Systems in an area or domain 
---
> ISO 10589 [1] requires that all Intermediate Systems in an area or domain 
36c36
< ISO [1] defines the notification maximumAreaAddressMismatch,
---
> ISO 10589 defines the notification maximumAreaAddressMismatch,

7c7
< While ISO [1] requires in section 7.3.14.2 e) that any LSP
---
> While ISO 10589 [1] requires in section 7.3.14.2 e) that any LSP

26c26
< The protocol provides the architectural constant ReceiveLSPBufferSize
---
> ISO 10589 [1] defines the architectural constant ReceiveLSPBufferSize

30,32c30,32
< The originating buffer
< size parameters define the maximum size of an LSP that a router
< can generate.  The protocol directs the implementor to treat a PDU
---
> The originating buffer size parameters define the maximum size of 
> an LSP that a router can generate.  
> ISO 10589 directs the implementor to treat a PDU

7,8c7,8
< Some parameters to the protocol were defined as variable,
< but do not vary in practice.  These include
---
> Some that were defined as variables in ISO 10589 [1] 
> do not vary in practice.  These include

44,45c44,46
< ISO [1] defines the notification iDFieldLengthMismatch, 
< while the ISIS MIB [9] defines the notificationeisisIDLenMismatch. 
---
> ISO 10589 [1] defines the notification iDFieldLengthMismatch, 
> while the ISIS MIB [9] defines the notification 
> isisIDLenMismatch. 

8c8,9
< security concerns, as there is no change in the underlying protocol.
---
> security concerns, as there is no change in the underlying protocol
> described in ISO 10589 [1] and RFC 1195 [3].

7c7
< Some features defined in [1] and [3] are not in current use.
---
> Some features defined in ISO 10589 [1] and RFC 1195 [3] are not in current
use.

35c35,36
< Section 7.2.2, ISO [1] describes four metrics: Default Metric, Delay
Metric,
---
> Section 7.2.2, ISO 10589 [1] describes four metrics: 
> Default Metric, Delay Metric,

39c40
< In ISO, the most significant bit of the 8 bit metrics was
---
> In ISO 10589, the most significant bit of the 8 bit metrics was

41c44
< is discussed in section 7.3.21 of [1].  
---
> is discussed in section 7.3.21 of ISO 10589.  

7,8c7,8
< Some parameters to the protocol were defined as constants,
< but are modified in practice.  These include the following
---
> Some parameters that were defined as constant in ISO 10589 [1]
> are modified in practice.  These include the following

32c32,33
< section 8.2.4 [1].  However, in an IP Only environment,
---
> section 8.2.4 of ISO 10589 [1].  
> However, in an IP Only environment,

7c7
< In [1] 7.2.9.2, an algorithm is described to 
---
> In section 7.2.9.2 of ISO 10589 [1], an algorithm is described to 

7c7
< In section 8.2.4.2, ISO [1] does not explicitly require comparison
---
> In section 8.2.4.2, ISO 10589 [1] does not explicitly require comparison

115c115
< The original design of IS-IS, as described in [1] has proved
---
> The original design of IS-IS, as described in ISO 10589 [1] has proved

17c17
< Given that IIH PDUs as specified in ISO[1] do not include a checksum,
---
> Given that IIH PDUs as specified in ISO 10589 do not include a checksum,

119c119
< protocol as described in [1] and [3] and the protocol
---
> protocol as described in ISO 10589 and RFC 1195 [3] and the protocol

17c17
< ISO [1] defines ISISHoldingMultiplier to be 10,
---
> ISO 10589 [1] defines ISISHoldingMultiplier to be 10,

> Jeff,
> 
> Just had a chance to pore over the draft and I've got a few comments
> (hope my word wrapping comes out OK):
> 
> 1. Because of the different authors, the footnote references are
> inconsistent.  Some sections use just the reference "In [1]", while
> others use "in ISO [1]", while other make no reference to the footnote
> "in ISO 10589", some are just "in ISO", while in some, there is no
> reference when there should be "such-and-such is defined as a 
> constant."  (should be ...as a constant in [1]).  Other place say
> "The protocol".
> 
> I can either cc the WG with the list or send it directly to you.
> 
> 2. In section 6.1 MaxAge, in the first line "which is set to the
> MaxAge of the generating IS", should this be:
>   "which is initially set to the MaxAge value on the generating IS" ?
> 
> 4. In section 7.1 ID Length, the last sentence needs a space between
> notification and isisIDLenMismatch.
> 
> 5. In section 8.3 Alternative Metrics, there should be blank line
> after the quote from the ISO doc.
> 
> 6. In section 14 The Attached Bit, in the 2nd sentence:
>   "Some implementations allow the attachedFlag to be set on (ISs)
>    routing IP traffic under restricted conditions, such as ..."
> did we mean to say "only be set ... under restricted conditions"
> or "can additionally be set" ?
> 
> Thanks,
> Don