From Alex Zinin Mon Jun 3 20:18:12 2002 From: Alex Zinin (Alex Zinin) Date: Mon, 3 Jun 2002 12:18:12 -0700 Subject: [Isis-wg] last call on draft draft-ietf-isis-ext-lsp-frags-00 ... In-Reply-To: References: Message-ID: <1359636974.20020603121812@psg.com> Amir, > Alex, > comments inline. Thanks very much for the helpful comments and suggestions. > As always, other suggetions, especially for terminology, are more than welcomed. ... >> > Extended system-id >> >> Sounds like we're stretching out the normal system-id. >> Maybe "Virtual system-id" would be a better choice? >> > again, could be bad naming. However, I originally thought "Virtual" to be a little confusing, > as a "virtual link" term is already used in the IS-IS spec, for a completely different purpose. The > draft uses "extended" for LSPs, since they really extend the original LS information an IS could advertise, > as opposed to "Virtual System", which doesn't really add any additional info. Does that > make sense? "extended" LSPs, though not perfect, make more sense--I couldn't come up with a better name, maybe native English speakers can :) >> > These modes may be configured per level. There is no restriction >> > that an L1/L2 IS operates in the same mode, for both L1 and L2. >> >> Shouldn't the modes be on a per-level & area basis. This >> text also sounds like all routers within a level (or an area >> if corrected) need to work in the same mode, which is not true, >> since modified SPF is a requirement regardless of the LSP >> origination mode. > agreed, that's the original intent. I'll add "per area". The actual requirement > is "per spf", but I think it will confuse more than it will clarify. Agreed. >> >> > 2.0 IS Alias ID TLV (IS-A) >> > >> > The proposed IS-A TLV allows extension-capable ISs to >> recognize all >> > LSPs of an Originating System, and combine the original >> and extended >> > LSPs for the purpose of SPF computation. >> > >> > The IS Alias ID TLV is type 24, and contains a new data >> structure, >> > consisting of: >> > 7 octets of system Id and pseudonode number >> > 1 octet of length of sub-TLVs >> > 0-247 octets of sub-TLVs, >> > where each sub-TLV consists of a sequence of >> > 1 octet of sub-type >> > 1 octet of length >> > 0-245 octets of value >> > >> > Without sub-TLVs, this structure consumes 8 octets per >> LSP set. This >> > TLV MUST be included in fragment 0 of every LSP set >> belonging to an >> > Originating System. >> >> Couldn't find any info on how to put S' and S'' in the TLV. >> > Actually, what you need to put here is S (or the is-alias-id, which > could be different). The S' and S'' (and also S) appear in the LSP header. I think I was confused by the illustration. Could you please specify more explicitly which ID is put in the TLV. >> Couldn't find description of any sub-TLVs that would be >> used to do the above. > It's just put there for future or proprietary use - doesn't take up > any space, I think we should keep it. No objection to this, but you need to describe sub-TLV handling properly. >> >> Couldn't find any rules about sub-TLV handling, i.e., padding >> and length calculation with it. >> >> The format description above should use the illustration >> style from 1195. > I don't fully understand what's missing, but I will add an example. > I've used the format from the TE-extensions draft, which I think to be > clear and well-discussed. Please clarify what you'd like to see here. I'd like the TLV format illustration to be consistent with 1195, i.e., something like this: x CODE - 24 x LENGTH - total length of the value field. x VALUE - the following data: No. of Octets +--------------------------------+ | ALIAS SYSTEM ID | 7 +--------------------------------+ | SUB-TLV LENGTH | 1 +--------------------------------+ | | . SUB-TLVs . | | +--------------------------------+ >> What about the OL bit? > The 3.1.* sections are exceptions. The OL bit should be set/unset in original and extended LSPs the same as before. Don't we want to have consistent values in the "normal" and "extended" LSPs, at least for mode 2? >> > 3.2 Operation Mode 1 Additions >> ... >> > When an extended LSP belonging to extended system-id S' is first >> > created, the original LSP MUST specify S' as a neighbor, >> with metric >> > set to zero. This in order to satisfy the two-way >> connectivity check >> > on other routers, as well as to consider the cost of reaching the >> >> I thought that the S'->S link would be needed to satisfy >> the TWC check for the S->S' one, not the other way around... >> > Depends on which node (S or S') was first considered in SPF. In Mode 1, it's true > that always S will be reached first, but this isn't guaranteed in mode 2. Note the name of the section where this text belongs ;) >> > 4. Purging Extended LSP Fragments >> ... >> > However, an extended LSP fragment >> zero should not >> > be purged until all of the fragments in its set (i.e. >> belonging to a >> > particular extended system-id), are empty as well. This >> is to ensure >> > implementations consider the fragments in their SPF >> computations, as >> > specified in section 7.2.5. >> >> Given what section 5 says about ignoring non-0 fragments when >> fragment zero is missing, what does the above rule give us? >> > the above rule is specifically to ensure section 5 works well: if we have > info in other fragments, but the zero-fragment is empty (and we don't re-arrange > information, as we shouldn't), we still need to keep that fragment so other fragments > are considered. I guess this is true regardless of this draft or not - we just wanted > to clarify it. Makes sense. >> We don't have to go through mode-1 to get to mode-2. An upgrade of >> SW does not necessarily mean changing the LSP origination process. >> In fact, I would argue that the default setting MUST be the standard >> one, i.e., neither mode 1 nor mode 2, and it would be really great >> if this was spelled out. >> > Your upgrade option is identical to what the draft suggests - since "standard one" > is really Mode 1 (you can either have mode-1 or mode-2). The difference between mode-1 > and the "standard" way, is that the standard way asserts when the maximum fragments > are reached ;-) There's also the additional tlv, but there's no harm in advertising it. I don't agree here. I think the most common case will be where the network works and routers' SW gets upgraded. Once upgraded the LSP origination behavior should not change, i.e., neither mode-1 nor mode-2 should be activated until explicitly configured by the admin. This should save from problems with implementations that for some buggy reason react incorrectly to 0-cost links in non-pseudo LSPs, or with implementations that implement your spec incorrectly, as well as this is just a good general practice to not enable new behavior by default, especially in routing protocols. Thanks. Alex From rameshrr@future.futsoft.com Tue Jun 4 14:44:48 2002 From: rameshrr@future.futsoft.com (Rayapureddi Ramesh) Date: Tue, 4 Jun 2002 19:14:48 +0530 Subject: [Isis-wg] reg: no of IS's in an area Message-ID: <002701c20bcd$ff6b79b0$1305a8c0@future.futsoft.com> This is a multi-part message in MIME format. ------=_NextPart_000_0028_01C20BFC.1923B5B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hello, Is there any limitation on maximum number of Intermediate System can be configured in an Area. If any one knows please let me know. Thanks in advance. Regards, Ramesh *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** ------=_NextPart_000_0028_01C20BFC.1923B5B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
Is = there any=20 limitation on maximum number of Intermediate System can be = configured in an=20 Area.
If any = one knows=20 please let me know.
 
Thanks = in=20 advance.
 
Regards,
Ramesh
 
 
------=_NextPart_000_0028_01C20BFC.1923B5B0-- From jparker@axiowave.com Tue Jun 4 15:41:50 2002 From: jparker@axiowave.com (Jeff Parker) Date: Tue, 4 Jun 2002 10:41:50 -0400 Subject: [Isis-wg] reg: no of IS's in an area Message-ID: > Is there any limitation on maximum number of > Intermediate System can be configured in an Area. > If any one knows please let me know. > > Ramesh The protocol does not have any realistic hard limits. That is, you cannot have more than 2^48 routers in your network, but things will probably fall apart before reaching that limit. Implementations have limits: often these will be in the SPF computation, the processing of large LSP sets, and dealing with many interfaces. Various three digit numbers have been suggested as the realistic limits on the number of routers per area. Your mileage may vary. - jeff parker From jonathan.sadler@tellabs.com Tue Jun 4 18:32:39 2002 From: jonathan.sadler@tellabs.com (Jonathan Sadler) Date: Tue, 04 Jun 2002 12:32:39 -0500 Subject: [Isis-wg] reg: no of IS's in an area References: Message-ID: <3CFCF9B7.6C16D8D4@tellabs.com> Please be aware that a number of IS-IS implementations used in the support of OSI CLNP routing are limited to 50 or so ISes per area. This situation exists due to advice provided by SIF to the SONET/SDH NE community back in the early '90s. While this doesn't pose an interoperability problem per se, it does cause nightmares for SONET/SDH DCN designers. Jonathan Sadler Jeff Parker wrote: > > > Is there any limitation on maximum number of > > Intermediate System can be configured in an Area. > > If any one knows please let me know. > > > > Ramesh > > The protocol does not have any realistic hard limits. > That is, you cannot have more than 2^48 routers in > your network, but things will probably fall apart > before reaching that limit. > > Implementations have limits: often these will be in > the SPF computation, the processing of large LSP sets, > and dealing with many interfaces. Various three digit > numbers have been suggested as the realistic limits > on the number of routers per area. Your mileage may vary. > > - jeff parker > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ From jlearman@cisco.com Tue Jun 4 20:42:13 2002 From: jlearman@cisco.com (Jeff Learman) Date: Tue, 04 Jun 2002 15:42:13 -0400 Subject: [Isis-wg] reg: no of IS's in an area In-Reply-To: <3CFCF9B7.6C16D8D4@tellabs.com> References: Message-ID: <4.3.2.7.2.20020604151606.01a8dd18@dingdong.cisco.com> The limit of 50 (in the Guidelines doc written in 1997) was advice to network designers based on limitations of existing equipment. It's unfortunate if some NE vendors have misconstrued that as an excuse to limit their support to 50. Regards, Jeff At 01:32 PM 6/4/2002, Jonathan Sadler wrote: >Please be aware that a number of IS-IS implementations used in the >support of OSI CLNP routing are limited to 50 or so ISes per area. This >situation exists due to advice provided by SIF to the SONET/SDH NE >community back in the early '90s. > >While this doesn't pose an interoperability problem per se, it does >cause nightmares for SONET/SDH DCN designers. > >Jonathan Sadler > >Jeff Parker wrote: >> >> > Is there any limitation on maximum number of >> > Intermediate System can be configured in an Area. >> > If any one knows please let me know. >> > >> > Ramesh >> >> The protocol does not have any realistic hard limits. >> That is, you cannot have more than 2^48 routers in >> your network, but things will probably fall apart >> before reaching that limit. >> >> Implementations have limits: often these will be in >> the SPF computation, the processing of large LSP sets, >> and dealing with many interfaces. Various three digit >> numbers have been suggested as the realistic limits >> on the number of routers per area. Your mileage may vary. >> >> - jeff parker >> _______________________________________________ >> Isis-wg mailing list - Isis-wg@spider.juniper.net >> http://spider.juniper.net/mailman/listinfo/isis-wg >============================================================ >The information contained in this message may be privileged >and confidential and protected from disclosure. If the >reader of this message is not the intended recipient, or an >employee or agent responsible for delivering this message to >the intended recipient, you are hereby notified that any >reproduction, dissemination or distribution of this >communication is strictly prohibited. If you have received >this communication in error, please notify us immediately by >replying to the message and deleting it from your computer. > >Thank you. >Tellabs >============================================================ >_______________________________________________ >Isis-wg mailing list - Isis-wg@spider.juniper.net >http://spider.juniper.net/mailman/listinfo/isis-wg From jparker@axiowave.com Tue Jun 4 23:35:07 2002 From: jparker@axiowave.com (Jeff Parker) Date: Tue, 4 Jun 2002 18:35:07 -0400 Subject: [Isis-wg] RE: IS-IS MIB (metric comments) Message-ID: > In version 0.8 of the ISIS MIB, you have a Textual Convention > for DefaultMetric which is defined as (1..63). Should we > allow zero in the range, as our passive interfaces have a > metric of zero. > > Also, are you working on adding a WideMetric TC and associated > objects (isisCircLevelWideMetric, isisIPRAWideMetric, > isisSummAddrWideMetric)? > > -don Don - 1) Thanks. The TC is easy to change from 1..63 to 0..63. 2) I'm not sure if the right thing to do here is to add new types. Is there harm in simply extending the range of all of these to go past 63? - jeff parker From dgoodspe@excite.com Wed Jun 5 00:06:47 2002 From: dgoodspe@excite.com (Don Goodspeed) Date: Tue, 4 Jun 2002 19:06:47 -0400 (EDT) Subject: [Isis-wg] RE: IS-IS MIB (metric comments) Message-ID: <20020604230647.B62D9B6FE@xmxpita.excite.com> Jeff, Thanks for cc'ing the WG on this. I'd forgotten to when I sent this originally. In section 12.2 of the "Recommendations" draft you just sent out, we acknowledge that the narrow and the wide metric can be set independently. Separate attributes would make sense then, even if the IS-IS implementation used always sets one equal to the other internally. I would also push for a separate WideMetric TC since allowing a larger range on the current DefaultMetric attributes might break some range checking algorithms. My 2 cents, Don --- On Tue 06/04, Jeff Parker wrote: From: Jeff Parker [mailto: jparker@axiowave.com] To: dgoodspe@excite.com Cc: isis-wg@spider.juniper.net Date: Tue 06/04 Subject: RE: IS-IS MIB (metric comments) > > > In version 0.8 of the ISIS MIB, you have a Textual Convention > > for DefaultMetric which is defined as (1..63). Should we > > allow zero in the range, as our passive interfaces have a > > metric of zero. > > > > Also, are you working on adding a WideMetric TC and associated > > objects (isisCircLevelWideMetric, isisIPRAWideMetric, > > isisSummAddrWideMetric)? > > > > -don > > Don - > 1) Thanks. The TC is easy to change from 1..63 to 0..63. > > 2) I'm not sure if the right thing to do here is to add > new types. Is there harm in simply extending the range of > all of these to go past 63? > > - jeff parker > ------------------------------------------------ Join Excite! - http://www.excite.com The most personalized portal on the Web! From christi@nortelnetworks.com Wed Jun 5 12:42:41 2002 From: christi@nortelnetworks.com (Philip Christian) Date: Wed, 5 Jun 2002 12:42:41 +0100 Subject: [Isis-wg] last call on draft draft-ietf-isis-ext-lsp-frags-00 ... Message-ID: <4103264BC8D3D51180B7002048400C454FB6F5@zhard0jd.europe.nortel.com> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C20C85.7758C92A Content-Type: text/plain; charset="iso-8859-1" > ... > >> > Extended system-id > >> > >> Sounds like we're stretching out the normal system-id. > >> Maybe "Virtual system-id" would be a better choice? > >> > > > again, could be bad naming. However, I originally thought > "Virtual" to be a little confusing, > > as a "virtual link" term is already used in the IS-IS spec, > for a completely different purpose. The > > draft uses "extended" for LSPs, since they really extend > the original LS information an IS could advertise, > > as opposed to "Virtual System", which doesn't really add > any additional info. Does that > > make sense? > > "extended" LSPs, though not perfect, make more sense--I couldn't come > up with a better name, maybe native English speakers can :) > > Is this is a similar concept to "Extended Local Circuit ID" in three way handshaking? it sounds as though it is, in which case consistency is a good thing. Philip ------_=_NextPart_001_01C20C85.7758C92A Content-Type: text/html; charset="iso-8859-1" RE: [Isis-wg] last call on draft draft-ietf-isis-ext-lsp-frags-00 ...

> ...
> >> >      Extended system-id
> >>
> >> Sounds like we're stretching out the normal system-id.
> >> Maybe "Virtual system-id" would be a better choice?
> >>
>
> > again, could be bad naming. However, I originally thought
> "Virtual" to be a little confusing,
> > as a "virtual link" term is already used in the IS-IS spec,
> for a completely different purpose. The
> > draft uses "extended" for LSPs, since they really extend
> the original LS information an IS could advertise,
> > as opposed to "Virtual System", which doesn't really add
> any additional info. Does that
> > make sense?
>
> "extended" LSPs, though not perfect, make more sense--I couldn't come
> up with a better name, maybe native English speakers can :)
>
>

Is this is a similar concept to "Extended Local Circuit ID" in three way handshaking?
it sounds as though it is, in which case consistency is a good thing.

Philip

------_=_NextPart_001_01C20C85.7758C92A-- From christi@nortelnetworks.com Mon Jun 10 11:29:41 2002 From: christi@nortelnetworks.com (Philip Christian) Date: Mon, 10 Jun 2002 11:29:41 +0100 Subject: [Isis-wg] Proprietary / Private TLV numbers? Message-ID: <4103264BC8D3D51180B7002048400C454FB701@zhard0jd.europe.nortel.com> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C21069.BADDA0D4 Content-Type: text/plain; charset="iso-8859-1" Looking at draft-ietf-isis-wg-tlv-codepoints-02.txt I notice that there is not really any mechanism for private or proprietary use of a TLV. Thus various companies (including my own) have just pcked one and used it for their own purpose. Eventually this will create an interop problem, but what else is a company to do? Is there a way that we could define that a certain TLV number is for private / proprietary / experimental purposes? This would then stop people just picking one. I am thinking that there would have to be some sort of entity identifier in there so that when you see this TLV you know whether it is yours or not. Maybe we could define that the first four bytes are an IP address for example. Any entity large enough to want to use a proprietary TLV would have a public IP address to put in there, I would have thought. After the first for bytes then the rest would be free. Or maybe there is a better way to identify a particular company / entity (like a MAC address)? Maybe ISO 8348? What do people think? Philip ------_=_NextPart_001_01C21069.BADDA0D4 Content-Type: text/html; charset="iso-8859-1"
Looking at draft-ietf-isis-wg-tlv-codepoints-02.txt I notice that there is not really any mechanism for private or proprietary use of a TLV.
 
Thus various companies (including my own) have just pcked one and used it for their own purpose.  Eventually this will create an interop problem, but what else is a company to do?
 
Is there a way that we could define that a certain TLV number is for private / proprietary / experimental purposes?
 
This would then stop people just picking one.
 
I am thinking that there would have to be some sort of entity identifier in there so that when you see this TLV you know whether it is yours or not.
 
Maybe we could define that the first four bytes are an IP address for example.  Any entity large enough to want to use a proprietary TLV would have a public IP address to put in there, I would have thought. After the first for bytes then the rest would be free.
 
Or maybe there is a better way to identify a particular company / entity (like a MAC address)?  Maybe ISO 8348?
 
What do people think?
 
Philip
 
------_=_NextPart_001_01C21069.BADDA0D4-- From mshand@cisco.com Mon Jun 10 12:23:39 2002 From: mshand@cisco.com (mike shand) Date: Mon, 10 Jun 2002 12:23:39 +0100 Subject: [Isis-wg] Proprietary / Private TLV numbers? In-Reply-To: <4103264BC8D3D51180B7002048400C454FB701@zhard0jd.europe.nor tel.com> Message-ID: <4.3.2.7.2.20020610121359.026459d8@jaws.cisco.com> At 11:29 10/06/2002 +0100, Philip Christian wrote: >Looking at draft-ietf-isis-wg-tlv-codepoints-02.txt I notice that there is >not really any mechanism for private or proprietary use of a TLV. > >Thus various companies (including my own) have just pcked one and used it >for their own purpose. Eventually this will create an interop problem, >but what else is a company to do? > >Is there a way that we could define that a certain TLV number is for >private / proprietary / experimental purposes? > >This would then stop people just picking one. > >I am thinking that there would have to be some sort of entity identifier >in there so that when you see this TLV you know whether it is yours or not. > >Maybe we could define that the first four bytes are an IP address for >example. Any entity large enough to want to use a proprietary TLV would >have a public IP address to put in there, I would have thought. After the >first for bytes then the rest would be free. > >Or maybe there is a better way to identify a particular company / entity >(like a MAC address)? Maybe ISO 8348? > >What do people think? > >Philip > This has been suggested before, but never came to anything. I think if it WERE to be done then using something link the MAC OUI would probably work. What do you mean by ISO 8348? Do you mean ISO 6523? I hope not :-) Mike From christi@nortelnetworks.com Mon Jun 10 13:43:18 2002 From: christi@nortelnetworks.com (Philip Christian) Date: Mon, 10 Jun 2002 13:43:18 +0100 Subject: [Isis-wg] Proprietary / Private TLV numbers? Message-ID: <4103264BC8D3D51180B7002048400C454FB702@zhard0jd.europe.nortel.com> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2107C.658C0C02 Content-Type: text/plain; charset="iso-8859-1" I suppose that we could define different sub-TLVs, a sub-TLV if the identifier is an IPv4 address, a different sub-TLV if it is a MAC address, etc Then folks could use whichever mechanism they prefer, as long as it is a globally unique identifier. Or is that too complex? Philip > -----Original Message----- > From: mike shand [mailto:mshand@cisco.com] > Sent: Monday, June 10, 2002 12:24 PM > To: Christian, Philip [HAL02:GI50:EXCH] > Cc: isis-wg@spider.juniper.net > Subject: Re: [Isis-wg] Proprietary / Private TLV numbers? > > > At 11:29 10/06/2002 +0100, Philip Christian wrote: > >Looking at draft-ietf-isis-wg-tlv-codepoints-02.txt I notice > that there is > >not really any mechanism for private or proprietary use of a TLV. > > > >Thus various companies (including my own) have just pcked > one and used it > >for their own purpose. Eventually this will create an > interop problem, > >but what else is a company to do? > > > >Is there a way that we could define that a certain TLV number is for > >private / proprietary / experimental purposes? > > > >This would then stop people just picking one. > > > >I am thinking that there would have to be some sort of > entity identifier > >in there so that when you see this TLV you know whether it > is yours or not. > > > >Maybe we could define that the first four bytes are an IP > address for > >example. Any entity large enough to want to use a > proprietary TLV would > >have a public IP address to put in there, I would have > thought. After the > >first for bytes then the rest would be free. > > > >Or maybe there is a better way to identify a particular > company / entity > >(like a MAC address)? Maybe ISO 8348? > > > >What do people think? > > > >Philip > > > > This has been suggested before, but never came to anything. I > think if it > WERE to be done then using something link the MAC OUI would > probably work. > What do you mean by ISO 8348? Do you mean ISO 6523? I hope not :-) > > Mike > ------_=_NextPart_001_01C2107C.658C0C02 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Isis-wg] Proprietary / Private TLV numbers?

I suppose that we could define different sub-TLVs, a = sub-TLV if the identifier is an IPv4 address, a different sub-TLV if it = is a MAC address, etc

Then folks could use whichever mechanism they prefer, = as long as it is a globally unique identifier.

Or is that too complex?

Philip

> -----Original Message-----
> From: mike shand [mailto:mshand@cisco.com]
> Sent: Monday, June 10, 2002 12:24 PM
> To: Christian, Philip [HAL02:GI50:EXCH]
> Cc: isis-wg@spider.juniper.net
> Subject: Re: [Isis-wg] Proprietary / Private = TLV numbers?
>
>
> At 11:29 10/06/2002 +0100, Philip Christian = wrote:
> >Looking at = draft-ietf-isis-wg-tlv-codepoints-02.txt I notice
> that there is
> >not really any mechanism for private or = proprietary use of a TLV.
> >
> >Thus various companies (including my own) = have just pcked
> one and used it
> >for their own purpose.  Eventually = this will create an
> interop problem,
> >but what else is a company to do?
> >
> >Is there a way that we could define that a = certain TLV number is for
> >private / proprietary / experimental = purposes?
> >
> >This would then stop people just picking = one.
> >
> >I am thinking that there would have to be = some sort of
> entity identifier
> >in there so that when you see this TLV you = know whether it
> is yours or not.
> >
> >Maybe we could define that the first four = bytes are an IP
> address for
> >example.  Any entity large enough to = want to use a
> proprietary TLV would
> >have a public IP address to put in there, I = would have
> thought. After the
> >first for bytes then the rest would be = free.
> >
> >Or maybe there is a better way to identify = a particular
> company / entity
> >(like a MAC address)?  Maybe ISO = 8348?
> >
> >What do people think?
> >
> >Philip
> >
>
> This has been suggested before, but never came = to anything. I
> think if it
> WERE to be done then using something link the = MAC OUI would
> probably work.
> What do you mean by ISO 8348? Do you mean ISO = 6523? I hope not :-)
>
>          = Mike
>

------_=_NextPart_001_01C2107C.658C0C02-- From mshand@cisco.com Mon Jun 10 14:05:20 2002 From: mshand@cisco.com (mike shand) Date: Mon, 10 Jun 2002 14:05:20 +0100 Subject: [Isis-wg] Proprietary / Private TLV numbers? In-Reply-To: <4103264BC8D3D51180B7002048400C454FB702@zhard0jd.europe.nor tel.com> Message-ID: <4.3.2.7.2.20020610140439.02656f28@jaws.cisco.com> At 13:43 10/06/2002 +0100, Philip Christian wrote: >I suppose that we could define different sub-TLVs, a sub-TLV if the >identifier is an IPv4 address, a different sub-TLV if it is a MAC address, etc > >Then folks could use whichever mechanism they prefer, as long as it is a >globally unique identifier. > >Or is that too complex? Yes! That's how NSAP addresses got to be so awful :-) Mike >Philip > > > -----Original Message----- > > From: mike shand [mailto:mshand@cisco.com] > > Sent: Monday, June 10, 2002 12:24 PM > > To: Christian, Philip [HAL02:GI50:EXCH] > > Cc: isis-wg@spider.juniper.net > > Subject: Re: [Isis-wg] Proprietary / Private TLV numbers? > > > > > > At 11:29 10/06/2002 +0100, Philip Christian wrote: > > >Looking at draft-ietf-isis-wg-tlv-codepoints-02.txt I notice > > that there is > > >not really any mechanism for private or proprietary use of a TLV. > > > > > >Thus various companies (including my own) have just pcked > > one and used it > > >for their own purpose. Eventually this will create an > > interop problem, > > >but what else is a company to do? > > > > > >Is there a way that we could define that a certain TLV number is for > > >private / proprietary / experimental purposes? > > > > > >This would then stop people just picking one. > > > > > >I am thinking that there would have to be some sort of > > entity identifier > > >in there so that when you see this TLV you know whether it > > is yours or not. > > > > > >Maybe we could define that the first four bytes are an IP > > address for > > >example. Any entity large enough to want to use a > > proprietary TLV would > > >have a public IP address to put in there, I would have > > thought. After the > > >first for bytes then the rest would be free. > > > > > >Or maybe there is a better way to identify a particular > > company / entity > > >(like a MAC address)? Maybe ISO 8348? > > > > > >What do people think? > > > > > >Philip > > > > > > > This has been suggested before, but never came to anything. I > > think if it > > WERE to be done then using something link the MAC OUI would > > probably work. > > What do you mean by ISO 8348? Do you mean ISO 6523? I hope not :-) > > > > Mike > > From christi@nortelnetworks.com Mon Jun 10 15:06:57 2002 From: christi@nortelnetworks.com (Philip Christian) Date: Mon, 10 Jun 2002 15:06:57 +0100 Subject: [Isis-wg] Proprietary / Private TLV numbers? Message-ID: <4103264BC8D3D51180B7002048400C454FB704@zhard0jd.europe.nortel.com> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C21088.155172F2 Content-Type: text/plain; charset="iso-8859-1" A vendor code of 4 octets could be an IPv4 address. Then no-one would have to assign them. The vendor just uses a global IPv4 address that he has. Even the smallest vendor can buy a /32 IP address for this purpose. That would work. Philip > -----Original Message----- > From: Mike Truskowski [mailto:truskows@cisco.com] > Sent: Monday, June 10, 2002 2:42 PM > To: mshand@cisco.com > Cc: Christian, Philip [HAL02:GI50:EXCH]; isis-wg@spider.juniper.net > Subject: Re: [Isis-wg] Proprietary / Private TLV numbers? > > > Why not just do the following? > > +-------------------------------------------------+ > | Type | Length | Value | > +-------------------------------------------------+ > | TLV # | Length | vendor code | "value" | > +-------------------------------------------------+ > > Where the vendor code is a fixed 3-4 octets? > > I guess one could do this on their own... couldn't they? > > The major problem I see here is what Philip said he wanted to fix... > > If vendors are doing this already and this is trying to avoid > interoperability > problems... then it would seem reasonable that the carrier > would go back and > install new images or force the vendor to fix the embedded > base.. but they > won't do either.. thus leaving the problem to stumble over some day... > > Mike > > > At 13:43 10/06/2002 +0100, Philip Christian wrote: > > > > >I suppose that we could define different sub-TLVs, a > sub-TLV if the > > >identifier is an IPv4 address, a different sub-TLV if it > is a MAC address, etc > > > > > >Then folks could use whichever mechanism they prefer, as > long as it is a > > >globally unique identifier. > > > > > >Or is that too complex? > > > > Yes! That's how NSAP addresses got to be so awful :-) > > > > Mike > > > > > > > > >Philip > > > > > > > -----Original Message----- > > > > From: mike shand > [mailto:mshand@cisco.com] > > > > Sent: Monday, June 10, 2002 12:24 PM > > > > To: Christian, Philip [HAL02:GI50:EXCH] > > > > Cc: isis-wg@spider.juniper.net > > > > Subject: Re: [Isis-wg] Proprietary / Private TLV numbers? > > > > > > > > > > > > At 11:29 10/06/2002 +0100, Philip Christian wrote: > > > > >Looking at draft-ietf-isis-wg-tlv-codepoints-02.txt I notice > > > > that there is > > > > >not really any mechanism for private or proprietary > use of a TLV. > > > > > > > > > >Thus various companies (including my own) have just pcked > > > > one and used it > > > > >for their own purpose. Eventually this will create an > > > > interop problem, > > > > >but what else is a company to do? > > > > > > > > > >Is there a way that we could define that a certain TLV > number is for > > > > >private / proprietary / experimental purposes? > > > > > > > > > >This would then stop people just picking one. > > > > > > > > > >I am thinking that there would have to be some sort of > > > > entity identifier > > > > >in there so that when you see this TLV you know whether it > > > > is yours or not. > > > > > > > > > >Maybe we could define that the first four bytes are an IP > > > > address for > > > > >example. Any entity large enough to want to use a > > > > proprietary TLV would > > > > >have a public IP address to put in there, I would have > > > > thought. After the > > > > >first for bytes then the rest would be free. > > > > > > > > > >Or maybe there is a better way to identify a particular > > > > company / entity > > > > >(like a MAC address)? Maybe ISO 8348? > > > > > > > > > >What do people think? > > > > > > > > > >Philip > > > > > > > > > > > > > This has been suggested before, but never came to anything. I > > > > think if it > > > > WERE to be done then using something link the MAC OUI would > > > > probably work. > > > > What do you mean by ISO 8348? Do you mean ISO 6523? I > hope not :-) > > > > > > > > Mike > > > > > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@spider.juniper.net > > http://spider.juniper.net/mailman/listinfo/isis-wg > > > > ------_=_NextPart_001_01C21088.155172F2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Isis-wg] Proprietary / Private TLV numbers?

A vendor code of 4 octets could be an IPv4 = address.
Then no-one would have to assign them. The vendor = just uses a global IPv4 address that he has.

Even the smallest vendor can buy a /32 IP address for = this purpose.

That would work.

Philip

> -----Original Message-----
> From: Mike Truskowski [mailto:truskows@cisco.com]=
> Sent: Monday, June 10, 2002 2:42 PM
> To: mshand@cisco.com
> Cc: Christian, Philip [HAL02:GI50:EXCH]; = isis-wg@spider.juniper.net
> Subject: Re: [Isis-wg] Proprietary / Private = TLV numbers?
>
>
> Why not just do the following?
>
> = +-------------------------------------------------+
> | Type   |  Length  = |       = Value           &= nbsp;     |
> = +-------------------------------------------------+
> | TLV #  |  Length  |  = vendor code  |   "value"   |
> = +-------------------------------------------------+
>
> Where the vendor code is a fixed 3-4 = octets?
>
> I guess one could do this on their own... = couldn't they?
>
> The major problem I see here is what Philip = said he wanted to fix...
>
> If vendors are doing this already and this is = trying to avoid
> interoperability
> problems... then it would seem reasonable that = the carrier
> would go back and
> install new images or force the vendor to fix = the embedded
> base..  but they
> won't do either.. thus leaving the problem to = stumble over some day...
>
> Mike
>
> > At 13:43 10/06/2002 +0100, Philip = Christian wrote:
> >
> > >I suppose that we could define = different sub-TLVs, a
> sub-TLV if the
> > >identifier is an IPv4 address, a = different sub-TLV if it
> is a MAC address, etc
> > >
> > >Then folks could use whichever = mechanism they prefer, as
> long as it is a
> > >globally unique identifier.
> > >
> > >Or is that too complex?
> >
> > Yes! That's how NSAP addresses got to be = so awful :-)
> >
> = >          Mike
> >
> >
> >
> > >Philip
> > >
> > > > -----Original = Message-----
> > > > From: mike shand
> [<mailto:mshand@cisco.com>mailto:mshand@cisco.com]
> > > > Sent: Monday, June 10, 2002 = 12:24 PM
> > > > To: Christian, Philip = [HAL02:GI50:EXCH]
> > > > Cc: = isis-wg@spider.juniper.net
> > > > Subject: Re: [Isis-wg] = Proprietary / Private TLV numbers?
> > > >
> > > >
> > > > At 11:29 10/06/2002 +0100, = Philip Christian wrote:
> > > > >Looking at = draft-ietf-isis-wg-tlv-codepoints-02.txt I notice
> > > > that there is
> > > > >not really any mechanism for = private or proprietary
> use of a TLV.
> > > > >
> > > > >Thus various companies = (including my own) have just pcked
> > > > one and used it
> > > > >for their own purpose.  = Eventually this will create an
> > > > interop problem,
> > > > >but what else is a company = to do?
> > > > >
> > > > >Is there a way that we could = define that a certain TLV
> number is for
> > > > >private / proprietary / = experimental purposes?
> > > > >
> > > > >This would then stop people = just picking one.
> > > > >
> > > > >I am thinking that there = would have to be some sort of
> > > > entity identifier
> > > > >in there so that when you = see this TLV you know whether it
> > > > is yours or not.
> > > > >
> > > > >Maybe we could define that = the first four bytes are an IP
> > > > address for
> > > > >example.  Any entity = large enough to want to use a
> > > > proprietary TLV would
> > > > >have a public IP address to = put in there, I would have
> > > > thought. After the
> > > > >first for bytes then the = rest would be free.
> > > > >
> > > > >Or maybe there is a better = way to identify a particular
> > > > company / entity
> > > > >(like a MAC address)?  = Maybe ISO 8348?
> > > > >
> > > > >What do people think?
> > > > >
> > > > >Philip
> > > > >
> > > >
> > > > This has been suggested before, = but never came to anything. I
> > > > think if it
> > > > WERE to be done then using = something link the MAC OUI would
> > > > probably work.
> > > > What do you mean by ISO 8348? Do = you mean ISO 6523? I
> hope not :-)
> > > >
> > > = >          Mike
> > > >
> >
> > = _______________________________________________
> > Isis-wg mailing list  -  = Isis-wg@spider.juniper.net
> > http://spider.juniper.net/mailman/listinfo/isis-wg=
> >
>
>

------_=_NextPart_001_01C21088.155172F2-- From christi@nortelnetworks.com Wed Jun 12 13:33:43 2002 From: christi@nortelnetworks.com (Philip Christian) Date: Wed, 12 Jun 2002 13:33:43 +0100 Subject: [Isis-wg] Proprietary / Private TLV numbers? Message-ID: <4103264BC8D3D51180B7002048400C454FB710@zhard0jd.europe.nortel.com> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2120C.FEB807FA Content-Type: text/plain; charset="iso-8859-1" I have done an update, see below Philip > -----Original Message----- > From: mike shand [mailto:mshand@cisco.com] > Sent: Tuesday, June 11, 2002 3:56 PM > To: Christian, Philip [HAL02:GI50:EXCH] > Cc: 'Tony Przygienda'; isis-wg@spider.juniper.net; 'Mike Truskowski' > Subject: RE: [Isis-wg] Proprietary / Private TLV numbers? > > > At 15:38 11/06/2002 +0100, Philip Christian wrote: > >On receipt of an LSP a router MUST ignore TLVs of type XXX that > > include an OUI from a different organization, > > MUST is a bit strong here. SHOULD or MAY, perhaps. If you > know how to parse > company X's subTLVs you should be allowed to do so. > > I'm not sure we want to get into mentioning non-standard OUIs > with G or L > bits set. > > Mike > > Internet Engineering Task Force P. Christian INTERNET DRAFT Nortel Networks June 2002 TLV for Proprietary Use draft-ietf-isis-private-tlv-forlist2.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this draft is unlimited. 1. Abstract This document defines a TLV that may be used for vendor specific or experimental extensions to the IS-IS routing protocol, and defines the format of the TLV. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. TLV for Proprietary Use June 2002 3. Introduction IS-IS as defined in [1] has always been an extensible routing protocol. Extensions to IS-IS are encoded as a TLV. Critically [1] has always defined that an IS-IS router SHALL flood entire LSPs that it receives on to other IS-IS routers in the network, whether or not it understands the TLVs that are included in the LSP. Also IS-IS LSPs are structured such that a router can find TLVs that it understands, whilst ignoring ones that it does not. Thus information that is encoded into a TLV and placed into an LSP by a router will be propagated to every other router in an IS-IS level-1 area or level-2 subdomain. The basic function of an IS-IS TLV is identified by the first byte of the TLV. Thus there are only 256 possible basic types of TLV. Certain types of TLV have been defined to include sub-TLVs so that a single TLV type can be used for multiple functions. No single authority assigns TLV type numbers, [2] lists all known TLV type numbers at this time. Also no TLV type number was ever defined for private, proprietary or experimental use. The extensible nature of IS-IS has made the use of TLVs in LSPs for proprietary purposes so useful that in the absence of a central authority for assigning TLV type numbers vendors have occasionally simply chosen a number and hoped for the best. The risk is that such a TLV type number may then be chosen by another organization at a later time for a different function, thus creating an interoperability problem. Also this accelerates the burning of the 256 possible TLV type numbers. This document specifies a TLV type number that may be used for proprietary, private or experimental purposes, and a mechanism that insures that implementations from different sources can use the TLV for different purposes in the same network without creating interoperability problems. By using this new TLV, companies, individuals or institutions may use extensions to IS-IS without fear of interoperability problems with other organizations in the future, and the available pool of TLV type numbers will no longer be diminished by proprietary use. 4. TLV type number for proprietary use The type field for this TLV SHALL be XXX. TLVs that use XXX for the type field MUST include a valid IEEE assigned OUI as the first three bytes of the value field of the TLV. For more information about OUIs see [3]. TLV for Proprietary Use June 2002 On receipt of an LSP a router MAY ignore TLVs of type XXX that include an OUI from a different organization, however the router MUST flood the LSP onwards as per [1]. After the first three bytes of the value field subsequent bytes may be used freely for any purpose provided that the resultant TLV is conformant with [1]. Many organizations will have access to only one or a few OUIs. Implementers are free to format the value field after their OUI into sub-TLVs so that it may be used for multiple purposes, and would be well advised to do this from the outset. Note that if sub-TLVs are to be used then the very first implementation to exist will need to recognize the sub-TLV structure, and ignore sub-TLVs that it does not understand whilst searching for sub-TLVs that it does understand. 5. Security Considerations The proprietary TLV raises no new security issues for IS-IS. Information placed in an IS-IS TLV cannot be considered secure, and so if security is required then an implementation will need to encrypt the information using a suitable method. 6. References [1] ISO, "Intermediate system to Intermediate system routeing information exchange protocol for use in conjunction with the Protocol for providing the Connectionless-mode Network Service (ISO 8473)", ISO/IEC 10589:1992. [2] draft-ietf-isis-wg-tlv-codepoints-02.txt, Reserved TLV Codepoints in ISIS, Tony Przygienda, November 2001 [3] http://standards.ieee.org/regauth/oui/index.html 7. Acknowledgments The author takes no credit for this work as the concept was discussed in the IS-IS Working Group before the author even became an active participant. Suggestions for acknowledgement gladly received. 8. Author's Addresses Philip Christian Nortel Networks Harlow Laboratories London Road, Harlow, Essex, CM17 9NA UK Email: christi@nortelnetworks.com ------_=_NextPart_001_01C2120C.FEB807FA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Isis-wg] Proprietary / Private TLV numbers?

I have done an update, see below

Philip

> -----Original Message-----
> From: mike shand [mailto:mshand@cisco.com]
> Sent: Tuesday, June 11, 2002 3:56 PM
> To: Christian, Philip [HAL02:GI50:EXCH]
> Cc: 'Tony Przygienda'; = isis-wg@spider.juniper.net; 'Mike Truskowski'
> Subject: RE: [Isis-wg] Proprietary / Private = TLV numbers?
>
>
> At 15:38 11/06/2002 +0100, Philip Christian = wrote:
> >On receipt of an LSP a router MUST ignore = TLVs of type XXX that
> >    include an OUI from a = different organization,
>
> MUST is a bit strong here. SHOULD or MAY, = perhaps. If you
> know how to parse
> company X's subTLVs you should be allowed to do = so.
>
> I'm not sure we want to get into mentioning = non-standard OUIs
> with G or L
> bits set.
>
>          = Mike
>
>

Internet Engineering Task = Force           &= nbsp;           &= nbsp;    P. Christian
INTERNET = DRAFT           &= nbsp;           &= nbsp;           &= nbsp;      Nortel Networks
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;   June 2002
 
 
          &nb= sp;           &nb= sp;   TLV for Proprietary Use
          &nb= sp;          = draft-ietf-isis-private-tlv-forlist2.txt
 
Status of this Memo
 
   This document is an Internet-Draft and = is in full conformance with
   all provisions of Section 10 of RFC = 2026.
   
   Internet Drafts are working documents = of the Internet Engineering
   Task Force (IETF), its Areas, and its = Working Groups.  Note that
   other groups may also distribute = working documents as Internet
   Drafts.
   
   Internet Drafts are draft documents = valid for a maximum of six
   months.  Internet Drafts may be = updated, replaced, or obsoleted by
   other documents at any time.  It = is not appropriate to use Internet
   Drafts as reference material or to cite = them other than as a
   "working draft" or "work = in progress".
   
   The list of current Internet-Drafts can = be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt =
   
   The list of Internet-Draft Shadow = Directories can be accessed at
   http://www.ietf.org/shadow.html.
   
   This memo provides information for the = Internet community. This memo
   does not specify an Internet standard = of any kind. 
   
   Distribution of this draft is = unlimited.
   
   
1. Abstract
   
   This document defines a TLV that may be = used for vendor specific or
   experimental extensions to the IS-IS = routing protocol, and defines
   the format of the TLV.
   
   
2. Conventions used in this document
   
   The key words "MUST", = "MUST NOT", "REQUIRED", "SHALL", = "SHALL NOT",
   "SHOULD", "SHOULD = NOT", "RECOMMENDED",  "MAY", and = "OPTIONAL" in
   this document are to be interpreted as = described in RFC 2119.
   





 
          &nb= sp;            = TLV for Proprietary = Use           &nb= sp;   June 2002 
 
3. Introduction
   
   IS-IS as defined in [1] has always been = an extensible routing
   protocol.  Extensions to IS-IS are = encoded as a TLV.  Critically [1]
   has always defined that an IS-IS router = SHALL flood entire LSPs that
   it receives on to other IS-IS routers = in the network, whether or not
   it understands the TLVs that are = included in the LSP.  Also IS-IS
   LSPs are structured such that a router = can find TLVs that it
   understands, whilst ignoring ones that = it does not.
   
   Thus information that is encoded into a = TLV and placed into an LSP
   by a router will be propagated to every = other router in an IS-IS
   level-1 area or level-2 subdomain. =
   
   The basic function of an IS-IS TLV is = identified by the first byte
   of the TLV.  Thus there are only = 256 possible basic types of TLV. 
   Certain types of TLV have been defined = to include sub-TLVs so that a
   single TLV type can be used for = multiple functions.
   
   No single authority assigns TLV type = numbers, [2] lists all known
   TLV type numbers at this time.  = Also no TLV type number was ever
   defined for private, proprietary or = experimental use.
   
   The extensible nature of IS-IS has made = the use of TLVs in LSPs for
   proprietary purposes so useful that in = the absence of a central
   authority for assigning TLV type = numbers vendors have occasionally
   simply chosen a number and hoped for = the best.  The risk is that
   such a TLV type number may then be = chosen by another organization at
   a later time for a different function, = thus creating an
   interoperability problem. Also this = accelerates the burning of the
   256 possible TLV type numbers.
   
   This document specifies a TLV type = number that may be used for
   proprietary, private or experimental = purposes, and a mechanism that
   insures that implementations from = different sources can use the TLV
   for different purposes in the same = network without creating
   interoperability problems.
   
   By using this new TLV, companies, = individuals or institutions may
   use extensions to IS-IS without fear of = interoperability problems
   with other organizations in the future, = and the available pool of
   TLV type numbers will no longer be = diminished by proprietary use.
   
4. TLV type number for proprietary use
   
   The type field for this TLV SHALL be = XXX.
   
   TLVs that use XXX for the type field = MUST include a valid IEEE
   assigned OUI as the first three bytes = of the value field of the TLV. 
   For more information about OUIs see = [3].
   


 
          &nb= sp;            = TLV for Proprietary = Use           &nb= sp;   June 2002 
 
   On receipt of an LSP a router MAY = ignore TLVs of type XXX that
   include an OUI from a different = organization, however the router
   MUST flood the LSP onwards as per [1]. =
 
   After the first three bytes of the = value field subsequent bytes may
   be used freely for any purpose provided = that the resultant TLV is
   conformant with [1].
   
   Many organizations will have access to = only one or a few OUIs. 
   Implementers are free to format the = value field after their OUI into
   sub-TLVs so that it may be used for = multiple purposes, and would be
   well advised to do this from the = outset.  Note that if sub-TLVs are
   to be used then the very first = implementation to exist will need to
   recognize the sub-TLV structure, and = ignore sub-TLVs that it does
   not understand whilst searching for = sub-TLVs that it does
   understand.
   
5. Security Considerations
 
   The proprietary TLV raises no new = security issues for IS-IS. 
   Information placed in an IS-IS TLV = cannot be considered secure, and
   so if security is required then an = implementation will need to
   encrypt the information using a = suitable method.
   
6. References
   
   [1] ISO, "Intermediate system to = Intermediate system routeing
   information exchange protocol for use = in conjunction with the
   Protocol for providing the = Connectionless-mode Network Service (ISO
   8473)", ISO/IEC 10589:1992. =
   
   [2] = draft-ietf-isis-wg-tlv-codepoints-02.txt, Reserved TLV
   Codepoints in ISIS, Tony Przygienda, = November 2001
   
   [3] http://standards.ieee.org/regauth/oui/index.html =
   
7. Acknowledgments
   
   The author takes no credit for this = work as the concept was
   discussed in the IS-IS Working Group = before the author even became
   an active participant.  = Suggestions for acknowledgement gladly
   received.
   
8. Author's Addresses
   
   Philip Christian
   Nortel Networks Harlow Laboratories =
   London Road, Harlow,
   Essex, CM17 9NA UK
   
   Email: = christi@nortelnetworks.com

------_=_NextPart_001_01C2120C.FEB807FA-- From dgoodspe@excite.com Thu Jun 13 20:50:21 2002 From: dgoodspe@excite.com (Don Goodspeed) Date: Thu, 13 Jun 2002 15:50:21 -0400 (EDT) Subject: FW: [Isis-wg] I-D ACTION:draft-ietf-isis-interoperable-00.txt Message-ID: <20020613195021.6DFE43E0A@xmxpita.excite.com> 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" ? 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 ..." ? 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 --- On Tue 05/21, Jeff Parker wrote: From: Jeff Parker [mailto: jparker@axiowave.com] To: isis-wg@spider.juniper.net Date: Tue 05/21 Subject: FW: [Isis-wg] I-D ACTION:draft-ietf-isis-interoperable-00.txt > A small, but very active, subgroup of the WG has been > working on this document for the last month. We considered > a larger set of issues, and decided not to pursue some. > A brief description of those issues is included in the > attached document, remaining.dos. > > Suggestions and edits always welcome: we are still > actively revising the last section, on checking the > Source ID on point-to-point IIH packets. > > - jeff parker > > > 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 : Recommendations for Interoperable IP > > Networks using > > IS-IS > > Author(s) : J. Parker > > Filename : draft-ietf-isis-interoperable-00.txt > > Pages : 19 > > Date : 20-May-02 > > > > 'The difference between theory and practice is greater in > > practice than it is in theory.' (Author unknown) > > This document discusses a number of differences between the IS-IS > > protocol as described in ISO 10589 [1] and RFC 1195 [3] and the > > protocol as it is deployed today. These differences are discussed > as > > a service to those implementing, testing, and deploying the IS-IS > > Protocol to route IP traffic. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-isis-interoperable-00.txt > > > ------------------------------------------------ Join Excite! - http://www.excite.com The most personalized portal on the Web! From amir@cwnt.com Mon Jun 10 14:24:12 2002 From: amir@cwnt.com (Amir Hermelin) Date: Mon, 10 Jun 2002 16:24:12 +0300 Subject: FW: [Isis-wg] last call on draft draft-ietf-isis-ext-lsp-frags-00 ... Message-ID: Alex, once again, comments inline. I've cut out the parts that were in full agreement. Thanks for the comments. Amir. -- Amir Hermelin Charlotte's Web Networks Inc. > -----Original Message----- > From: Alex Zinin [mailto:zinin@psg.com] > Sent: Monday, June 03, 2002 10:18 PM > To: Amir Hermelin > Cc: isis-wg@juniper.net > Subject: Re: [Isis-wg] last call on draft > draft-ietf-isis-ext-lsp-frags-00 ... > > > Amir, > > >> > >> Couldn't find any info on how to put S' and S'' in the TLV. > >> > > > Actually, what you need to put here is S (or the is-alias-id, which > > could be different). The S' and S'' (and also S) appear in > the LSP header. > > I think I was confused by the illustration. Could you please > specify more > explicitly which ID is put in the TLV. > Right, I see where the stuff in parenthesis can confuse - removed that and added more explanation in the TLV section. > >> Couldn't find description of any sub-TLVs that would be > >> used to do the above. > > > It's just put there for future or proprietary use - doesn't take up > > any space, I think we should keep it. > > No objection to this, but you need to describe sub-TLV handling > properly. ok. > > >> > >> Couldn't find any rules about sub-TLV handling, i.e., padding > >> and length calculation with it. > >> > >> The format description above should use the illustration > >> style from 1195. > > > I don't fully understand what's missing, but I will add an example. > > I've used the format from the TE-extensions draft, which I > think to be > > clear and well-discussed. Please clarify what you'd like to > see here. > > I'd like the TLV format illustration to be consistent with > 1195, i.e., something like this: > > > x CODE - 24 > > x LENGTH - total length of the value field. > > x VALUE - the following data: > No. of Octets > +--------------------------------+ > | ALIAS SYSTEM ID | 7 > +--------------------------------+ > | SUB-TLV LENGTH | 1 > +--------------------------------+ > | | > . SUB-TLVs . > | | > +--------------------------------+ > agreed. > > >> What about the OL bit? > > > The 3.1.* sections are exceptions. The OL bit should be > set/unset in original and extended LSPs the same as before. > > Don't we want to have consistent values in the "normal" and "extended" > LSPs, at least for mode 2? > > >> > 3.2 Operation Mode 1 Additions > >> ... > >> > When an extended LSP belonging to extended system-id > S' is first > >> > created, the original LSP MUST specify S' as a neighbor, > >> with metric > >> > set to zero. This in order to satisfy the two-way > >> connectivity check > >> > on other routers, as well as to consider the cost of > reaching the > >> > >> I thought that the S'->S link would be needed to satisfy > >> the TWC check for the S->S' one, not the other way around... > >> > > > Depends on which node (S or S') was first considered in > SPF. In Mode 1, it's true > > that always S will be reached first, but this isn't > guaranteed in mode 2. > > Note the name of the section where this text belongs ;) it took me some time, but I finally got your point. Will move the sentence to describe the right direction. > >> We don't have to go through mode-1 to get to mode-2. An upgrade of > >> SW does not necessarily mean changing the LSP origination process. > >> In fact, I would argue that the default setting MUST be > the standard > >> one, i.e., neither mode 1 nor mode 2, and it would be really great > >> if this was spelled out. > >> > > > Your upgrade option is identical to what the draft suggests > - since "standard one" > > is really Mode 1 (you can either have mode-1 or mode-2). > The difference between mode-1 > > and the "standard" way, is that the standard way asserts > when the maximum fragments > > are reached ;-) There's also the additional tlv, but > there's no harm in advertising it. > > > I don't agree here. I think the most common case will be where the > network works and routers' SW gets upgraded. Once upgraded the LSP > origination behavior should not change, i.e., neither mode-1 nor > mode-2 should be activated until explicitly configured by the admin. > This should save from problems with implementations that for some > buggy reason react incorrectly to 0-cost links in non-pseudo LSPs, > or with implementations that implement your spec incorrectly, > as well as this is just a good general practice to not enable new > behavior by default, especially in routing protocols. > Ok, I can add the text to that. However, it's just a recommendation, since implementations can do whatever they want here - the default values are implementation specific. You're right in that I was referring more to the case where the network doesn't work well when the upgrade is done. > > Thanks. > > Alex > > > Thanks. From truskows@cisco.com Mon Jun 10 14:41:44 2002 From: truskows@cisco.com (Mike Truskowski) Date: Mon, 10 Jun 2002 06:41:44 -0700 (PDT) Subject: [Isis-wg] Proprietary / Private TLV numbers? In-Reply-To: <4.3.2.7.2.20020610140439.02656f28@jaws.cisco.com> from mike shand at Jun "10," 2002 "02:05:20" pm Message-ID: <200206101341.GAB17419@wells.cisco.com> Why not just do the following? +-------------------------------------------------+ | Type | Length | Value | +-------------------------------------------------+ | TLV # | Length | vendor code | "value" | +-------------------------------------------------+ Where the vendor code is a fixed 3-4 octets? I guess one could do this on their own... couldn't they? The major problem I see here is what Philip said he wanted to fix... If vendors are doing this already and this is trying to avoid interoperability problems... then it would seem reasonable that the carrier would go back and install new images or force the vendor to fix the embedded base.. but they won't do either.. thus leaving the problem to stumble over some day... Mike > At 13:43 10/06/2002 +0100, Philip Christian wrote: > > >I suppose that we could define different sub-TLVs, a sub-TLV if the > >identifier is an IPv4 address, a different sub-TLV if it is a MAC address, etc > > > >Then folks could use whichever mechanism they prefer, as long as it is a > >globally unique identifier. > > > >Or is that too complex? > > Yes! That's how NSAP addresses got to be so awful :-) > > Mike > > > > >Philip > > > > > -----Original Message----- > > > From: mike shand [mailto:mshand@cisco.com] > > > Sent: Monday, June 10, 2002 12:24 PM > > > To: Christian, Philip [HAL02:GI50:EXCH] > > > Cc: isis-wg@spider.juniper.net > > > Subject: Re: [Isis-wg] Proprietary / Private TLV numbers? > > > > > > > > > At 11:29 10/06/2002 +0100, Philip Christian wrote: > > > >Looking at draft-ietf-isis-wg-tlv-codepoints-02.txt I notice > > > that there is > > > >not really any mechanism for private or proprietary use of a TLV. > > > > > > > >Thus various companies (including my own) have just pcked > > > one and used it > > > >for their own purpose. Eventually this will create an > > > interop problem, > > > >but what else is a company to do? > > > > > > > >Is there a way that we could define that a certain TLV number is for > > > >private / proprietary / experimental purposes? > > > > > > > >This would then stop people just picking one. > > > > > > > >I am thinking that there would have to be some sort of > > > entity identifier > > > >in there so that when you see this TLV you know whether it > > > is yours or not. > > > > > > > >Maybe we could define that the first four bytes are an IP > > > address for > > > >example. Any entity large enough to want to use a > > > proprietary TLV would > > > >have a public IP address to put in there, I would have > > > thought. After the > > > >first for bytes then the rest would be free. > > > > > > > >Or maybe there is a better way to identify a particular > > > company / entity > > > >(like a MAC address)? Maybe ISO 8348? > > > > > > > >What do people think? > > > > > > > >Philip > > > > > > > > > > This has been suggested before, but never came to anything. I > > > think if it > > > WERE to be done then using something link the MAC OUI would > > > probably work. > > > What do you mean by ISO 8348? Do you mean ISO 6523? I hope not :-) > > > > > > Mike > > > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg > From jparker@axiowave.com Mon Jun 10 15:46:19 2002 From: jparker@axiowave.com (Jeff Parker) Date: Mon, 10 Jun 2002 10:46:19 -0400 Subject: [Isis-wg] Proprietary / Private TLV numbers? Message-ID: > >Then folks could use whichever mechanism they prefer, as > >long as it is a globally unique identifier. > > > >Or is that too complex? Per Mike's suggestion, an OUI is globally unique and very short. What's not to like? - jeff parker From jlearman@cisco.com Mon Jun 10 16:14:03 2002 From: jlearman@cisco.com (Jeff Learman) Date: Mon, 10 Jun 2002 11:14:03 -0400 Subject: [Isis-wg] Proprietary / Private TLV numbers? In-Reply-To: <4103264BC8D3D51180B7002048400C454FB704@zhard0jd.europe.nor tel.com> Message-ID: <4.3.2.7.2.20020610111305.01a34f30@dingdong.cisco.com> --=====================_10142854==_.ALT Content-Type: text/plain; charset="us-ascii" IP address assignments are not permanent like OUI assignments are. I realize the chance for collision is very low, though ;-) At 10:06 AM 6/10/2002, Philip Christian wrote: >A vendor code of 4 octets could be an IPv4 address. >Then no-one would have to assign them. The vendor just uses a global IPv4 address that he has. > >Even the smallest vendor can buy a /32 IP address for this purpose. > >That would work. > >Philip > >> -----Original Message----- >> From: Mike Truskowski [mailto:truskows@cisco.com] >> Sent: Monday, June 10, 2002 2:42 PM >> To: mshand@cisco.com >> Cc: Christian, Philip [HAL02:GI50:EXCH]; isis-wg@spider.juniper.net >> Subject: Re: [Isis-wg] Proprietary / Private TLV numbers? >> >> >> Why not just do the following? >> >> +-------------------------------------------------+ >> | Type | Length | Value | >> +-------------------------------------------------+ >> | TLV # | Length | vendor code | "value" | >> +-------------------------------------------------+ >> >> Where the vendor code is a fixed 3-4 octets? >> >> I guess one could do this on their own... couldn't they? >> >> The major problem I see here is what Philip said he wanted to fix... >> >> If vendors are doing this already and this is trying to avoid >> interoperability >> problems... then it would seem reasonable that the carrier >> would go back and >> install new images or force the vendor to fix the embedded >> base.. but they >> won't do either.. thus leaving the problem to stumble over some day... >> >> Mike >> >> > At 13:43 10/06/2002 +0100, Philip Christian wrote: >> > >> > >I suppose that we could define different sub-TLVs, a >> sub-TLV if the >> > >identifier is an IPv4 address, a different sub-TLV if it >> is a MAC address, etc >> > > >> > >Then folks could use whichever mechanism they prefer, as >> long as it is a >> > >globally unique identifier. >> > > >> > >Or is that too complex? >> > >> > Yes! That's how NSAP addresses got to be so awful :-) >> > >> > Mike >> > >> > >> > >> > >Philip >> > > >> > > > -----Original Message----- >> > > > From: mike shand >> [<mailto:mshand@cisco.com>mailto:mshand@cisco.com] >> > > > Sent: Monday, June 10, 2002 12:24 PM >> > > > To: Christian, Philip [HAL02:GI50:EXCH] >> > > > Cc: isis-wg@spider.juniper.net >> > > > Subject: Re: [Isis-wg] Proprietary / Private TLV numbers? >> > > > >> > > > >> > > > At 11:29 10/06/2002 +0100, Philip Christian wrote: >> > > > >Looking at draft-ietf-isis-wg-tlv-codepoints-02.txt I notice >> > > > that there is >> > > > >not really any mechanism for private or proprietary >> use of a TLV. >> > > > > >> > > > >Thus various companies (including my own) have just pcked >> > > > one and used it >> > > > >for their own purpose. Eventually this will create an >> > > > interop problem, >> > > > >but what else is a company to do? >> > > > > >> > > > >Is there a way that we could define that a certain TLV >> number is for >> > > > >private / proprietary / experimental purposes? >> > > > > >> > > > >This would then stop people just picking one. >> > > > > >> > > > >I am thinking that there would have to be some sort of >> > > > entity identifier >> > > > >in there so that when you see this TLV you know whether it >> > > > is yours or not. >> > > > > >> > > > >Maybe we could define that the first four bytes are an IP >> > > > address for >> > > > >example. Any entity large enough to want to use a >> > > > proprietary TLV would >> > > > >have a public IP address to put in there, I would have >> > > > thought. After the >> > > > >first for bytes then the rest would be free. >> > > > > >> > > > >Or maybe there is a better way to identify a particular >> > > > company / entity >> > > > >(like a MAC address)? Maybe ISO 8348? >> > > > > >> > > > >What do people think? >> > > > > >> > > > >Philip >> > > > > >> > > > >> > > > This has been suggested before, but never came to anything. I >> > > > think if it >> > > > WERE to be done then using something link the MAC OUI would >> > > > probably work. >> > > > What do you mean by ISO 8348? Do you mean ISO 6523? I >> hope not :-) >> > > > >> > > > Mike >> > > > >> > >> > _______________________________________________ >> > Isis-wg mailing list - Isis-wg@spider.juniper.net >> > http://spider.juniper.net/mailman/listinfo/isis-wg >> > >> >> --=====================_10142854==_.ALT Content-Type: text/html; charset="us-ascii"
IP address assignments are not permanent like OUI assignments are.
I realize the chance for collision is very low, though ;-)

At 10:06 AM 6/10/2002, Philip Christian wrote:

A vendor code of 4 octets could be an IPv4 address.
Then no-one would have to assign them. The vendor just uses a global IPv4 address that he has.

Even the smallest vendor can buy a /32 IP address for this purpose.

That would work.

Philip

> -----Original Message-----
> From: Mike Truskowski [mailto:truskows@cisco.com]
> Sent: Monday, June 10, 2002 2:42 PM
> To: mshand@cisco.com
> Cc: Christian, Philip [HAL02:GI50:EXCH]; isis-wg@spider.juniper.net
> Subject: Re: [Isis-wg] Proprietary / Private TLV numbers?
>
>
> Why not just do the following?
>
> +-------------------------------------------------+
> | Type   |  Length  |       Value                 |
> +-------------------------------------------------+
> | TLV #  |  Length  |  vendor code  |   "value"   |
> +-------------------------------------------------+
>
> Where the vendor code is a fixed 3-4 octets?
>
> I guess one could do this on their own... couldn't they?
>
> The major problem I see here is what Philip said he wanted to fix...
>
> If vendors are doing this already and this is trying to avoid
> interoperability
> problems... then it would seem reasonable that the carrier
> would go back and
> install new images or force the vendor to fix the embedded
> base..  but they
> won't do either.. thus leaving the problem to stumble over some day...
>
> Mike
>
> > At 13:43 10/06/2002 +0100, Philip Christian wrote:
> >
> > >I suppose that we could define different sub-TLVs, a
> sub-TLV if the
> > >identifier is an IPv4 address, a different sub-TLV if it
> is a MAC address, etc
> > >
> > >Then folks could use whichever mechanism they prefer, as
> long as it is a
> > >globally unique identifier.
> > >
> > >Or is that too complex?
> >
> > Yes! That's how NSAP addresses got to be so awful :-)
> >
> >          Mike
> >
> >
> >
> > >Philip
> > >
> > > > -----Original Message-----
> > > > From: mike shand
> [<mailto:mshand@cisco.com>mailto:mshand@cisco.com]
> > > > Sent: Monday, June 10, 2002 12:24 PM
> > > > To: Christian, Philip [HAL02:GI50:EXCH]
> > > > Cc: isis-wg@spider.juniper.net
> > > > Subject: Re: [Isis-wg] Proprietary / Private TLV numbers?
> > > >
> > > >
> > > > At 11:29 10/06/2002 +0100, Philip Christian wrote:
> > > > >Looking at draft-ietf-isis-wg-tlv-codepoints-02.txt I notice
> > > > that there is
> > > > >not really any mechanism for private or proprietary
> use of a TLV.
> > > > >
> > > > >Thus various companies (including my own) have just pcked
> > > > one and used it
> > > > >for their own purpose.  Eventually this will create an
> > > > interop problem,
> > > > >but what else is a company to do?
> > > > >
> > > > >Is there a way that we could define that a certain TLV
> number is for
> > > > >private / proprietary / experimental purposes?
> > > > >
> > > > >This would then stop people just picking one.
> > > > >
> > > > >I am thinking that there would have to be some sort of
> > > > entity identifier
> > > > >in there so that when you see this TLV you know whether it
> > > > is yours or not.
> > > > >
> > > > >Maybe we could define that the first four bytes are an IP
> > > > address for
> > > > >example.  Any entity large enough to want to use a
> > > > proprietary TLV would
> > > > >have a public IP address to put in there, I would have
> > > > thought. After the
> > > > >first for bytes then the rest would be free.
> > > > >
> > > > >Or maybe there is a better way to identify a particular
> > > > company / entity
> > > > >(like a MAC address)?  Maybe ISO 8348?
> > > > >
> > > > >What do people think?
> > > > >
> > > > >Philip
> > > > >
> > > >
> > > > This has been suggested before, but never came to anything. I
> > > > think if it
> > > > WERE to be done then using something link the MAC OUI would
> > > > probably work.
> > > > What do you mean by ISO 8348? Do you mean ISO 6523? I
> hope not :-)
> > > >
> > > >          Mike
> > > >
> >
> > _______________________________________________
> > Isis-wg mailing list  -  Isis-wg@spider.juniper.net
> > http://spider.juniper.net/mailman/listinfo/isis-wg
> >
>
>
--=====================_10142854==_.ALT-- From appallar" --=_MAILER_ATTACH_BOUNDARY1_200261601741571914544919 Content-Type: text/plain; charset=us-ascii Hi all, Are there any guidelines, about number of routers that can exist in an area in ISIS? Can any one tell me what could the maximum number of routers that can be present in an area, and maximum number of Areas that can exist in a Domain. Any Help regarding this is appretiated, Thanks in Advance, Suryanarayana Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from http://www.planetm.co.in --=_MAILER_ATTACH_BOUNDARY1_200261601741571914544919 Content-Type: text/html; charset=us-ascii

Hi all,

 Are there any guidelines, about number of routers that can exist in an area in ISIS?

Can any one tell me what could the maximum number of routers that can be present in an area, and maximum number of Areas that can exist in a Domain.

Any Help regarding this is appretiated,

 

Thanks in Advance,

Suryanarayana

 

Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com
Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from http://www.planetm.co.in --=_MAILER_ATTACH_BOUNDARY1_200261601741571914544919-- From jlearman@cisco.com Mon Jun 17 14:03:50 2002 From: jlearman@cisco.com (Jeff Learman) Date: Mon, 17 Jun 2002 09:03:50 -0400 Subject: [Isis-wg] number of routers in an area In-Reply-To: <200206161215.RAA32123@WS0005.indiatimes.com> Message-ID: <4.3.2.7.2.20020617090213.01aeda58@dingdong.cisco.com> --=====================_56413508==_.ALT Content-Type: text/plain; charset="us-ascii" The protocol does not impose any standards. This is a weakest-link situation; the router with the least memory or insufficient CPU power will dictate the limitation for that area or level 2 subdomain. Regards, Jeff At 08:11 AM 6/16/2002, appallar wrote: >Hi all, > > Are there any guidelines, about number of routers that can exist in an area in ISIS? > >Can any one tell me what could the maximum number of routers that can be present in an area, and maximum number of Areas that can exist in a Domain. > >Any Help regarding this is appretiated, > > > >Thanks in Advance, > >Suryanarayana > > > >---------- >Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com >Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from http://www.planetm.co.in --=====================_56413508==_.ALT Content-Type: text/html; charset="us-ascii"
The protocol does not impose any standards.  This is a weakest-link
situation; the router with the least memory or insufficient CPU
power will dictate the limitation for that area or level 2 subdomain.

Regards,
Jeff

At 08:11 AM 6/16/2002, appallar wrote:

Hi all,

 Are there any guidelines, about number of routers that can exist in an area in ISIS?

Can any one tell me what could the maximum number of routers that can be present in an area, and maximum number of Areas that can exist in a Domain.

Any Help regarding this is appretiated,

 

Thanks in Advance,

Suryanarayana

 
Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com
Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from http://www.planetm.co.in
--=====================_56413508==_.ALT-- From wongkent@hotmail.com Mon Jun 17 19:26:37 2002 From: wongkent@hotmail.com (Kent Wong) Date: Mon, 17 Jun 2002 18:26:37 +0000 Subject: [Isis-wg] testing, please ignore Message-ID: _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From prz@redback.com Mon Jun 17 16:06:14 2002 From: prz@redback.com (Tony Przygienda) Date: Mon, 17 Jun 2002 08:06:14 -0700 Subject: [Isis-wg] ISIS drafts status summary ... Message-ID: <3D0DFAE6.237BE9EC@redback.com> To keep tab on things and for Tony Ward's benefit status to things we are in. Alex, pls take according drafts that are to publication after last call forward (I will send another message to iesg secretary) 1. draft-ietf-isis-ext-lsp-frags-00 last call ended 5/22/02. I still see comments on the list. From that I deduct last call is going on 2. draft-ietf-isis-3way-06 passed last call as of 5/3/02. Alex took it to IESG. 3. draft draft-ietf-isis-wg-multi-topology-02 has been updated to -03, passed last call as of 3/19/02. Please move forward to publication 4. draft-ietf-isis-traffic-04.txt passed last call as of 02/04/02. Please move forward to publication and since last time 1. draft-ietf-isis-wg-tlv-codepoints-01.txt waiting for publication 2. draft-ietf-isis-ipv6-02.txt waiting for publication 3. draft-ietf-isis-hmac-03.txt waiting for publication 4. draft-ietf-isis-wg-snp-checksum-03.txt waiting for publication unduly yours -- tony From Alex Zinin Mon Jun 17 21:44:04 2002 From: Alex Zinin (Alex Zinin) Date: Mon, 17 Jun 2002 13:44:04 -0700 Subject: [Isis-wg] ISIS drafts status summary ... In-Reply-To: <3D0DFAE6.237BE9EC@redback.com> References: <3D0DFAE6.237BE9EC@redback.com> Message-ID: <18213216476.20020617134404@psg.com> Tony, Some comments on the draft status below, please. > To keep tab on things and for Tony Ward's benefit status to things we are in. Alex, pls take > according drafts that are > to publication after last call forward (I will send another message to iesg secretary) > 1. draft-ietf-isis-ext-lsp-frags-00 last call ended 5/22/02. I still see comments on the list. > From that I deduct last call is going on Amir and I exchanged a couple of messages off the list and I think the discussion converged. Unless there were more comments besides mine, I think we're expecting a new version. > 2. draft-ietf-isis-3way-06 passed last call as of 5/3/02. Alex took it to IESG. Approved by the IESG last Thursday. Should be going to the rfc-ed's queue now. > 3. draft draft-ietf-isis-wg-multi-topology-02 has been updated to -03, passed last call as of > 3/19/02. Please move forward to publication AD-review comments provided to the authors on 05/01/02. Last heard from them on 05/10/02. Expecting new version. > 4. draft-ietf-isis-traffic-04.txt passed last call as of 02/04/02. Please move forward to > publication AD-review comments provided for -04 on 05/01/02. Last heard from tli on 05/02/02. Expecting new version. > and since last time > 1. draft-ietf-isis-wg-tlv-codepoints-01.txt waiting for publication > 2. draft-ietf-isis-ipv6-02.txt waiting for publication AD comments provided; new version needed, waiting for the author. > 3. draft-ietf-isis-hmac-03.txt waiting for publication AD comments provided; new version needed, waiting for the authors. > 4. draft-ietf-isis-wg-snp-checksum-03.txt waiting for publication Alex From wongkent@hotmail.com Mon Jun 17 23:25:48 2002 From: wongkent@hotmail.com (Kent Wong) Date: Mon, 17 Jun 2002 22:25:48 +0000 Subject: [Isis-wg] draft-ietf-isis-restart-01.txt Message-ID: Hi, I have some questions and comments on the isis restart draft: 1. On Page 6 "....a router MAY transmit one or more normal IIHs (containing a restart option, but with RR and RA clear) after the initial RR/RA exchange, but before synchronization has been achieved, in order to extend the holding time of the neighbors adjacencies, beyond that indicated in the remaining time field of the neighbors IIH with the RA bit set." When a router does this, should it also extend T3 to be the new holding time? Otherwise, even though we extend nbr's holding time for the adjacency, T3 will still expire in a short time and LSP with OL bit set will be generated and the graceful restart will fail anyway. 2. Instead of sending normal IIH after initial RR/RA exchange, would it make more sense that if this is a planned restart, a normal IIH with a large holding time is sent before the router going down so that nbr will hold the adjacency until restarting router finishes the complete restart procedure. In that way, there is no need to send extra normal IIH after initial RR/RA exchange. 3. If T2 on both levels expires/cancelled, it means end of database resync and if T3 is still running, we should cancel T3 at this time. Is that correct? The draft did not say this explicitly. Thanks. Kent Wong _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx From jparker@axiowave.com Fri Jun 21 14:34:36 2002 From: jparker@axiowave.com (Jeff Parker) Date: Fri, 21 Jun 2002 09:34:36 -0400 Subject: [Isis-wg] FW: ISIS MIB update Message-ID: > From: Les Ginsberg [mailto:ginsberg@pluris.com] > Sent: Thursday, June 20, 2002 8:14 PM > Subject: RE: ISIS MIB update > > Table 10 which defined the alternative multicast addresses > for 802.5 was deleted as per TC1 (published in 1992). The > defect report which I have (hardcopy only unfortunately - > be happy to FAX to anybody who really wants it) discusses > the issue at some length, but concludes by saying that > various groups have reviewed the issues and agreed that > > "token ring ISs be required to use the proper multicast addresses" > > It then specified deletion of the related material from ISO 10589. > > Those who were involved at the time may remember more... > > Les Thanks, Les. I'll remove the associated knob from the MIB. One less thing to puzzle future generations. - jeff parker From wongkent@hotmail.com Mon Jun 17 20:10:41 2002 From: wongkent@hotmail.com (Kent Wong) Date: Mon, 17 Jun 2002 19:10:41 +0000 Subject: [Isis-wg] draft-ietf-isis-restart-01.txt Message-ID: Hi, I have some questions and comments on the isis restart draft: 1. On Page 6 "....a router MAY transmit one or more normal IIHs (containing a restart option, but with RR and RA clear) after the initial RR/RA exchange, but before synchronization has been achieved, in order to extend the holding time of the neighbors adjacencies, beyond that indicated in the remaining time field of the neighbors IIH with the RA bit set." When a router does this, should it also extend T3 to be the new holding time? Otherwise, even though we extend nbr's holding time for the adjacency, T3 will still expire in a short time and LSP with OL bit set will be generated and the graceful restart will fail anyway. 2. Instead of sending normal IIH after initial RR/RA exchange, would it make more sense that if this is a planned restart, a normal IIH with a large holding time is sent before the router going down so that nbr will hold the adjacency until restarting router finishes the complete restart procedure. In that way, there is no need to send extra normal IIH after initial RR/RA exchange. 3. If T2 on both levels expires/cancelled, it means end of database resync and if T3 is still running, we should cancel T3 at this time. Is that correct? The draft did not say this explicitly. 4. Along the same line of thought, there is no need for a separate T2 and T3. Because when T2 expires/cancels before T3, T3 should be cancelled anyway. The only case T3 is supposed to be useful is when T3 expires before T2. The draft states that "If the timer T3 expires before all the T2 timers have expired, this indicates that the synchronization process is taking longer than minimum holding time of the neighbors. The router's own LSP(s) for levels which have not yet completed their first SPF computation are then flooded with the overload bit set to indicate that the router's LSPDB is not yet synchronized (and other routers should therefore not compute routes through this router)." However this assumes that the restarting router has acquired its own pre-start LSP before T3 expires. What if T3 expires even before it acquires its pre-start LSP? In that case, it doesn't know what sequence number it should use in its zero LSP to set the OL bit. If the seq num it uses is smaller than the seq num in its nbr's DB, then the zero LSP will be ignored by nbr anyway. So why not just combine T2 and T3 into a single timer and set the timer to be the min. remaining holding time of its nbr. If the timer expires before it DB re-sync, then graceful restart fails and everything reverts back to normal. Isn't this much more simpler and effective? 5. On section 4.3.1.1, the draft mentions the behavior of a router when it starts for the first time. Does it mean this draft intends to change the normal ISIS behavior even though it is not a restart? That means we need to start T2 (but no T1, T3) for each level even we start for the first time. However, it may not be desirable to set the OL bit every time ISIS comes up. This should be decided by the network admin on individual cases whether to set the OL bit or not. 6. Just for clarification, in the draft, it mentions "own" LSP many times, sometimes it mention own non-pseudonode LSP, sometimes it mention own LSP including pseudonode. Sometimes, it simply mention "own" LSP. Should we interpret the "own" LSP as including pseudonode LSP if it doesn't specify otherwise? Thanks! ---Kent Wong _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From slattanze@allegronetworks.com Mon Jun 17 19:39:39 2002 From: slattanze@allegronetworks.com (Sharon Lattanze) Date: Mon, 17 Jun 2002 14:39:39 -0400 Subject: [Isis-wg] unsubscribe Message-ID: <0850602E0461D511B54B00E0B1041F55391DBB@poker.allegronetworks.com> Unsubscribe slattanze@allegronetworks.com From prz@redback.com Mon Jun 24 04:53:03 2002 From: prz@redback.com (Tony Przygienda) Date: Sun, 23 Jun 2002 20:53:03 -0700 Subject: [Isis-wg] summer cleaning done ... Message-ID: <3D16979F.9A143203@redback.com> Manoj was kind enough to nuke all the spam that was clogging mailman and restart it to alleviate complaints we had about excessive delays on the list. We'll observe it over next couple of days ... Again, without subscription, there is little chance your mail will make it here or even be looked at. Spammer script kiddies are just too powerfull thanks -- tony From truskows@cisco.com Mon Jun 24 14:40:01 2002 From: truskows@cisco.com (Mike Truskowski) Date: Mon, 24 Jun 2002 06:40:01 -0700 (PDT) Subject: [Isis-wg] Message from the ITU In-Reply-To: from Tony Li at May "17," 2002 "00:04:43" am Message-ID: <200206241340.GAA16171@wells.cisco.com> Unfortunately, this is a great opportunity to see the problems we face in having different standards bodies which must work together or face responding to each others variations of the original document.. And I know the other side... like: 1. Let the market decide 2. There's only a few major suppliers of IP so they'll build what they want... the list of comments goes on... Recently, the one SG in the ITU indicated a need to re-architect MPLS. When will they see a need to re-architect IP? It is my opinion that this group is now taking authority of ISIS. Therefore it is important that whatever you do with the document and whichever body it is forwarded to .. it must be on a standards track so as to be referencable in other standard bodies. If you want to display it as a Standards track RFC while it is being accepted in ISO. Then do it. I support this. Mike > > > > An out of the box alternative is for the IS-IS WG to simply be > 'rude' and put its documents on the standards track. > > Any objections? > > Tony > > > > | -----Original Message----- > | From: Les Ginsberg [mailto:ginsberg@pluris.com] > | Sent: Thursday, May 16, 2002 6:35 PM > | To: 'RJ Atkinson'; jonathan.sadler@tellabs.com > | Cc: isis-wg@spider.juniper.net > | Subject: RE: [Isis-wg] Message from the ITU > | > | > | Having worked on the ISO 10589:2001 draft within ISO, I > | would be very > | surprised to learn that ANSI thinks it owns the IS-IS > | spec. As far as I > | know it is owned by JTC1/SC6/WG7. > | > | More importantly, your mail states that the reason IS-IS WG > | drafts are on > | the Informational track is because the IETF does not own the IS-IS > | specification and therefore does not feel it in its purview > | to define > | extensions to the protocol which are "standards". If true, > | this would > | suggest that it is necessary that either: > | > | a)ISO have procedures to incorporate IS-IS WG RFCs into ISO > | documents > | b)IETF be empowered to issue IS-IS extensions which are standards > | c)IETF take ownership of the IS-IS standard > | > | Having spoken to both IETF and ISO leadership on this > | issue, I have no > | reason to think that any solution to this impasse > | acceptable to both sides > | has been offered. > | > | Given that we have even more compelling reasons now to want > | to fix this, I > | would hope that leadership on "all sides of the aisle" > | would find a way to > | make Ran's fantasy come true. > | > | Les > | > | > | > > | > > | > On Thursday, May 16, 2002, at 07:01 , Jonathan Sadler wrote: > | > > This is why I wish that the IS-IS working group could have > | > its drafts > | > > achive Standards track. Then they would be available > | as normative > | > > references to other bodies, such as the ITU. > | > > > | > > Unfortunately, as I understand it, the IETF is > | sensative to JTC1's > | > > "ownership" of IS-IS and therefore the RFCs are limited to > | > Informational > | > > status at best. > | > > | > IETF has asked (formally) ANSI, who apparently really are the > | > standards > | > body for IS-IS under ISO (ANSI rather than JTC1) about > | handing over > | > change control > | > to IETF. Anecdotal (i.e. unconfirmed, possibly wrong) > | reports that I > | > hear are > | > that ANSI either didn't respond or said "no we don't want > | to do that". > | > > | > IETF is not publishing IS-IS stuff as standards-track because > | > change-control hasn't been handed over to IETF from ANSI. > | > > | > Consequently, I find this whole thread a bit confusing. > | > Perhaps others > | > also do. > | > > | > A fantasy that occurs to me right now would be to get the > | IETF IS-IS > | > chairs, the applicable ANSI folks, the applicable JTC1 folks, and > | > the applicable ITU-T folks all in the same room -- with a goal of > | > trying to find some more productive process and path forwards > | > for all of us. > | > > | > Ran > | > rja@extremenetworks.com > | > > | > _______________________________________________ > | > Isis-wg mailing list - Isis-wg@spider.juniper.net > | > http://spider.juniper.net/mailman/listinfo/isis-wg > | > > | _______________________________________________ > | Isis-wg mailing list - Isis-wg@spider.juniper.net > | http://spider.juniper.net/mailman/listinfo/isis-wg > | _______________________________________________ > | Isis-wg-external mailing list > | Isis-wg-external@mailist.procket.com > | http://mailist.procket.com/mailman/listinfo/isis-wg-external > | > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg > From jharper@cisco.com Mon Jun 24 16:24:34 2002 From: jharper@cisco.com (John Harper) Date: Mon, 24 Jun 2002 08:24:34 -0700 Subject: [Isis-wg] Message from the ITU In-Reply-To: <200206241340.GAA16171@wells.cisco.com> References: Message-ID: <4.3.2.7.2.20020624082423.0a969f08@jaws.cisco.com> FWIW I agree 100% with Tony L. John At 06:40 24/06/2002 -0700, Mike Truskowski wrote: >Unfortunately, this is a great opportunity to see the problems we >face in having different standards bodies which must work together >or face responding to each others variations of the original >document.. > >And I know the other side... like: >1. Let the market decide >2. There's only a few major suppliers of IP so they'll build what >they want... >the list of comments goes on... > >Recently, the one SG in the ITU indicated a need to re-architect >MPLS. When will they see a need to re-architect IP? > >It is my opinion that this group is now taking authority of ISIS. >Therefore it is important that whatever you do with the document >and whichever body it is forwarded to .. it must be on a standards >track so as to be referencable in other standard bodies. > >If you want to display it as a Standards track RFC while it is being >accepted in ISO. Then do it. I support this. > >Mike > > > > > > > > > > An out of the box alternative is for the IS-IS WG to simply be > > 'rude' and put its documents on the standards track. > > > > Any objections? > > > > Tony > > > > > > > > | -----Original Message----- > > | From: Les Ginsberg [mailto:ginsberg@pluris.com] > > | Sent: Thursday, May 16, 2002 6:35 PM > > | To: 'RJ Atkinson'; jonathan.sadler@tellabs.com > > | Cc: isis-wg@spider.juniper.net > > | Subject: RE: [Isis-wg] Message from the ITU > > | > > | > > | Having worked on the ISO 10589:2001 draft within ISO, I > > | would be very > > | surprised to learn that ANSI thinks it owns the IS-IS > > | spec. As far as I > > | know it is owned by JTC1/SC6/WG7. > > | > > | More importantly, your mail states that the reason IS-IS WG > > | drafts are on > > | the Informational track is because the IETF does not own the IS-IS > > | specification and therefore does not feel it in its purview > > | to define > > | extensions to the protocol which are "standards". If true, > > | this would > > | suggest that it is necessary that either: > > | > > | a)ISO have procedures to incorporate IS-IS WG RFCs into ISO > > | documents > > | b)IETF be empowered to issue IS-IS extensions which are standards > > | c)IETF take ownership of the IS-IS standard > > | > > | Having spoken to both IETF and ISO leadership on this > > | issue, I have no > > | reason to think that any solution to this impasse > > | acceptable to both sides > > | has been offered. > > | > > | Given that we have even more compelling reasons now to want > > | to fix this, I > > | would hope that leadership on "all sides of the aisle" > > | would find a way to > > | make Ran's fantasy come true. > > | > > | Les > > | > > | > > | > > > | > > > | > On Thursday, May 16, 2002, at 07:01 , Jonathan Sadler wrote: > > | > > This is why I wish that the IS-IS working group could have > > | > its drafts > > | > > achive Standards track. Then they would be available > > | as normative > > | > > references to other bodies, such as the ITU. > > | > > > > | > > Unfortunately, as I understand it, the IETF is > > | sensative to JTC1's > > | > > "ownership" of IS-IS and therefore the RFCs are limited to > > | > Informational > > | > > status at best. > > | > > > | > IETF has asked (formally) ANSI, who apparently really are the > > | > standards > > | > body for IS-IS under ISO (ANSI rather than JTC1) about > > | handing over > > | > change control > > | > to IETF. Anecdotal (i.e. unconfirmed, possibly wrong) > > | reports that I > > | > hear are > > | > that ANSI either didn't respond or said "no we don't want > > | to do that". > > | > > > | > IETF is not publishing IS-IS stuff as standards-track because > > | > change-control hasn't been handed over to IETF from ANSI. > > | > > > | > Consequently, I find this whole thread a bit confusing. > > | > Perhaps others > > | > also do. > > | > > > | > A fantasy that occurs to me right now would be to get the > > | IETF IS-IS > > | > chairs, the applicable ANSI folks, the applicable JTC1 folks, and > > | > the applicable ITU-T folks all in the same room -- with a goal of > > | > trying to find some more productive process and path forwards > > | > for all of us. > > | > > > | > Ran > > | > rja@extremenetworks.com > > | > > > | > _______________________________________________ > > | > Isis-wg mailing list - Isis-wg@spider.juniper.net > > | > http://spider.juniper.net/mailman/listinfo/isis-wg > > | > > > | _______________________________________________ > > | Isis-wg mailing list - Isis-wg@spider.juniper.net > > | http://spider.juniper.net/mailman/listinfo/isis-wg > > | _______________________________________________ > > | Isis-wg-external mailing list > > | Isis-wg-external@mailist.procket.com > > | http://mailist.procket.com/mailman/listinfo/isis-wg-external > > | > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@spider.juniper.net > > http://spider.juniper.net/mailman/listinfo/isis-wg > > > >_______________________________________________ >Isis-wg mailing list - Isis-wg@spider.juniper.net >http://spider.juniper.net/mailman/listinfo/isis-wg From sboddapa@hotmail.com Wed Jun 26 21:11:31 2002 From: sboddapa@hotmail.com (Suresh Boddapati) Date: Wed, 26 Jun 2002 20:11:31 +0000 Subject: [Isis-wg] 3 Way Handshake Message-ID: I have a question regarding the 3 way handshake draft (I guess now it is in limbo land where it is waiting to become an informational RFC). The state machine indicates that if the existing 3 way adjacency state is UP and we receive a 3 way adjacency state of DOWN, the action should be INIT. This does not seem right. The fact that you had a 3 way state that was up and now the nbr says it is down, shouldnt we restart the adjacency? This may be one way of the nbr wanting to restart the adjacency. I think the state should be DOWN and not INIT. Same thing applies in the case where you receive a ptop IIH with the 3 way state TLV being absent. The draft says "A received ptop IIH PDU may or may not contain the PTOP 3 way adj option. If it does not, the link is assumed to be functional in both directions....". If you already had a 3 way nbr state of UP and let's say the IS got switched with another IS that does not support 3 way TLV, going by the draft, we will not detect the change in the system. We will continue to keep the adjacency when in fact we should restart it. Comments? Suresh _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. From Ming.Chan@SpirentCom.COM Fri Jun 28 19:08:55 2002 From: Ming.Chan@SpirentCom.COM (Chan, Chung Ming) Date: Fri, 28 Jun 2002 08:08:55 -1000 Subject: [Isis-wg] Inclusion of zero Length VLF Message-ID: <8AC36D3167EED41184C800508BD9540502DD6B64@apollo.adtech-inc.com> Hi, I just observed from one of the routers in our lab include VLF which has zero length in its PDU. For example, in the IIH, it contains an IS Neighbor VLF with no MAC address in it. It looks to me that it won't do any harm, it will be ignored anyway by the receiving router; But it is meaningless to include something like that also. Is this one of the common ways of encoding a PDU? Thanks, C. Ming Chan From mshand@cisco.com Mon Jun 24 09:25:02 2002 From: mshand@cisco.com (mike shand) Date: Mon, 24 Jun 2002 09:25:02 +0100 Subject: [Isis-wg] draft-ietf-isis-restart-01.txt In-Reply-To: Message-ID: <4.3.2.7.2.20020624091932.042cbef0@jaws.cisco.com> I think I've answered most of this already, but with the recent problems on the list I'm not sure what has got through. So, here goes again. Mike At 19:10 17/06/2002 +0000, Kent Wong wrote: >Hi, > >I have some questions and comments on the isis restart draft: > >1. On Page 6 >"....a router MAY transmit one or more normal IIHs >(containing a restart option, but with RR and RA clear) after the >initial RR/RA exchange, but before synchronization has been >achieved, in order to extend the holding time of the neighbors >adjacencies, beyond that indicated in the remaining time field of >the neighbors IIH with the RA bit set." > >When a router does this, should it also extend T3 to be the new >holding time? Yes. > Otherwise, even though we extend nbr's holding time >for the adjacency, T3 will still expire in a short time and LSP >with OL bit set will be generated and the graceful restart will >fail anyway. > >2. Instead of sending normal IIH after initial RR/RA exchange, >would it make more sense that if this is a planned restart, >a normal IIH with a large holding time is sent before the router >going down so that nbr will hold the adjacency until restarting >router finishes the complete restart procedure. In that way, there >is no need to send extra normal IIH after initial RR/RA exchange. You could do that. >3. If T2 on both levels expires/cancelled, it means end of >database resync and if T3 is still running, we should cancel >T3 at this time. Is that correct? The draft did not say this explicitly. Yes. >4. Along the same line of thought, there is no need for a separate >T2 and T3. Because when T2 expires/cancels before T3, T3 should be >cancelled anyway. The only case T3 is supposed to be useful is >when T3 expires before T2. The draft states that > >"If the timer T3 expires before all the T2 timers have expired, this >indicates that the synchronization process is taking longer than >minimum holding time of the neighbors. The router's own LSP(s) for >levels which have not yet completed their first SPF computation are >then flooded with the overload bit set to indicate that the router's >LSPDB is not yet synchronized (and other routers should therefore >not compute routes through this router)." > >However this assumes that the restarting router has acquired its >own pre-start LSP before T3 expires. What if T3 expires even before >it acquires its pre-start LSP? In that case, it doesn't know what >sequence number it should use in its zero LSP to set the OL bit. >If the seq num it uses is smaller than the seq num in its nbr's DB, >then the zero LSP will be ignored by nbr anyway. No. It starts with a seq no. of 1, but thisn will cause any neighbors with a higher seq number to send back that higher seq number, then the originator will "trump" it with a yet higher seq number. Normal update process operation. >So why not just combine T2 and T3 into a single timer and set the >timer to be the min. remaining holding time of its nbr. If the timer >expires before it DB re-sync, then graceful restart fails >and everything reverts back to normal. Isn't this much more simpler >and effective? You COULD implement it that way. It makes no difference to the semantics of the timers. >5. On section 4.3.1.1, the draft mentions the behavior of a router >when it starts for the first time. Does it mean this draft intends to >change the normal ISIS behavior even though it is not a restart? Yes. >That means we need to start T2 (but no T1, T3) for each level even >we start for the first time. However, it may not be desirable to set >the OL bit every time ISIS comes up. This should be decided by the >network admin on individual cases whether to set the OL bit or not. Also need T1. >6. Just for clarification, in the draft, it mentions "own" LSP >many times, sometimes it mention own non-pseudonode LSP, sometimes >it mention own LSP including pseudonode. Sometimes, it simply >mention "own" LSP. Should we interpret the "own" LSP as including >pseudonode LSP if it doesn't specify otherwise? Yes, hopefully. >Thanks! > >---Kent Wong > > > >_________________________________________________________________ >Chat with friends online, try MSN Messenger: http://messenger.msn.com > >_______________________________________________ >Isis-wg mailing list - Isis-wg@spider.juniper.net >http://spider.juniper.net/mailman/listinfo/isis-wg From slattanze@allegronetworks.com Mon Jun 17 19:39:39 2002 From: slattanze@allegronetworks.com (Sharon Lattanze) Date: Mon, 17 Jun 2002 14:39:39 -0400 Subject: [Isis-wg] unsubscribe Message-ID: <0850602E0461D511B54B00E0B1041F55391DBB@poker.allegronetworks.com> Unsubscribe slattanze@allegronetworks.com From slattanze@allegronetworks.com Mon Jun 17 19:39:39 2002 From: slattanze@allegronetworks.com (Sharon Lattanze) Date: Mon, 17 Jun 2002 14:39:39 -0400 Subject: [Isis-wg] unsubscribe Message-ID: <0850602E0461D511B54B00E0B1041F55391DBB@poker.allegronetworks.com> Unsubscribe slattanze@allegronetworks.com From slattanze@allegronetworks.com Mon Jun 17 19:39:39 2002 From: slattanze@allegronetworks.com (Sharon Lattanze) Date: Mon, 17 Jun 2002 14:39:39 -0400 Subject: [Isis-wg] unsubscribe Message-ID: <0850602E0461D511B54B00E0B1041F55391DBB@poker.allegronetworks.com> Unsubscribe slattanze@allegronetworks.com From slattanze@allegronetworks.com Mon Jun 17 19:39:39 2002 From: slattanze@allegronetworks.com (Sharon Lattanze) Date: Mon, 17 Jun 2002 14:39:39 -0400 Subject: [Isis-wg] unsubscribe Message-ID: <0850602E0461D511B54B00E0B1041F55391DBB@poker.allegronetworks.com> Unsubscribe slattanze@allegronetworks.com From slattanze@allegronetworks.com Mon Jun 17 19:39:39 2002 From: slattanze@allegronetworks.com (Sharon Lattanze) Date: Mon, 17 Jun 2002 14:39:39 -0400 Subject: [Isis-wg] unsubscribe Message-ID: <0850602E0461D511B54B00E0B1041F55391DBB@poker.allegronetworks.com> Unsubscribe slattanze@allegronetworks.com From slattanze@allegronetworks.com Mon Jun 17 19:39:39 2002 From: slattanze@allegronetworks.com (Sharon Lattanze) Date: Mon, 17 Jun 2002 14:39:39 -0400 Subject: [Isis-wg] unsubscribe Message-ID: <0850602E0461D511B54B00E0B1041F55391DBB@poker.allegronetworks.com> Unsubscribe slattanze@allegronetworks.com From slattanze@allegronetworks.com Mon Jun 17 19:39:39 2002 From: slattanze@allegronetworks.com (Sharon Lattanze) Date: Mon, 17 Jun 2002 14:39:39 -0400 Subject: [Isis-wg] unsubscribe Message-ID: <0850602E0461D511B54B00E0B1041F55391DBB@poker.allegronetworks.com> Unsubscribe slattanze@allegronetworks.com From slattanze@allegronetworks.com Mon Jun 17 19:39:39 2002 From: slattanze@allegronetworks.com (Sharon Lattanze) Date: Mon, 17 Jun 2002 14:39:39 -0400 Subject: [Isis-wg] unsubscribe Message-ID: <0850602E0461D511B54B00E0B1041F55391DBB@poker.allegronetworks.com> Unsubscribe slattanze@allegronetworks.com From slattanze@allegronetworks.com Mon Jun 17 19:39:39 2002 From: slattanze@allegronetworks.com (Sharon Lattanze) Date: Mon, 17 Jun 2002 14:39:39 -0400 Subject: [Isis-wg] unsubscribe Message-ID: <0850602E0461D511B54B00E0B1041F55391DBB@poker.allegronetworks.com> Unsubscribe slattanze@allegronetworks.com From slattanze@allegronetworks.com Mon Jun 17 19:39:39 2002 From: slattanze@allegronetworks.com (Sharon Lattanze) Date: Mon, 17 Jun 2002 14:39:39 -0400 Subject: [Isis-wg] unsubscribe Message-ID: <0850602E0461D511B54B00E0B1041F55391DBB@poker.allegronetworks.com> Unsubscribe slattanze@allegronetworks.com From slattanze@allegronetworks.com Mon Jun 17 19:39:39 2002 From: slattanze@allegronetworks.com (Sharon Lattanze) Date: Mon, 17 Jun 2002 14:39:39 -0400 Subject: [Isis-wg] unsubscribe Message-ID: <0850602E0461D511B54B00E0B1041F55391DBB@poker.allegronetworks.com> Unsubscribe slattanze@allegronetworks.com From slattanze@allegronetworks.com Mon Jun 17 19:39:39 2002 From: slattanze@allegronetworks.com (Sharon Lattanze) Date: Mon, 17 Jun 2002 14:39:39 -0400 Subject: [Isis-wg] unsubscribe Message-ID: <0850602E0461D511B54B00E0B1041F55391DBB@poker.allegronetworks.com> Unsubscribe slattanze@allegronetworks.com From slattanze@allegronetworks.com Mon Jun 17 19:39:39 2002 From: slattanze@allegronetworks.com (Sharon Lattanze) Date: Mon, 17 Jun 2002 14:39:39 -0400 Subject: [Isis-wg] unsubscribe Message-ID: <0850602E0461D511B54B00E0B1041F55391DBB@poker.allegronetworks.com> Unsubscribe slattanze@allegronetworks.com From slattanze@allegronetworks.com Mon Jun 17 19:39:39 2002 From: slattanze@allegronetworks.com (Sharon Lattanze) Date: Mon, 17 Jun 2002 14:39:39 -0400 Subject: [Isis-wg] unsubscribe Message-ID: <0850602E0461D511B54B00E0B1041F55391DBB@poker.allegronetworks.com> Unsubscribe slattanze@allegronetworks.com From slattanze@allegronetworks.com Mon Jun 17 19:39:39 2002 From: slattanze@allegronetworks.com (Sharon Lattanze) Date: Mon, 17 Jun 2002 14:39:39 -0400 Subject: [Isis-wg] unsubscribe Message-ID: <0850602E0461D511B54B00E0B1041F55391DBB@poker.allegronetworks.com> Unsubscribe slattanze@allegronetworks.com From slattanze@allegronetworks.com Mon Jun 17 19:39:39 2002 From: slattanze@allegronetworks.com (Sharon Lattanze) Date: Mon, 17 Jun 2002 14:39:39 -0400 Subject: [Isis-wg] unsubscribe Message-ID: <0850602E0461D511B54B00E0B1041F55391DBB@poker.allegronetworks.com> Unsubscribe slattanze@allegronetworks.com From slattanze@allegronetworks.com Mon Jun 17 19:39:39 2002 From: slattanze@allegronetworks.com (Sharon Lattanze) Date: Mon, 17 Jun 2002 14:39:39 -0400 Subject: [Isis-wg] unsubscribe Message-ID: <0850602E0461D511B54B00E0B1041F55391DBB@poker.allegronetworks.com> Unsubscribe slattanze@allegronetworks.com From wongkent@hotmail.com Mon Jun 17 23:47:55 2002 From: wongkent@hotmail.com (Kent Wong) Date: Mon, 17 Jun 2002 22:47:55 +0000 Subject: [Isis-wg] draft-ietf-isis-restart-01.txt [continued] Message-ID: Hi, Some more questions and comments: 4. I don't understand why there is a need for two different timers T2 and T3. Because when T2 expires/cancels before T3, T3 should be cancelled anyway. The only case T3 is supposed to be useful is when T3 expires before T2. The draft states that "If the timer T3 expires before all the T2 timers have expired, this indicates that the synchronization process is taking longer than minimum holding time of the neighbors. The router's own LSP(s) for levels which have not yet completed their first SPF computation are then flooded with the overload bit set to indicate that the router's LSPDB is not yet synchronized (and other routers should therefore not compute routes through this router)." However this assumes that the restarting router has acquired its own pre-start LSP before T3 expires. What if T3 expires even before it acquires its pre-start LSP? In that case, it doesn't know what sequence number it should use in its zero LSP to set the OL bit. If the seq num it uses is smaller than the seq num in its nbr's DB, then the zero LSP will be ignored by nbr anyway. So why not just combine T2 and T3 into a single timer and set the timer to be the min. remaining holding time of its nbr. If the timer expires before it DB re-sync, then graceful restart fails and everything reverts back to normal. Isn't this much more simpler and effective? 5. On section 4.3.1.1, the draft mentions the behavior of a router when it starts for the first time. Does it mean this draft intends to change the normal ISIS behavior even though it is not a restart? That means we need to start T2 (but no T1, T3) for each level even we start for the first time. However, it may not be desirable to set the OL bit every time ISIS comes up. This should be decided by the network admin on individual cases whether to set the OL bit or not. 6. Just for clarification, in the draft, it mentions "own" LSP many times, sometimes it mention own non-pseudonode LSP, sometimes it mention own LSP including pseudonode. Sometimes, it simply mention "own" LSP. Should we interpret the "own" LSP as including pseudonode LSP if it doesn't specify otherwise? Thanks! Kent Wong _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From prz@net4u.ch Mon Jun 10 17:43:45 2002 From: prz@net4u.ch (Tony Przygienda) Date: Mon, 10 Jun 2002 09:43:45 -0700 Subject: [Isis-wg] Proprietary / Private TLV numbers? References: <4103264BC8D3D51180B7002048400C454FB704@zhard0jd.europe.nortel.com> Message-ID: <3D04D741.5010700@net4u.ch> Yes, the proposals have been made before and nohting has been written down. I am for using the official OUI, this would be aligned with Frame Relay, ATM and so on. The /32 may fly but unfortunately IP address space is a volatile thing compared to OUIs. I assume any vendor building sophisticated networking gear with ISIS on it will at a certain point have an OUI, I see little value in having a /32-address-based-cottage-industry-of-ISIS-extensions ... So, this time any takers to write it down ? thanks -- tony Philip Christian wrote: > A vendor code of 4 octets could be an IPv4 address. > Then no-one would have to assign them. The vendor just uses a global > IPv4 address that he has. > > Even the smallest vendor can buy a /32 IP address for this purpose. > > That would work. > > Philip > > > -----Original Message----- > > From: Mike Truskowski [ mailto:truskows@cisco.com ] > > Sent: Monday, June 10, 2002 2:42 PM > > To: mshand@cisco.com > > Cc: Christian, Philip [HAL02:GI50:EXCH]; isis-wg@spider.juniper.net > > Subject: Re: [Isis-wg] Proprietary / Private TLV numbers? > > > > > > Why not just do the following? > > > > +-------------------------------------------------+ > > | Type | Length | Value | > > +-------------------------------------------------+ > > | TLV # | Length | vendor code | "value" | > > +-------------------------------------------------+ > > > > Where the vendor code is a fixed 3-4 octets? > > > > I guess one could do this on their own... couldn't they? > > > > The major problem I see here is what Philip said he wanted to fix... > > > > If vendors are doing this already and this is trying to avoid > > interoperability > > problems... then it would seem reasonable that the carrier > > would go back and > > install new images or force the vendor to fix the embedded > > base.. but they > > won't do either.. thus leaving the problem to stumble over some day... > > > > Mike > > > > > At 13:43 10/06/2002 +0100, Philip Christian wrote: > > > > > > >I suppose that we could define different sub-TLVs, a > > sub-TLV if the > > > >identifier is an IPv4 address, a different sub-TLV if it > > is a MAC address, etc > > > > > > > >Then folks could use whichever mechanism they prefer, as > > long as it is a > > > >globally unique identifier. > > > > > > > >Or is that too complex? > > > > > > Yes! That's how NSAP addresses got to be so awful :-) > > > > > > Mike > > > > > > > > > > > > >Philip > > > > > > > > > -----Original Message----- > > > > > From: mike shand > > [mailto:mshand@cisco.com ] > > > > > Sent: Monday, June 10, 2002 12:24 PM > > > > > To: Christian, Philip [HAL02:GI50:EXCH] > > > > > Cc: isis-wg@spider.juniper.net > > > > > Subject: Re: [Isis-wg] Proprietary / Private TLV numbers? > > > > > > > > > > > > > > > At 11:29 10/06/2002 +0100, Philip Christian wrote: > > > > > >Looking at draft-ietf-isis-wg-tlv-codepoints-02.txt I notice > > > > > that there is > > > > > >not really any mechanism for private or proprietary > > use of a TLV. > > > > > > > > > > > >Thus various companies (including my own) have just pcked > > > > > one and used it > > > > > >for their own purpose. Eventually this will create an > > > > > interop problem, > > > > > >but what else is a company to do? > > > > > > > > > > > >Is there a way that we could define that a certain TLV > > number is for > > > > > >private / proprietary / experimental purposes? > > > > > > > > > > > >This would then stop people just picking one. > > > > > > > > > > > >I am thinking that there would have to be some sort of > > > > > entity identifier > > > > > >in there so that when you see this TLV you know whether it > > > > > is yours or not. > > > > > > > > > > > >Maybe we could define that the first four bytes are an IP > > > > > address for > > > > > >example. Any entity large enough to want to use a > > > > > proprietary TLV would > > > > > >have a public IP address to put in there, I would have > > > > > thought. After the > > > > > >first for bytes then the rest would be free. > > > > > > > > > > > >Or maybe there is a better way to identify a particular > > > > > company / entity > > > > > >(like a MAC address)? Maybe ISO 8348? > > > > > > > > > > > >What do people think? > > > > > > > > > > > >Philip > > > > > > > > > > > > > > > > This has been suggested before, but never came to anything. I > > > > > think if it > > > > > WERE to be done then using something link the MAC OUI would > > > > > probably work. > > > > > What do you mean by ISO 8348? Do you mean ISO 6523? I > > hope not :-) > > > > > > > > > > Mike > > > > > > > > > > > _______________________________________________ > > > Isis-wg mailing list - Isis-wg@spider.juniper.net > > > http://spider.juniper.net/mailman/listinfo/isis-wg > > > > > > > > From christi@nortelnetworks.com Mon Jun 10 18:00:02 2002 From: christi@nortelnetworks.com (Philip Christian) Date: Mon, 10 Jun 2002 18:00:02 +0100 Subject: [Isis-wg] Proprietary / Private TLV numbers? Message-ID: <4103264BC8D3D51180B7002048400C454FB706@zhard0jd.europe.nortel.com> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C210A0.3ADE8AB0 Content-Type: text/plain; charset="iso-8859-1" I am guessing that OUI means an IEEE assigned MAC address? If so then it sounds okay to me. I'll write it if you like. Philip > -----Original Message----- > From: Tony Przygienda [mailto:prz@net4u.ch] > Sent: Monday, June 10, 2002 5:44 PM > To: Christian, Philip [HAL02:GI50:EXCH] > Cc: 'Mike Truskowski'; mshand@cisco.com; isis-wg@spider.juniper.net > Subject: Re: [Isis-wg] Proprietary / Private TLV numbers? > > > Yes, the proposals have been made before and nohting has been written > down. I am > for using the official OUI, this would be aligned with Frame > Relay, ATM > and so on. > The /32 may fly but unfortunately IP address space is a > volatile thing > compared to > OUIs. I assume any vendor building sophisticated networking gear with > ISIS on it > will at a certain point have an OUI, I see little value in having a > /32-address-based-cottage-industry-of-ISIS-extensions ... > > So, this time any takers to write it down ? > > thanks > > -- tony > > > Philip Christian wrote: > > > A vendor code of 4 octets could be an IPv4 address. > > Then no-one would have to assign them. The vendor just uses > a global > > IPv4 address that he has. > > > > Even the smallest vendor can buy a /32 IP address for this purpose. > > > > That would work. > > > > Philip > > > > > -----Original Message----- > > > From: Mike Truskowski [ mailto:truskows@cisco.com ] > > > Sent: Monday, June 10, 2002 2:42 PM > > > To: mshand@cisco.com > > > Cc: Christian, Philip [HAL02:GI50:EXCH]; > isis-wg@spider.juniper.net > > > Subject: Re: [Isis-wg] Proprietary / Private TLV numbers? > > > > > > > > > Why not just do the following? > > > > > > +-------------------------------------------------+ > > > | Type | Length | Value | > > > +-------------------------------------------------+ > > > | TLV # | Length | vendor code | "value" | > > > +-------------------------------------------------+ > > > > > > Where the vendor code is a fixed 3-4 octets? > > > > > > I guess one could do this on their own... couldn't they? > > > > > > The major problem I see here is what Philip said he > wanted to fix... > > > > > > If vendors are doing this already and this is trying to avoid > > > interoperability > > > problems... then it would seem reasonable that the carrier > > > would go back and > > > install new images or force the vendor to fix the embedded > > > base.. but they > > > won't do either.. thus leaving the problem to stumble > over some day... > > > > > > Mike > > > > > > > At 13:43 10/06/2002 +0100, Philip Christian wrote: > > > > > > > > >I suppose that we could define different sub-TLVs, a > > > sub-TLV if the > > > > >identifier is an IPv4 address, a different sub-TLV if it > > > is a MAC address, etc > > > > > > > > > >Then folks could use whichever mechanism they prefer, as > > > long as it is a > > > > >globally unique identifier. > > > > > > > > > >Or is that too complex? > > > > > > > > Yes! That's how NSAP addresses got to be so awful :-) > > > > > > > > Mike > > > > > > > > > > > > > > > > >Philip > > > > > > > > > > > -----Original Message----- > > > > > > From: mike shand > > > [mailto:mshand@cisco.com ] > > > > > > Sent: Monday, June 10, 2002 12:24 PM > > > > > > To: Christian, Philip [HAL02:GI50:EXCH] > > > > > > Cc: isis-wg@spider.juniper.net > > > > > > Subject: Re: [Isis-wg] Proprietary / Private TLV numbers? > > > > > > > > > > > > > > > > > > At 11:29 10/06/2002 +0100, Philip Christian wrote: > > > > > > >Looking at > draft-ietf-isis-wg-tlv-codepoints-02.txt I notice > > > > > > that there is > > > > > > >not really any mechanism for private or proprietary > > > use of a TLV. > > > > > > > > > > > > > >Thus various companies (including my own) have just pcked > > > > > > one and used it > > > > > > >for their own purpose. Eventually this will create an > > > > > > interop problem, > > > > > > >but what else is a company to do? > > > > > > > > > > > > > >Is there a way that we could define that a certain TLV > > > number is for > > > > > > >private / proprietary / experimental purposes? > > > > > > > > > > > > > >This would then stop people just picking one. > > > > > > > > > > > > > >I am thinking that there would have to be some sort of > > > > > > entity identifier > > > > > > >in there so that when you see this TLV you know whether it > > > > > > is yours or not. > > > > > > > > > > > > > >Maybe we could define that the first four bytes are an IP > > > > > > address for > > > > > > >example. Any entity large enough to want to use a > > > > > > proprietary TLV would > > > > > > >have a public IP address to put in there, I would have > > > > > > thought. After the > > > > > > >first for bytes then the rest would be free. > > > > > > > > > > > > > >Or maybe there is a better way to identify a particular > > > > > > company / entity > > > > > > >(like a MAC address)? Maybe ISO 8348? > > > > > > > > > > > > > >What do people think? > > > > > > > > > > > > > >Philip > > > > > > > > > > > > > > > > > > > This has been suggested before, but never came to > anything. I > > > > > > think if it > > > > > > WERE to be done then using something link the MAC OUI would > > > > > > probably work. > > > > > > What do you mean by ISO 8348? Do you mean ISO 6523? I > > > hope not :-) > > > > > > > > > > > > Mike > > > > > > > > > > > > > > _______________________________________________ > > > > Isis-wg mailing list - Isis-wg@spider.juniper.net > > > > http://spider.juniper.net/mailman/listinfo/isis-wg > > > > > > > > > > > > > > > ------_=_NextPart_001_01C210A0.3ADE8AB0 Content-Type: text/html; charset="iso-8859-1" RE: [Isis-wg] Proprietary / Private TLV numbers?

I am guessing that OUI means an IEEE assigned MAC address?

If so then it sounds okay to me.

I'll write it if you like.

Philip

> -----Original Message-----
> From: Tony Przygienda [mailto:prz@net4u.ch]
> Sent: Monday, June 10, 2002 5:44 PM
> To: Christian, Philip [HAL02:GI50:EXCH]
> Cc: 'Mike Truskowski'; mshand@cisco.com; isis-wg@spider.juniper.net
> Subject: Re: [Isis-wg] Proprietary / Private TLV numbers?
>
>
> Yes, the proposals have been made before and nohting has been written
> down. I am
> for using the official OUI, this would be aligned with Frame
> Relay, ATM
> and so on.
> The /32 may fly but unfortunately IP address space is a
> volatile thing
> compared to
> OUIs. I assume any vendor building sophisticated networking gear with
> ISIS on it
> will at a certain point have an OUI, I see little value in having a
> /32-address-based-cottage-industry-of-ISIS-extensions ...
>
> So, this time any takers to write it down ?
>
>     thanks
>
>     -- tony
>
>
> Philip Christian wrote:
>
> > A vendor code of 4 octets could be an IPv4 address.
> > Then no-one would have to assign them. The vendor just uses
> a global
> > IPv4 address that he has.
> >
> > Even the smallest vendor can buy a /32 IP address for this purpose.
> >
> > That would work.
> >
> > Philip
> >
> > > -----Original Message-----
> > > From: Mike Truskowski [ mailto:truskows@cisco.com ]
> > > Sent: Monday, June 10, 2002 2:42 PM
> > > To: mshand@cisco.com
> > > Cc: Christian, Philip [HAL02:GI50:EXCH];
> isis-wg@spider.juniper.net
> > > Subject: Re: [Isis-wg] Proprietary / Private TLV numbers?
> > >
> > >
> > > Why not just do the following?
> > >
> > > +-------------------------------------------------+
> > > | Type   |  Length  |       Value                 |
> > > +-------------------------------------------------+
> > > | TLV #  |  Length  |  vendor code  |   "value"   |
> > > +-------------------------------------------------+
> > >
> > > Where the vendor code is a fixed 3-4 octets?
> > >
> > > I guess one could do this on their own... couldn't they?
> > >
> > > The major problem I see here is what Philip said he
> wanted to fix...
> > >
> > > If vendors are doing this already and this is trying to avoid
> > > interoperability
> > > problems... then it would seem reasonable that the carrier
> > > would go back and
> > > install new images or force the vendor to fix the embedded
> > > base..  but they
> > > won't do either.. thus leaving the problem to stumble
> over some day...
> > >
> > > Mike
> > >
> > > > At 13:43 10/06/2002 +0100, Philip Christian wrote:
> > > >
> > > > >I suppose that we could define different sub-TLVs, a
> > > sub-TLV if the
> > > > >identifier is an IPv4 address, a different sub-TLV if it
> > > is a MAC address, etc
> > > > >
> > > > >Then folks could use whichever mechanism they prefer, as
> > > long as it is a
> > > > >globally unique identifier.
> > > > >
> > > > >Or is that too complex?
> > > >
> > > > Yes! That's how NSAP addresses got to be so awful :-)
> > > >
> > > >          Mike
> > > >
> > > >
> > > >
> > > > >Philip
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: mike shand
> > > [<mailto:mshand@cisco.com >mailto:mshand@cisco.com ]
> > > > > > Sent: Monday, June 10, 2002 12:24 PM
> > > > > > To: Christian, Philip [HAL02:GI50:EXCH]
> > > > > > Cc: isis-wg@spider.juniper.net
> > > > > > Subject: Re: [Isis-wg] Proprietary / Private TLV numbers?
> > > > > >
> > > > > >
> > > > > > At 11:29 10/06/2002 +0100, Philip Christian wrote:
> > > > > > >Looking at
> draft-ietf-isis-wg-tlv-codepoints-02.txt I notice
> > > > > > that there is
> > > > > > >not really any mechanism for private or proprietary
> > > use of a TLV.
> > > > > > >
> > > > > > >Thus various companies (including my own) have just pcked
> > > > > > one and used it
> > > > > > >for their own purpose.  Eventually this will create an
> > > > > > interop problem,
> > > > > > >but what else is a company to do?
> > > > > > >
> > > > > > >Is there a way that we could define that a certain TLV
> > > number is for
> > > > > > >private / proprietary / experimental purposes?
> > > > > > >
> > > > > > >This would then stop people just picking one.
> > > > > > >
> > > > > > >I am thinking that there would have to be some sort of
> > > > > > entity identifier
> > > > > > >in there so that when you see this TLV you know whether it
> > > > > > is yours or not.
> > > > > > >
> > > > > > >Maybe we could define that the first four bytes are an IP
> > > > > > address for
> > > > > > >example.  Any entity large enough to want to use a
> > > > > > proprietary TLV would
> > > > > > >have a public IP address to put in there, I would have
> > > > > > thought. After the
> > > > > > >first for bytes then the rest would be free.
> > > > > > >
> > > > > > >Or maybe there is a better way to identify a particular
> > > > > > company / entity
> > > > > > >(like a MAC address)?  Maybe ISO 8348?
> > > > > > >
> > > > > > >What do people think?
> > > > > > >
> > > > > > >Philip
> > > > > > >
> > > > > >
> > > > > > This has been suggested before, but never came to
> anything. I
> > > > > > think if it
> > > > > > WERE to be done then using something link the MAC OUI would
> > > > > > probably work.
> > > > > > What do you mean by ISO 8348? Do you mean ISO 6523? I
> > > hope not :-)
> > > > > >
> > > > > >          Mike
> > > > > >
> > > >
> > > > _______________________________________________
> > > > Isis-wg mailing list  -  Isis-wg@spider.juniper.net
> > > > http://spider.juniper.net/mailman/listinfo/isis-wg
> > > >
> > >
> > >
> >
>
>
>

------_=_NextPart_001_01C210A0.3ADE8AB0-- From christi@nortelnetworks.com Mon Jun 10 18:09:01 2002 From: christi@nortelnetworks.com (Philip Christian) Date: Mon, 10 Jun 2002 18:09:01 +0100 Subject: [Isis-wg] Proprietary / Private TLV numbers? Message-ID: <4103264BC8D3D51180B7002048400C454FB707@zhard0jd.europe.nortel.com> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C210A1.3AE6317E Content-Type: text/plain; charset="iso-8859-1" And to answer my own question... One can read what OUIs are from http://standards.ieee.org/regauth/oui/index.shtml still sounds okay to me Philip > -----Original Message----- > From: Christian, Philip [HAL02:GI50:EXCH] > Sent: Monday, June 10, 2002 6:00 PM > To: 'Tony Przygienda' > Cc: 'Mike Truskowski'; mshand@cisco.com; isis-wg@spider.juniper.net > Subject: RE: [Isis-wg] Proprietary / Private TLV numbers? > > > I am guessing that OUI means an IEEE assigned MAC address? > > If so then it sounds okay to me. > > I'll write it if you like. > > Philip > > > -----Original Message----- > > From: Tony Przygienda [mailto:prz@net4u.ch] > > Sent: Monday, June 10, 2002 5:44 PM > > To: Christian, Philip [HAL02:GI50:EXCH] > > Cc: 'Mike Truskowski'; mshand@cisco.com; isis-wg@spider.juniper.net > > Subject: Re: [Isis-wg] Proprietary / Private TLV numbers? > > > > > > Yes, the proposals have been made before and nohting has > been written > > down. I am > > for using the official OUI, this would be aligned with Frame > > Relay, ATM > > and so on. > > The /32 may fly but unfortunately IP address space is a > > volatile thing > > compared to > > OUIs. I assume any vendor building sophisticated networking > gear with > > ISIS on it > > will at a certain point have an OUI, I see little value in having a > > /32-address-based-cottage-industry-of-ISIS-extensions ... > > > > So, this time any takers to write it down ? > > > > thanks > > > > -- tony > > > > > > Philip Christian wrote: > > > > > A vendor code of 4 octets could be an IPv4 address. > > > Then no-one would have to assign them. The vendor just uses > > a global > > > IPv4 address that he has. > > > > > > Even the smallest vendor can buy a /32 IP address for > this purpose. > > > > > > That would work. > > > > > > Philip > > > > > > > -----Original Message----- > > > > From: Mike Truskowski [ mailto:truskows@cisco.com ] > > > > Sent: Monday, June 10, 2002 2:42 PM > > > > To: mshand@cisco.com > > > > Cc: Christian, Philip [HAL02:GI50:EXCH]; > > isis-wg@spider.juniper.net > > > > Subject: Re: [Isis-wg] Proprietary / Private TLV numbers? > > > > > > > > > > > > Why not just do the following? > > > > > > > > +-------------------------------------------------+ > > > > | Type | Length | Value | > > > > +-------------------------------------------------+ > > > > | TLV # | Length | vendor code | "value" | > > > > +-------------------------------------------------+ > > > > > > > > Where the vendor code is a fixed 3-4 octets? > > > > > > > > I guess one could do this on their own... couldn't they? > > > > > > > > The major problem I see here is what Philip said he > > wanted to fix... > > > > > > > > If vendors are doing this already and this is trying to avoid > > > > interoperability > > > > problems... then it would seem reasonable that the carrier > > > > would go back and > > > > install new images or force the vendor to fix the embedded > > > > base.. but they > > > > won't do either.. thus leaving the problem to stumble > > over some day... > > > > > > > > Mike > > > > > > > > > At 13:43 10/06/2002 +0100, Philip Christian wrote: > > > > > > > > > > >I suppose that we could define different sub-TLVs, a > > > > sub-TLV if the > > > > > >identifier is an IPv4 address, a different sub-TLV if it > > > > is a MAC address, etc > > > > > > > > > > > >Then folks could use whichever mechanism they prefer, as > > > > long as it is a > > > > > >globally unique identifier. > > > > > > > > > > > >Or is that too complex? > > > > > > > > > > Yes! That's how NSAP addresses got to be so awful :-) > > > > > > > > > > Mike > > > > > > > > > > > > > > > > > > > > >Philip > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: mike shand > > > > [mailto:mshand@cisco.com ] > > > > > > > Sent: Monday, June 10, 2002 12:24 PM > > > > > > > To: Christian, Philip [HAL02:GI50:EXCH] > > > > > > > Cc: isis-wg@spider.juniper.net > > > > > > > Subject: Re: [Isis-wg] Proprietary / Private TLV numbers? > > > > > > > > > > > > > > > > > > > > > At 11:29 10/06/2002 +0100, Philip Christian wrote: > > > > > > > >Looking at > > draft-ietf-isis-wg-tlv-codepoints-02.txt I notice > > > > > > > that there is > > > > > > > >not really any mechanism for private or proprietary > > > > use of a TLV. > > > > > > > > > > > > > > > >Thus various companies (including my own) have just pcked > > > > > > > one and used it > > > > > > > >for their own purpose. Eventually this will create an > > > > > > > interop problem, > > > > > > > >but what else is a company to do? > > > > > > > > > > > > > > > >Is there a way that we could define that a certain TLV > > > > number is for > > > > > > > >private / proprietary / experimental purposes? > > > > > > > > > > > > > > > >This would then stop people just picking one. > > > > > > > > > > > > > > > >I am thinking that there would have to be some sort of > > > > > > > entity identifier > > > > > > > >in there so that when you see this TLV you know > whether it > > > > > > > is yours or not. > > > > > > > > > > > > > > > >Maybe we could define that the first four bytes are an IP > > > > > > > address for > > > > > > > >example. Any entity large enough to want to use a > > > > > > > proprietary TLV would > > > > > > > >have a public IP address to put in there, I would have > > > > > > > thought. After the > > > > > > > >first for bytes then the rest would be free. > > > > > > > > > > > > > > > >Or maybe there is a better way to identify a particular > > > > > > > company / entity > > > > > > > >(like a MAC address)? Maybe ISO 8348? > > > > > > > > > > > > > > > >What do people think? > > > > > > > > > > > > > > > >Philip > > > > > > > > > > > > > > > > > > > > > > This has been suggested before, but never came to > > anything. I > > > > > > > think if it > > > > > > > WERE to be done then using something link the MAC > OUI would > > > > > > > probably work. > > > > > > > What do you mean by ISO 8348? Do you mean ISO 6523? I > > > > hope not :-) > > > > > > > > > > > > > > Mike > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Isis-wg mailing list - Isis-wg@spider.juniper.net > > > > > http://spider.juniper.net/mailman/listinfo/isis-wg > > > > > > > > > > > > > > > > > > > > > > > ------_=_NextPart_001_01C210A1.3AE6317E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Isis-wg] Proprietary / Private TLV numbers?

And to answer my own question...

One can read what OUIs are from
http://standards.ieee.org/regauth/oui/index.shtml<= /FONT>

still sounds okay to me

Philip

> -----Original Message-----
> From: Christian, Philip [HAL02:GI50:EXCH] =
> Sent: Monday, June 10, 2002 6:00 PM
> To: 'Tony Przygienda'
> Cc: 'Mike Truskowski'; mshand@cisco.com; = isis-wg@spider.juniper.net
> Subject: RE: [Isis-wg] Proprietary / Private = TLV numbers?
>
>
> I am guessing that OUI means an IEEE assigned = MAC address?
>
> If so then it sounds okay to me.
>
> I'll write it if you like.
>
> Philip
>
> > -----Original Message-----
> > From: Tony Przygienda [mailto:prz@net4u.ch]
> > Sent: Monday, June 10, 2002 5:44 PM
> > To: Christian, Philip = [HAL02:GI50:EXCH]
> > Cc: 'Mike Truskowski'; mshand@cisco.com; = isis-wg@spider.juniper.net
> > Subject: Re: [Isis-wg] Proprietary / = Private TLV numbers?
> >
> >
> > Yes, the proposals have been made before = and nohting has
> been written
> > down. I am
> > for using the official OUI, this would be = aligned with Frame
> > Relay, ATM
> > and so on.
> > The /32 may fly but unfortunately IP = address space is a
> > volatile thing
> > compared to
> > OUIs. I assume any vendor building = sophisticated networking
> gear with
> > ISIS on it
> > will at a certain point have an OUI, I see = little value in having a
> > = /32-address-based-cottage-industry-of-ISIS-extensions ...
> >
> > So, this time any takers to write it down = ?
> >
> >     thanks
> >
> >     -- tony
> >
> >
> > Philip Christian wrote:
> >
> > > A vendor code of 4 octets could be an = IPv4 address.
> > > Then no-one would have to assign = them. The vendor just uses
> > a global
> > > IPv4 address that he has.
> > >
> > > Even the smallest vendor can buy a = /32 IP address for
> this purpose.
> > >
> > > That would work.
> > >
> > > Philip
> > >
> > > > -----Original = Message-----
> > > > From: Mike Truskowski [ mailto:truskows@cisco.com = ]
> > > > Sent: Monday, June 10, 2002 2:42 = PM
> > > > To: mshand@cisco.com
> > > > Cc: Christian, Philip = [HAL02:GI50:EXCH];
> > isis-wg@spider.juniper.net
> > > > Subject: Re: [Isis-wg] = Proprietary / Private TLV numbers?
> > > >
> > > >
> > > > Why not just do the = following?
> > > >
> > > > = +-------------------------------------------------+
> > > > | Type   |  = Length  |       = Value           &= nbsp;     |
> > > > = +-------------------------------------------------+
> > > > | TLV #  |  = Length  |  vendor code  |   = "value"   |
> > > > = +-------------------------------------------------+
> > > >
> > > > Where the vendor code is a fixed = 3-4 octets?
> > > >
> > > > I guess one could do this on = their own... couldn't they?
> > > >
> > > > The major problem I see here is = what Philip said he
> > wanted to fix...
> > > >
> > > > If vendors are doing this = already and this is trying to avoid
> > > > interoperability
> > > > problems... then it would seem = reasonable that the carrier
> > > > would go back and
> > > > install new images or force the = vendor to fix the embedded
> > > > base..  but they
> > > > won't do either.. thus leaving = the problem to stumble
> > over some day...
> > > >
> > > > Mike
> > > >
> > > > > At 13:43 10/06/2002 +0100, = Philip Christian wrote:
> > > > >
> > > > > >I suppose that we could = define different sub-TLVs, a
> > > > sub-TLV if the
> > > > > >identifier is an IPv4 = address, a different sub-TLV if it
> > > > is a MAC address, etc
> > > > > >
> > > > > >Then folks could use = whichever mechanism they prefer, as
> > > > long as it is a
> > > > > >globally unique = identifier.
> > > > > >
> > > > > >Or is that too = complex?
> > > > >
> > > > > Yes! That's how NSAP = addresses got to be so awful :-)
> > > > >
> > > > = >          Mike
> > > > >
> > > > >
> > > > >
> > > > > >Philip
> > > > > >
> > > > > > > -----Original = Message-----
> > > > > > > From: mike = shand
> > > > [<mailto:mshand@cisco.com >mailto:mshand@cisco.com ]
> > > > > > > Sent: Monday, = June 10, 2002 12:24 PM
> > > > > > > To: Christian, = Philip [HAL02:GI50:EXCH]
> > > > > > > Cc: = isis-wg@spider.juniper.net
> > > > > > > Subject: Re: = [Isis-wg] Proprietary / Private TLV numbers?
> > > > > > >
> > > > > > >
> > > > > > > At 11:29 = 10/06/2002 +0100, Philip Christian wrote:
> > > > > > > >Looking at =
> > draft-ietf-isis-wg-tlv-codepoints-02.txt I = notice
> > > > > > > that there = is
> > > > > > > >not really = any mechanism for private or proprietary
> > > > use of a TLV.
> > > > > > > >
> > > > > > > >Thus various = companies (including my own) have just pcked
> > > > > > > one and used = it
> > > > > > > >for their own = purpose.  Eventually this will create an
> > > > > > > interop = problem,
> > > > > > > >but what else = is a company to do?
> > > > > > > >
> > > > > > > >Is there a = way that we could define that a certain TLV
> > > > number is for
> > > > > > > >private / = proprietary / experimental purposes?
> > > > > > > >
> > > > > > > >This would = then stop people just picking one.
> > > > > > > >
> > > > > > > >I am thinking = that there would have to be some sort of
> > > > > > > entity = identifier
> > > > > > > >in there so = that when you see this TLV you know
> whether it
> > > > > > > is yours or = not.
> > > > > > > >
> > > > > > > >Maybe we = could define that the first four bytes are an IP
> > > > > > > address = for
> > > > > > > = >example.  Any entity large enough to want to use a
> > > > > > > proprietary TLV = would
> > > > > > > >have a public = IP address to put in there, I would have
> > > > > > > thought. After = the
> > > > > > > >first for = bytes then the rest would be free.
> > > > > > > >
> > > > > > > >Or maybe = there is a better way to identify a particular
> > > > > > > company / = entity
> > > > > > > >(like a MAC = address)?  Maybe ISO 8348?
> > > > > > > >
> > > > > > > >What do = people think?
> > > > > > > >
> > > > > > > >Philip
> > > > > > > >
> > > > > > >
> > > > > > > This has been = suggested before, but never came to
> > anything. I
> > > > > > > think if = it
> > > > > > > WERE to be done = then using something link the MAC
> OUI would
> > > > > > > probably = work.
> > > > > > > What do you mean = by ISO 8348? Do you mean ISO 6523? I
> > > > hope not :-)
> > > > > > >
> > > > > > = >          Mike
> > > > > > >
> > > > >
> > > > > = _______________________________________________
> > > > > Isis-wg mailing list  = -  Isis-wg@spider.juniper.net
> > > > > http://spider.juniper.net/mailman/listinfo/isis-wg=
> > > > >
> > > >
> > > >
> > >
> >
> >
> >
>

------_=_NextPart_001_01C210A1.3AE6317E-- From christi@nortelnetworks.com Tue Jun 11 12:01:12 2002 From: christi@nortelnetworks.com (Philip Christian) Date: Tue, 11 Jun 2002 12:01:12 +0100 Subject: [Isis-wg] Proprietary / Private TLV numbers? Message-ID: <4103264BC8D3D51180B7002048400C454FB709@zhard0jd.europe.nortel.com> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C21137.4C4F2E2A Content-Type: text/plain; charset="iso-8859-1" So I am just writing something at the moment based on OUIs. Two questions. 1. What TLV number shall be assigned as the proprietary TLV? 2. Does the "locally assigned" bit have any significance in an OUI as it does in a MAC address? IEEE assigned OUIs are no problem for vendors, but I am thinking that there is no harm in allowing an individual to use an OUI with "locally assigned" bit set (or something similar) if they do not have an IEEE assigned OUI. One scenario is maybe a college student doing a university project for example. An absolute requirement for an IEEE assigned OUI would be a big deal for them, whilst maybe the loss of an absolute guarantee of uniqueness would not cause them a serious problem. In any case they can put their own "key" somewhere in the TLV to statistically reduce the problem to next to nothing, for example. The draft could clearly state that this SHOULD NOT be used for commercial products intended for deployment in the Internet, if that helps. Put another way, it might just stop a student / lab guy from just picked your OUI at random and trampling on it, just because he thinks that it will never get out of the lab... Thoughts? Philip > -----Original Message----- > From: Tony Przygienda [mailto:prz@net4u.ch] > Sent: Monday, June 10, 2002 5:44 PM > To: Christian, Philip [HAL02:GI50:EXCH] > Cc: 'Mike Truskowski'; mshand@cisco.com; isis-wg@spider.juniper.net > Subject: Re: [Isis-wg] Proprietary / Private TLV numbers? > > > Yes, the proposals have been made before and nohting has been written > down. I am > for using the official OUI, this would be aligned with Frame > Relay, ATM > and so on. > The /32 may fly but unfortunately IP address space is a > volatile thing > compared to > OUIs. I assume any vendor building sophisticated networking gear with > ISIS on it > will at a certain point have an OUI, I see little value in having a > /32-address-based-cottage-industry-of-ISIS-extensions ... > > So, this time any takers to write it down ? > > thanks > > -- tony > > > Philip Christian wrote: > > > A vendor code of 4 octets could be an IPv4 address. > > Then no-one would have to assign them. The vendor just uses > a global > > IPv4 address that he has. > > > > Even the smallest vendor can buy a /32 IP address for this purpose. > > > > That would work. > > > > Philip > > > > > -----Original Message----- > > > From: Mike Truskowski [ mailto:truskows@cisco.com ] > > > Sent: Monday, June 10, 2002 2:42 PM > > > To: mshand@cisco.com > > > Cc: Christian, Philip [HAL02:GI50:EXCH]; > isis-wg@spider.juniper.net > > > Subject: Re: [Isis-wg] Proprietary / Private TLV numbers? > > > > > > > > > Why not just do the following? > > > > > > +-------------------------------------------------+ > > > | Type | Length | Value | > > > +-------------------------------------------------+ > > > | TLV # | Length | vendor code | "value" | > > > +-------------------------------------------------+ > > > > > > Where the vendor code is a fixed 3-4 octets? > > > > > > I guess one could do this on their own... couldn't they? > > > > > > The major problem I see here is what Philip said he > wanted to fix... > > > > > > If vendors are doing this already and this is trying to avoid > > > interoperability > > > problems... then it would seem reasonable that the carrier > > > would go back and > > > install new images or force the vendor to fix the embedded > > > base.. but they > > > won't do either.. thus leaving the problem to stumble > over some day... > > > > > > Mike > > > > > > > At 13:43 10/06/2002 +0100, Philip Christian wrote: > > > > > > > > >I suppose that we could define different sub-TLVs, a > > > sub-TLV if the > > > > >identifier is an IPv4 address, a different sub-TLV if it > > > is a MAC address, etc > > > > > > > > > >Then folks could use whichever mechanism they prefer, as > > > long as it is a > > > > >globally unique identifier. > > > > > > > > > >Or is that too complex? > > > > > > > > Yes! That's how NSAP addresses got to be so awful :-) > > > > > > > > Mike > > > > > > > > > > > > > > > > >Philip > > > > > > > > > > > -----Original Message----- > > > > > > From: mike shand > > > [mailto:mshand@cisco.com ] > > > > > > Sent: Monday, June 10, 2002 12:24 PM > > > > > > To: Christian, Philip [HAL02:GI50:EXCH] > > > > > > Cc: isis-wg@spider.juniper.net > > > > > > Subject: Re: [Isis-wg] Proprietary / Private TLV numbers? > > > > > > > > > > > > > > > > > > At 11:29 10/06/2002 +0100, Philip Christian wrote: > > > > > > >Looking at > draft-ietf-isis-wg-tlv-codepoints-02.txt I notice > > > > > > that there is > > > > > > >not really any mechanism for private or proprietary > > > use of a TLV. > > > > > > > > > > > > > >Thus various companies (including my own) have just pcked > > > > > > one and used it > > > > > > >for their own purpose. Eventually this will create an > > > > > > interop problem, > > > > > > >but what else is a company to do? > > > > > > > > > > > > > >Is there a way that we could define that a certain TLV > > > number is for > > > > > > >private / proprietary / experimental purposes? > > > > > > > > > > > > > >This would then stop people just picking one. > > > > > > > > > > > > > >I am thinking that there would have to be some sort of > > > > > > entity identifier > > > > > > >in there so that when you see this TLV you know whether it > > > > > > is yours or not. > > > > > > > > > > > > > >Maybe we could define that the first four bytes are an IP > > > > > > address for > > > > > > >example. Any entity large enough to want to use a > > > > > > proprietary TLV would > > > > > > >have a public IP address to put in there, I would have > > > > > > thought. After the > > > > > > >first for bytes then the rest would be free. > > > > > > > > > > > > > >Or maybe there is a better way to identify a particular > > > > > > company / entity > > > > > > >(like a MAC address)? Maybe ISO 8348? > > > > > > > > > > > > > >What do people think? > > > > > > > > > > > > > >Philip > > > > > > > > > > > > > > > > > > > This has been suggested before, but never came to > anything. I > > > > > > think if it > > > > > > WERE to be done then using something link the MAC OUI would > > > > > > probably work. > > > > > > What do you mean by ISO 8348? Do you mean ISO 6523? I > > > hope not :-) > > > > > > > > > > > > Mike > > > > > > > > > > > > > > _______________________________________________ > > > > Isis-wg mailing list - Isis-wg@spider.juniper.net > > > > http://spider.juniper.net/mailman/listinfo/isis-wg > > > > > > > > > > > > > > > ------_=_NextPart_001_01C21137.4C4F2E2A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Isis-wg] Proprietary / Private TLV numbers?

So I am just writing something at the moment based on = OUIs.

Two questions.

1. What TLV number shall be assigned as the = proprietary TLV?

2. Does the "locally assigned" bit have any = significance in an OUI as it does in a MAC address?

IEEE assigned OUIs are no problem for vendors, but I = am thinking that there is no harm in allowing an individual to use an = OUI with "locally assigned" bit set (or something similar) if = they do not have an IEEE assigned OUI.

One scenario is maybe a college student doing a = university project for example.  An absolute requirement for an = IEEE assigned OUI would be a big deal for them, whilst maybe the loss = of an absolute guarantee of uniqueness would not cause them a serious = problem.  In any case they can put their own "key" = somewhere in the TLV to statistically reduce the problem to next to = nothing, for example.

The draft could clearly state that this SHOULD NOT be = used for commercial products intended for deployment in the Internet, = if that helps.

Put another way, it might just stop a student / lab = guy from just picked your OUI at random and trampling on it, just = because he thinks that it will never get out of the lab...

Thoughts?

Philip

> -----Original Message-----
> From: Tony Przygienda [mailto:prz@net4u.ch]
> Sent: Monday, June 10, 2002 5:44 PM
> To: Christian, Philip [HAL02:GI50:EXCH]
> Cc: 'Mike Truskowski'; mshand@cisco.com; = isis-wg@spider.juniper.net
> Subject: Re: [Isis-wg] Proprietary / Private = TLV numbers?
>
>
> Yes, the proposals have been made before and = nohting has been written
> down. I am
> for using the official OUI, this would be = aligned with Frame
> Relay, ATM
> and so on.
> The /32 may fly but unfortunately IP address = space is a
> volatile thing
> compared to
> OUIs. I assume any vendor building = sophisticated networking gear with
> ISIS on it
> will at a certain point have an OUI, I see = little value in having a
> = /32-address-based-cottage-industry-of-ISIS-extensions ...
>
> So, this time any takers to write it down = ?
>
>     thanks
>
>     -- tony
>
>
> Philip Christian wrote:
>
> > A vendor code of 4 octets could be an IPv4 = address.
> > Then no-one would have to assign them. The = vendor just uses
> a global
> > IPv4 address that he has.
> >
> > Even the smallest vendor can buy a /32 IP = address for this purpose.
> >
> > That would work.
> >
> > Philip
> >
> > > -----Original Message-----
> > > From: Mike Truskowski [ mailto:truskows@cisco.com = ]
> > > Sent: Monday, June 10, 2002 2:42 = PM
> > > To: mshand@cisco.com
> > > Cc: Christian, Philip = [HAL02:GI50:EXCH];
> isis-wg@spider.juniper.net
> > > Subject: Re: [Isis-wg] Proprietary / = Private TLV numbers?
> > >
> > >
> > > Why not just do the following?
> > >
> > > = +-------------------------------------------------+
> > > | Type   |  = Length  |       = Value           &= nbsp;     |
> > > = +-------------------------------------------------+
> > > | TLV #  |  Length  = |  vendor code  |   "value"   = |
> > > = +-------------------------------------------------+
> > >
> > > Where the vendor code is a fixed 3-4 = octets?
> > >
> > > I guess one could do this on their = own... couldn't they?
> > >
> > > The major problem I see here is what = Philip said he
> wanted to fix...
> > >
> > > If vendors are doing this already and = this is trying to avoid
> > > interoperability
> > > problems... then it would seem = reasonable that the carrier
> > > would go back and
> > > install new images or force the = vendor to fix the embedded
> > > base..  but they
> > > won't do either.. thus leaving the = problem to stumble
> over some day...
> > >
> > > Mike
> > >
> > > > At 13:43 10/06/2002 +0100, = Philip Christian wrote:
> > > >
> > > > >I suppose that we could = define different sub-TLVs, a
> > > sub-TLV if the
> > > > >identifier is an IPv4 = address, a different sub-TLV if it
> > > is a MAC address, etc
> > > > >
> > > > >Then folks could use = whichever mechanism they prefer, as
> > > long as it is a
> > > > >globally unique = identifier.
> > > > >
> > > > >Or is that too = complex?
> > > >
> > > > Yes! That's how NSAP addresses = got to be so awful :-)
> > > >
> > > = >          Mike
> > > >
> > > >
> > > >
> > > > >Philip
> > > > >
> > > > > > -----Original = Message-----
> > > > > > From: mike = shand
> > > [<mailto:mshand@cisco.com >mailto:mshand@cisco.com ]
> > > > > > Sent: Monday, June 10, = 2002 12:24 PM
> > > > > > To: Christian, Philip = [HAL02:GI50:EXCH]
> > > > > > Cc: = isis-wg@spider.juniper.net
> > > > > > Subject: Re: [Isis-wg] = Proprietary / Private TLV numbers?
> > > > > >
> > > > > >
> > > > > > At 11:29 10/06/2002 = +0100, Philip Christian wrote:
> > > > > > >Looking at
> draft-ietf-isis-wg-tlv-codepoints-02.txt I = notice
> > > > > > that there is
> > > > > > >not really any = mechanism for private or proprietary
> > > use of a TLV.
> > > > > > >
> > > > > > >Thus various = companies (including my own) have just pcked
> > > > > > one and used it
> > > > > > >for their own = purpose.  Eventually this will create an
> > > > > > interop = problem,
> > > > > > >but what else is a = company to do?
> > > > > > >
> > > > > > >Is there a way = that we could define that a certain TLV
> > > number is for
> > > > > > >private / = proprietary / experimental purposes?
> > > > > > >
> > > > > > >This would then = stop people just picking one.
> > > > > > >
> > > > > > >I am thinking that = there would have to be some sort of
> > > > > > entity = identifier
> > > > > > >in there so that = when you see this TLV you know whether it
> > > > > > is yours or = not.
> > > > > > >
> > > > > > >Maybe we could = define that the first four bytes are an IP
> > > > > > address for
> > > > > > >example.  Any = entity large enough to want to use a
> > > > > > proprietary TLV = would
> > > > > > >have a public IP = address to put in there, I would have
> > > > > > thought. After = the
> > > > > > >first for bytes = then the rest would be free.
> > > > > > >
> > > > > > >Or maybe there is = a better way to identify a particular
> > > > > > company / = entity
> > > > > > >(like a MAC = address)?  Maybe ISO 8348?
> > > > > > >
> > > > > > >What do people = think?
> > > > > > >
> > > > > > >Philip
> > > > > > >
> > > > > >
> > > > > > This has been = suggested before, but never came to
> anything. I
> > > > > > think if it
> > > > > > WERE to be done then = using something link the MAC OUI would
> > > > > > probably work.
> > > > > > What do you mean by = ISO 8348? Do you mean ISO 6523? I
> > > hope not :-)
> > > > > >
> > > > > = >          Mike
> > > > > >
> > > >
> > > > = _______________________________________________
> > > > Isis-wg mailing list  = -  Isis-wg@spider.juniper.net
> > > > http://spider.juniper.net/mailman/listinfo/isis-wg=
> > > >
> > >
> > >
> >
>
>
>

------_=_NextPart_001_01C21137.4C4F2E2A-- From Alex Zinin Wed Jun 5 18:00:52 2002 From: Alex Zinin (Alex Zinin) Date: Wed, 5 Jun 2002 10:00:52 -0700 Subject: [Isis-wg] last call on draft draft-ietf-isis-ext-lsp-frags-00 ... In-Reply-To: <4103264BC8D3D51180B7002048400C454FB6F5@zhard0jd.europe.nortel.com> References: <4103264BC8D3D51180B7002048400C454FB6F5@zhard0jd.europe.nortel.com> Message-ID: <29295418.20020605100052@psg.com> Philip, >> "extended" LSPs, though not perfect, make more sense--I couldn't come >> up with a better name, maybe native English speakers can :) > Is this is a similar concept to "Extended Local Circuit ID" in three way > handshaking? > it sounds as though it is, in which case consistency is a good thing. Not exactly similar--the extended circuit ID is really "extended", i.e., it's length is increased; in the LSP case, those are not enlarged LSPs, but additional ones announced as originated by a fake IS and thus extending the amount of information a physical IS can announce... Alex From christi@nortelnetworks.com Wed Jun 5 19:48:10 2002 From: christi@nortelnetworks.com (Philip Christian) Date: Wed, 5 Jun 2002 19:48:10 +0100 Subject: [Isis-wg] last call on draft draft-ietf-isis-ext-lsp-frags-00 ... Message-ID: <4103264BC8D3D51180B7002048400C454FB6F7@zhard0jd.europe.nortel.com> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C20CC1.894C7168 Content-Type: text/plain; charset="iso-8859-1" To me an "extended" entity is the original entity plus an "extension". I am currently planning an "extension" to my house, and after I have done it then the entire house will be "extended". I guess that's why it is on my mind. So I think that these are "extension LSPs" or "expansion LSPs", or something... And I suppose that they have an "extension System Identifer" too... Next time I'll read the draft before commenting on it :) Hope that helps, Philip > -----Original Message----- > From: Alex Zinin [mailto:zinin@psg.com] > Sent: Wednesday, June 05, 2002 6:01 PM > To: Christian, Philip [HAL02:GI50:EXCH] > Cc: Amir Hermelin; isis-wg@juniper.net > Subject: Re: [Isis-wg] last call on draft > draft-ietf-isis-ext-lsp-frags-00 ... > > > Philip, > > >> "extended" LSPs, though not perfect, make more sense--I > couldn't come > >> up with a better name, maybe native English speakers can :) > > > Is this is a similar concept to "Extended Local Circuit ID" > in three way > > handshaking? > > it sounds as though it is, in which case consistency is a > good thing. > > Not exactly similar--the extended circuit ID is really "extended", > i.e., it's length is increased; in the LSP case, those are not > enlarged LSPs, but additional ones announced as originated by > a fake IS and thus extending the amount of information a physical > IS can announce... > > Alex > > > ------_=_NextPart_001_01C20CC1.894C7168 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Isis-wg] last call on draft = draft-ietf-isis-ext-lsp-frags-00 ...

To me an "extended" entity is the original = entity plus an "extension".

I am currently planning an "extension" to = my house, and after I have done it then the entire house will be = "extended".  I guess that's why it is on my = mind.

So I think that these are "extension LSPs" = or "expansion LSPs", or something...
And I suppose that they have an "extension = System Identifer" too...

Next time I'll read the draft before commenting on it = :)

Hope that helps, Philip

> -----Original Message-----
> From: Alex Zinin [mailto:zinin@psg.com]
> Sent: Wednesday, June 05, 2002 6:01 PM
> To: Christian, Philip [HAL02:GI50:EXCH]
> Cc: Amir Hermelin; isis-wg@juniper.net
> Subject: Re: [Isis-wg] last call on = draft
> draft-ietf-isis-ext-lsp-frags-00 ...
>
>
> Philip,
>
> >> "extended" LSPs, though not = perfect, make more sense--I
> couldn't come
> >> up with a better name, maybe native = English speakers can :)
>
> > Is this is a similar concept to = "Extended Local Circuit ID"
> in three way
> > handshaking?
> > it sounds as though it is, in which case = consistency is a
> good thing.
>
> Not exactly similar--the extended circuit ID is = really "extended",
> i.e., it's length is increased; in the LSP = case, those are not
> enlarged LSPs, but additional ones announced as = originated by
> a fake IS and thus extending the amount of = information a physical
> IS can announce...
>
> Alex
>
>
>

------_=_NextPart_001_01C20CC1.894C7168-- From Alex Zinin Wed Jun 5 20:15:41 2002 From: Alex Zinin (Alex Zinin) Date: Wed, 5 Jun 2002 12:15:41 -0700 Subject: [Isis-wg] last call on draft draft-ietf-isis-ext-lsp-frags-00 ... In-Reply-To: <4103264BC8D3D51180B7002048400C454FB6F7@zhard0jd.europe.nortel.com> References: <4103264BC8D3D51180B7002048400C454FB6F7@zhard0jd.europe.nortel.com> Message-ID: <16517384913.20020605121541@psg.com> Cool, why don't we use "extenSION LSPs" instead of "extenDED LSPs" then? Thanks! -- Alex Wednesday, June 05, 2002, 11:48:10 AM, you wrote: > To me an "extended" entity is the original entity plus an "extension". > I am currently planning an "extension" to my house, and after I have done it > then the entire house will be "extended". I guess that's why it is on my > mind. > So I think that these are "extension LSPs" or "expansion LSPs", or > something... > And I suppose that they have an "extension System Identifer" too... > Next time I'll read the draft before commenting on it :) > Hope that helps, Philip From mlu@chiaro.com Wed Jun 5 21:11:10 2002 From: mlu@chiaro.com (May Lu) Date: Wed, 5 Jun 2002 15:11:10 -0500 Subject: [Isis-wg] Question for HMAC-MD5 authentication Message-ID: <2383E22BDFF6D311BB8400B0D021A507CDD391@MAIL> --=_IS_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" In draft-ietf-isis-hmac-03.txt, the "Authentication Procedures" talked about how to calculate the authentication value. I need to conform the HMAC-MD5 validation. Here is what I though (authentication validation part only): When validate incoming LSP with HMAC-MD5 authentication TLV, the Checksum, Remaining Lifetime fields and the 16 bytes Authentication Value field in the authentication information tlv in the LSP are zeroed out first. The HMAC-MD5 algorithm takes a key and the modified LSP (length not modified) as input. The 16 byte result of the HMAC-MD5 algorithm is then compared with the original incoming authentication value. If all 16 bytes match, the authentication passed. Is this the right procedure? Thanks for your help. Xiaomei --=_IS_MIME_Boundary Content-Type: text/plain;charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline ----------------------------------------- (on Chiaro SMTP Relay) This e-mail and any files transmitted with it are the property of Chiaro Networks, Ltd., and may contain confidential and privileged material for the sole use of the intended recipient(s) to whom this e-mail is addressed. If you are not one of the named recipient(s), or otherwise have reason to believe that you have received this message in error, please notify the sender and delete all copies from your system. Any other use, retention, dissemination, forwarding, printing or copying of this e-mail is strictly prohibited. --------------------------------------------------------- --=_IS_MIME_Boundary-- From mlu@chiaro.com Thu Jun 6 15:16:18 2002 From: mlu@chiaro.com (May Lu) Date: Thu, 6 Jun 2002 09:16:18 -0500 Subject: [Isis-wg] FW: Question for HMAC-MD5 authentication Message-ID: <2383E22BDFF6D311BB8400B0D021A507CDD392@MAIL> --=_IS_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi Tony, I had a question about the HMAC-MD5. I sent a mail to the isis working group yesterday but I did not see this mail be distributed. So I am try again. Thanks in advance for your help. Xiaomei > -----Original Message----- > From: May Lu > Sent: Wednesday, June 05, 2002 3:11 PM > To: 'isis-wg@juniper.net' > Subject: Question for HMAC-MD5 authentication > > In draft-ietf-isis-hmac-03.txt, the "Authentication Procedures" talked > about how to calculate the authentication value. I need to conform the > HMAC-MD5 validation. Here is what I though (authentication validation part > only): > > When validate incoming LSP with HMAC-MD5 authentication TLV, the Checksum, > Remaining Lifetime fields and the 16 bytes Authentication Value field in > the authentication information tlv in the LSP are zeroed out first. The > HMAC-MD5 algorithm takes a key and the modified LSP (length not modified) > as input. The 16 byte result of the HMAC-MD5 algorithm is then compared > with the original incoming authentication value. If all 16 bytes match, > the authentication passed. > > Is this the right procedure? > > Thanks for your help. > Xiaomei > > > --=_IS_MIME_Boundary Content-Type: text/plain;charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline ----------------------------------------- (on Chiaro SMTP Relay) This e-mail and any files transmitted with it are the property of Chiaro Networks, Ltd., and may contain confidential and privileged material for the sole use of the intended recipient(s) to whom this e-mail is addressed. If you are not one of the named recipient(s), or otherwise have reason to believe that you have received this message in error, please notify the sender and delete all copies from your system. Any other use, retention, dissemination, forwarding, printing or copying of this e-mail is strictly prohibited. --------------------------------------------------------- --=_IS_MIME_Boundary-- From tli@procket.com Thu Jun 6 18:14:49 2002 From: tli@procket.com (Tony Li) Date: Thu, 6 Jun 2002 10:14:49 -0700 Subject: [Isis-wg] FW: Question for HMAC-MD5 authentication In-Reply-To: <2383E22BDFF6D311BB8400B0D021A507CDD392@MAIL> References: <2383E22BDFF6D311BB8400B0D021A507CDD392@MAIL> Message-ID: <15615.39049.805272.955628@alpha-tli.procket.com> Hi May, | I had a question about the HMAC-MD5. I sent a mail to the isis working group | yesterday but I did not see this mail be distributed. So I am try again. The mailing list will not redistribute your mail unless it recognizes you as a member of the mailing list. | > When validate incoming LSP with HMAC-MD5 authentication TLV, the Checksum, | > Remaining Lifetime fields and the 16 bytes Authentication Value field in | > the authentication information tlv in the LSP are zeroed out first. The | > HMAC-MD5 algorithm takes a key and the modified LSP (length not modified) | > as input. The 16 byte result of the HMAC-MD5 algorithm is then compared | > with the original incoming authentication value. If all 16 bytes match, | > the authentication passed. | > | > Is this the right procedure? Yup, sounds perfect. Tony From christi@nortelnetworks.com Tue Jun 11 15:38:38 2002 From: christi@nortelnetworks.com (Philip Christian) Date: Tue, 11 Jun 2002 15:38:38 +0100 Subject: [Isis-wg] Proprietary / Private TLV numbers? Message-ID: <4103264BC8D3D51180B7002048400C454FB70D@zhard0jd.europe.nortel.com> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C21155.37033688 Content-Type: text/plain; charset="iso-8859-1" First shot at a draft. Comments? Philip Internet Engineering Task Force P. Christian INTERNET DRAFT Nortel Networks June 2002 TLV for Proprietary Use draft-ietf-isis-private-tlv-forlist.txt Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or munnari.oz.au. A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested. This document will expire before December 2002. Distribution of this draft is unlimited. 1. Abstract This document defines a TLV that may be used by any individual, company or other organisation for vendor specific or experimental extensions to the IS-IS routing protocol, and defines the format of the TLV. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 3. Introduction IS-IS as defined in [1] has always been an extensible routing protocol. Extensions to IS-IS are encoded as a TLV. Critically [1] has always defined that a router that does not understand a TLV that it receives in an LSP SHALL process the parts of the LSP that it TLV for Proprietary Use June 2002 does understand, and SHALL flood the entire LSP, including all TLVs whether they are understand or not, on to other routers in the network. Thus information that is encoded into a TLV and placed in an LSP by a router will be propagated to every other router in an IS-IS level- 1 area or level-2 subdomain. The basic function of an IS-IS TLV is identified by the first byte of the TLV. Thus there are only 256 possible basic types of TLV. Certain types of TLV have been defined to include sub-TLVs so that a single TLV type can be used for multiple functions. No single authority assigns TLV type numbers, [2] lists all known TLV type numbers at this time. Also no TLV type number was ever defined for private, proprietary or experimental use. The extensible nature of IS-IS has made the use of TLVs in LSPs for proprietary purposes so useful that in the absence of a central authority for assigning TLV type numbers vendors have occasionally simply chosen a number and hoped for the best. The risk is that such a TLV type number may then be chosen by another organization at a later time for a different function, thus creating an interoperability problem. Also this accelerates the burning of the 256 possible TLV type numbers. This document specifies a TLV type number that may be used for proprietary, private or experimental purposes, and a mechanism that insures that implementations using this TLV type number can exist in the same network without creating interoperability problems. By using this new TLV, companies, individuals or institutions may use extensions to IS-IS without fear of interoperability problems with other organizations in the future, and the available pool of TLV type numbers will no longer be diminished by proprietary use. 4. TLV type number for proprietary use The type field for this TLV SHALL be XXX. TLVs that use XXX for the type field MUST include a valid IEEE assigned OUI as the first three bytes of the value of the TLV, except for the concession stated below. The rest of the value field may then be used freely. On receipt of an LSP a router MUST ignore TLVs of type XXX that include an OUI from a different organization, but MUST flood the LSP onwards as per [1]. Organizations or individuals that do not have access to an IEEE assigned OUI MAY use a locally assigned three byte value instead, however in this case the second least significant bit of the first TLV for Proprietary Use June 2002 byte MUST be set to one to indicate that it is non-IEEE assigned, and implementations that use such a non-IEEE assigned OUI SHOULD NOT be installed in the Internet. A non-IEEE assigned OUI does not guarantee uniqueness and may cause interoperability problems with implementations from other organizations. After the first three bytes of the value field of the TLV subsequent bytes may be used freely for any purpose provided that the resultant TLV is conformant with [1]. Many organizations will have access to only one or a few OUIs. Implementers are free to format the value field after their OUI into sub-TLVs so that it may be used for multiple purposes, and would be well advised to do this from the outset. Note that if subTLVs are to be used then the very first implementation to exist will need to recognize the subTLV structure, and ignore subTLVs that it does not understand whilst searching for subTLVs that it does understand. 5. Security Considerations The proprietary TLV raises no new security issues for IS-IS. Information placed in an IS-IS TLV cannot be considered secure, and so if security is required then an implementation will need to encrypt the information using a suitable method. 6. References [1] ISO, "Intermediate system to Intermediate system routeing information exchange protocol for use in conjunction with the Protocol for providing the Connectionless-mode Network Service (ISO 8473)", ISO/IEC 10589:1992. [2] draft-ietf-isis-wg-tlv-codepoints-02.txt, Reserved TLV Codepoints in ISIS, Tony Przygienda, November 2001 7. Acknowledgments The author takes no credit for this work as the concept was discussed in the IS-IS Working Group before the author even became an active participant. Suggestions for acknowledgement gladly received. 8. Author's Addresses Philip Christian Nortel Networks Harlow Laboratories London Road, Harlow, Essex, CM17 9NA UK Email: christi@nortelnetworks.com ------_=_NextPart_001_01C21155.37033688 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Isis-wg] Proprietary / Private TLV numbers?

First shot at a draft.  Comments?

Philip

Internet Engineering Task = Force           &= nbsp;           &= nbsp;    P. Christian
INTERNET = DRAFT           &= nbsp;           &= nbsp;           &= nbsp;      Nortel Networks
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;   June 2002
 
 
          &nb= sp;           &nb= sp;   TLV for Proprietary Use
          &nb= sp;          = draft-ietf-isis-private-tlv-forlist.txt
 
Status of this Memo
 
   This document is an Internet = Draft.  Internet Drafts are working
   documents of the Internet Engineering = Task Force (IETF), its Areas,
   and its Working Groups.  Note that = other groups may also distribute
   working documents as Internet Drafts. =
   
   Internet Drafts are draft documents = valid for a maximum of six
   months.  Internet Drafts may be = updated, replaced, or obsoleted by
   other documents at any time.  It = is not appropriate to use Internet
   Drafts as reference material or to cite = them other than as a
   "working draft" or "work = in progress".
   
   To learn the current status of any = Internet-Draft, please check the
   1id-abstracts.txt listing contained in = the Internet-Drafts Shadow
   Directories on ds.internic.net, = nic.nordu.net, ftp.isi.edu, or
   munnari.oz.au.
   
   A revised version of this draft = document will be submitted to the
   RFC editor as a Proposed Standard for = the Internet Community. 
   Discussion and suggestions for = improvement are requested.  This
   document will expire before December = 2002. Distribution of this
   draft is unlimited.
   
   
1. Abstract
   
   This document defines a TLV that may be = used by any individual,
   company or other organisation for = vendor specific or experimental
   extensions to the IS-IS routing = protocol, and defines the format of
   the TLV.
   
   
2. Conventions used in this document
   
   The key words "MUST", = "MUST NOT", "REQUIRED", "SHALL", = "SHALL NOT",
   "SHOULD", "SHOULD = NOT", "RECOMMENDED",  "MAY", and = "OPTIONAL" in
   this document are to be interpreted as = described in RFC 2119.
   
   
3. Introduction
   
   IS-IS as defined in [1] has always been = an extensible routing
   protocol.  Extensions to IS-IS are = encoded as a TLV.  Critically [1]
   has always defined that a router that = does not understand a TLV that
   it receives in an LSP SHALL process the = parts of the LSP that it
 
          &nb= sp;            = TLV for Proprietary = Use           &nb= sp;   June 2002
 
 
   does understand, and SHALL flood the = entire LSP, including all TLVs
   whether they are understand or not, on = to other routers in the
   network.
   
   Thus information that is encoded into a = TLV and placed in an LSP by
   a router will be propagated to every = other router in an IS-IS level-
   1 area or level-2 subdomain.
   
   The basic function of an IS-IS TLV is = identified by the first byte
   of the TLV.  Thus there are only = 256 possible basic types of TLV. 
   Certain types of TLV have been defined = to include sub-TLVs so that a
   single TLV type can be used for = multiple functions.
   
   No single authority assigns TLV type = numbers, [2] lists all known
   TLV type numbers at this time.  = Also no TLV type number was ever
   defined for private, proprietary or = experimental use.
   
   The extensible nature of IS-IS has made = the use of TLVs in LSPs for
   proprietary purposes so useful that in = the absence of a central
   authority for assigning TLV type = numbers vendors have occasionally
   simply chosen a number and hoped for = the best.  The risk is that
   such a TLV type number may then be = chosen by another organization at
   a later time for a different function, = thus creating an
   interoperability problem. Also this = accelerates the burning of the
   256 possible TLV type numbers.
   
   This document specifies a TLV type = number that may be used for
   proprietary, private or experimental = purposes, and a mechanism that
   insures that implementations using this = TLV type number can exist in
   the same network without creating = interoperability problems.
   
   By using this new TLV, companies, = individuals or institutions may
   use extensions to IS-IS without fear of = interoperability problems
   with other organizations in the future, = and the available pool of
   TLV type numbers will no longer be = diminished by proprietary use.
   
 
4. TLV type number for proprietary use
   
   The type field for this TLV SHALL be = XXX.
   
   TLVs that use XXX for the type field = MUST include a valid IEEE
   assigned OUI as the first three bytes = of the value of the TLV,
   except for the concession stated = below.  The rest of the value field
   may then be used freely.
   
   On receipt of an LSP a router MUST = ignore TLVs of type XXX that
   include an OUI from a different = organization, but MUST flood the LSP
   onwards as per [1].
   
   Organizations or individuals that do = not have access to an IEEE
   assigned OUI MAY use a locally assigned = three byte value instead,
   however in this case the second least = significant bit of the first
 
          &nb= sp;            = TLV for Proprietary = Use           &nb= sp;   June 2002
 
 
   byte MUST be set to one to indicate = that it is non-IEEE assigned,
   and implementations that use such a = non-IEEE assigned OUI SHOULD NOT
   be installed in the Internet.  A = non-IEEE assigned OUI does not
   guarantee uniqueness and may cause = interoperability problems with
   implementations from other = organizations.
   
   After the first three bytes of the = value field of the TLV subsequent
   bytes may be used freely for any = purpose provided that the resultant
   TLV is conformant with [1].
   
   Many organizations will have access to = only one or a few OUIs. 
   Implementers are free to format the = value field after their OUI into
   sub-TLVs so that it may be used for = multiple purposes, and would be
   well advised to do this from the = outset.  Note that if subTLVs are
   to be used then the very first = implementation to exist will need to
   recognize the subTLV structure, and = ignore subTLVs that it does not
   understand whilst searching for subTLVs = that it does understand.
   
   
5. Security Considerations
 
   The proprietary TLV raises no new = security issues for IS-IS. 
   Information placed in an IS-IS TLV = cannot be considered secure, and
   so if security is required then an = implementation will need to
   encrypt the information using a = suitable method.
   
   
6. References
   
   [1] ISO, "Intermediate system to = Intermediate system routeing
   information exchange protocol for use = in conjunction with the
   Protocol for providing the = Connectionless-mode Network Service (ISO
   8473)", ISO/IEC 10589:1992. =
   
   [2] = draft-ietf-isis-wg-tlv-codepoints-02.txt, Reserved TLV
   Codepoints in ISIS, Tony Przygienda, = November 2001
   
7. Acknowledgments
   
   The author takes no credit for this = work as the concept was
   discussed in the IS-IS Working Group = before the author even became
   an active participant.  = Suggestions for acknowledgement gladly
   received.
   
8. Author's Addresses
   
   Philip Christian
   Nortel Networks Harlow Laboratories =
   London Road, Harlow,
   Essex, CM17 9NA UK
   
   Email: christi@nortelnetworks.com =

 

------_=_NextPart_001_01C21155.37033688-- From mshand@cisco.com Tue Jun 11 15:55:33 2002 From: mshand@cisco.com (mike shand) Date: Tue, 11 Jun 2002 15:55:33 +0100 Subject: [Isis-wg] Proprietary / Private TLV numbers? In-Reply-To: <4103264BC8D3D51180B7002048400C454FB70D@zhard0jd.europe.nor tel.com> Message-ID: <4.3.2.7.2.20020611154537.025ce140@jaws.cisco.com> At 15:38 11/06/2002 +0100, Philip Christian wrote: >On receipt of an LSP a router MUST ignore TLVs of type XXX that > include an OUI from a different organization, MUST is a bit strong here. SHOULD or MAY, perhaps. If you know how to parse company X's subTLVs you should be allowed to do so. I'm not sure we want to get into mentioning non-standard OUIs with G or L bits set. Mike From jlearman@cisco.com Wed Jun 12 17:27:38 2002 From: jlearman@cisco.com (Jeff Learman) Date: Wed, 12 Jun 2002 12:27:38 -0400 Subject: [Isis-wg] Proprietary / Private TLV numbers? In-Reply-To: <4103264BC8D3D51180B7002048400C454FB710@zhard0jd.europe.nor tel.com> Message-ID: <4.3.2.7.2.20020612121454.01a53d48@dingdong.cisco.com> --=====================_55143622==_.ALT Content-Type: text/plain; charset="us-ascii" Minor comments below. At 08:33 AM 6/12/2002, Philip Christian wrote: >I have done an update, see below > >Philip > >> -----Original Message----- >> From: mike shand [mailto:mshand@cisco.com] >> Sent: Tuesday, June 11, 2002 3:56 PM >> To: Christian, Philip [HAL02:GI50:EXCH] >> Cc: 'Tony Przygienda'; isis-wg@spider.juniper.net; 'Mike Truskowski' >> Subject: RE: [Isis-wg] Proprietary / Private TLV numbers? >> >> >> At 15:38 11/06/2002 +0100, Philip Christian wrote: >> >On receipt of an LSP a router MUST ignore TLVs of type XXX that >> > include an OUI from a different organization, >> >> MUST is a bit strong here. SHOULD or MAY, perhaps. If you >> know how to parse >> company X's subTLVs you should be allowed to do so. >> >> I'm not sure we want to get into mentioning non-standard OUIs >> with G or L >> bits set. >> >> Mike >> >> > >Internet Engineering Task Force P. Christian >INTERNET DRAFT Nortel Networks > June 2002 > > > TLV for Proprietary Use > draft-ietf-isis-private-tlv-forlist2.txt > >Status of this Memo > > This document is an Internet-Draft and is in full conformance with > all provisions of Section 10 of RFC 2026. > > Internet Drafts are working documents of the Internet Engineering > Task Force (IETF), its Areas, and its Working Groups. Note that > other groups may also distribute working documents as Internet > Drafts. > > Internet Drafts are draft documents valid for a maximum of six > months. Internet Drafts may be updated, replaced, or obsoleted by > other documents at any time. It is not appropriate to use Internet > Drafts as reference material or to cite them other than as a > "working draft" or "work in progress". > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This memo provides information for the Internet community. This memo > does not specify an Internet standard of any kind. > > Distribution of this draft is unlimited. > > >1. Abstract > > This document defines a TLV that may be used for vendor specific or > experimental extensions to the IS-IS routing protocol, and defines > the format of the TLV. > > >2. Conventions used in this document > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in > this document are to be interpreted as described in RFC 2119. > > > > > > > TLV for Proprietary Use June 2002 > >3. Introduction > > IS-IS as defined in [1] has always been an extensible routing > protocol. Extensions to IS-IS are encoded as a TLV. Critically [1] > has always defined that an IS-IS router SHALL flood entire LSPs that > it receives on to other IS-IS routers in the network, whether or not > it understands the TLVs that are included in the LSP. Also IS-IS > LSPs are structured such that a router can find TLVs that it > understands, whilst ignoring ones that it does not. > > Thus information that is encoded into a TLV and placed into an LSP > by a router will be propagated to every other router in an IS-IS > level-1 area or level-2 subdomain. > > The basic function of an IS-IS TLV is identified by the first byte > of the TLV. Thus there are only 256 possible basic types of TLV. > Certain types of TLV have been defined to include sub-TLVs so that a > single TLV type can be used for multiple functions. > > No single authority assigns TLV type numbers, [2] lists all known use semicolon instead of comma above > TLV type numbers at this time. Also no TLV type number was ever > defined for private, proprietary or experimental use. > > The extensible nature of IS-IS has made the use of TLVs in LSPs for > proprietary purposes so useful that in the absence of a central > authority for assigning TLV type numbers vendors have occasionally > simply chosen a number and hoped for the best. The risk is that > such a TLV type number may then be chosen by another organization at > a later time for a different function, thus creating an > interoperability problem. Also this accelerates the burning of the "depletion" rather than "burning". > 256 possible TLV type numbers. > > This document specifies a TLV type number that may be used for > proprietary, private or experimental purposes, and a mechanism that > insures that implementations from different sources can use the TLV > for different purposes in the same network without creating > interoperability problems. > > By using this new TLV, companies, individuals or institutions may > use extensions to IS-IS without fear of interoperability problems > with other organizations in the future, and the available pool of > TLV type numbers will no longer be diminished by proprietary use. > >4. TLV type number for proprietary use > > The type field for this TLV SHALL be XXX. > > TLVs that use XXX for the type field MUST include a valid IEEE > assigned OUI as the first three bytes of the value field of the TLV. > For more information about OUIs see [3]. > > > > TLV for Proprietary Use June 2002 > > On receipt of an LSP a router MAY ignore TLVs of type XXX that > include an OUI from a different organization, however the router "unrecognized OUI" rather than "different organization". And I think "MAY" should be "MUST", but I won't quibble. > MUST flood the LSP onwards as per [1]. > > After the first three bytes of the value field subsequent bytes may > be used freely for any purpose provided that the resultant TLV is > conformant with [1]. I would say "The format of the remainder of the TLV would be defined by the identified organization, and MUST be conformant with [1]." > > Many organizations will have access to only one or a few OUIs. > Implementers are free to format the value field after their OUI into > sub-TLVs so that it may be used for multiple purposes, and would be > well advised to do this from the outset. Note that if sub-TLVs are > to be used then the very first implementation to exist will need to > recognize the sub-TLV structure, and ignore sub-TLVs that it does > not understand whilst searching for sub-TLVs that it does > understand. This is one way. Another way would be to use EUI48 or EUI64 numbers as type codes, especially for large organizations to allow hierarchical assignment of type codes. EUI numbers start with the OUI, and the remainder is allocated by the organization owning the OUI. Admittedly, this doesn't allow as optimized use of a switch statement as sub-TLVs would. Regards, Jeff > 5. Security Considerations > > The proprietary TLV raises no new security issues for IS-IS. > Information placed in an IS-IS TLV cannot be considered secure, and > so if security is required then an implementation will need to > encrypt the information using a suitable method. > >6. References > > [1] ISO, "Intermediate system to Intermediate system routeing > information exchange protocol for use in conjunction with the > Protocol for providing the Connectionless-mode Network Service (ISO > 8473)", ISO/IEC 10589:1992. > > [2] draft-ietf-isis-wg-tlv-codepoints-02.txt, Reserved TLV > Codepoints in ISIS, Tony Przygienda, November 2001 > > [3] http://standards.ieee.org/regauth/oui/index.html > >7. Acknowledgments > > The author takes no credit for this work as the concept was > discussed in the IS-IS Working Group before the author even became > an active participant. Suggestions for acknowledgement gladly > received. > >8. Author's Addresses > > Philip Christian > Nortel Networks Harlow Laboratories > London Road, Harlow, > Essex, CM17 9NA UK > > Email: christi@nortelnetworks.com --=====================_55143622==_.ALT Content-Type: text/html; charset="us-ascii"
Minor comments below.

At 08:33 AM 6/12/2002, Philip Christian wrote:

I have done an update, see below

Philip

> -----Original Message-----
> From: mike shand [mailto:mshand@cisco.com]
> Sent: Tuesday, June 11, 2002 3:56 PM
> To: Christian, Philip [HAL02:GI50:EXCH]
> Cc: 'Tony Przygienda'; isis-wg@spider.juniper.net; 'Mike Truskowski'
> Subject: RE: [Isis-wg] Proprietary / Private TLV numbers?
>
>
> At 15:38 11/06/2002 +0100, Philip Christian wrote:
> >On receipt of an LSP a router MUST ignore TLVs of type XXX that
> >    include an OUI from a different organization,
>
> MUST is a bit strong here. SHOULD or MAY, perhaps. If you
> know how to parse
> company X's subTLVs you should be allowed to do so.
>
> I'm not sure we want to get into mentioning non-standard OUIs
> with G or L
> bits set.
>
>          Mike
>
>

Internet Engineering Task Force                            P. Christian
INTERNET DRAFT                                          Nortel Networks
                                                              June 2002
 
 
                          TLV for Proprietary Use
                     draft-ietf-isis-private-tlv-forlist2.txt
 
Status of this Memo
 
   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.
   
   Internet Drafts are working documents of the Internet Engineering
   Task Force (IETF), its Areas, and its Working Groups.  Note that
   other groups may also distribute working documents as Internet
   Drafts.
   
   Internet Drafts are draft documents valid for a maximum of six
   months.  Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a
   "working draft" or "work in progress".
   
   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt
   
   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.
   
   This memo provides information for the Internet community. This memo
   does not specify an Internet standard of any kind. 
   
   Distribution of this draft is unlimited.
   
   
1. Abstract
   
   This document defines a TLV that may be used for vendor specific or
   experimental extensions to the IS-IS routing protocol, and defines
   the format of the TLV.
   
   
2. Conventions used in this document
   
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC 2119.
   




 
                       TLV for Proprietary Use               June 2002 
 
3. Introduction
   
   IS-IS as defined in [1] has always been an extensible routing
   protocol.  Extensions to IS-IS are encoded as a TLV.  Critically [1]
   has always defined that an IS-IS router SHALL flood entire LSPs that
   it receives on to other IS-IS routers in the network, whether or not
   it understands the TLVs that are included in the LSP.  Also IS-IS
   LSPs are structured such that a router can find TLVs that it
   understands, whilst ignoring ones that it does not.
   
   Thus information that is encoded into a TLV and placed into an LSP
   by a router will be propagated to every other router in an IS-IS
   level-1 area or level-2 subdomain.
   
   The basic function of an IS-IS TLV is identified by the first byte
   of the TLV.  Thus there are only 256 possible basic types of TLV. 
   Certain types of TLV have been defined to include sub-TLVs so that a
   single TLV type can be used for multiple functions.
   
   No single authority assigns TLV type numbers, [2] lists all known

use semicolon instead of comma above

   TLV type numbers at this time.  Also no TLV type number was ever
   defined for private, proprietary or experimental use.
   
   The extensible nature of IS-IS has made the use of TLVs in LSPs for
   proprietary purposes so useful that in the absence of a central
   authority for assigning TLV type numbers vendors have occasionally
   simply chosen a number and hoped for the best.  The risk is that
   such a TLV type number may then be chosen by another organization at
   a later time for a different function, thus creating an
   interoperability problem. Also this accelerates the burning of the

"depletion" rather than "burning".

   256 possible TLV type numbers.
   
   This document specifies a TLV type number that may be used for
   proprietary, private or experimental purposes, and a mechanism that
   insures that implementations from different sources can use the TLV
   for different purposes in the same network without creating
   interoperability problems.
   
   By using this new TLV, companies, individuals or institutions may
   use extensions to IS-IS without fear of interoperability problems
   with other organizations in the future, and the available pool of
   TLV type numbers will no longer be diminished by proprietary use.
   
4. TLV type number for proprietary use
   
   The type field for this TLV SHALL be XXX.
   
   TLVs that use XXX for the type field MUST include a valid IEEE
   assigned OUI as the first three bytes of the value field of the TLV. 
   For more information about OUIs see [3].
   

 
                       TLV for Proprietary Use               June 2002 
 
   On receipt of an LSP a router MAY ignore TLVs of type XXX that
   include an OUI from a different organization, however the router

"unrecognized OUI" rather than "different organization".  And I think
"MAY" should be "MUST", but I won't quibble.

   MUST flood the LSP onwards as per [1].
 
   After the first three bytes of the value field subsequent bytes may
   be used freely for any purpose provided that the resultant TLV is
   conformant with [1].

I would say "The format of the remainder of the TLV would be defined
by the identified organization, and MUST be conformant with [1]."

   
   Many organizations will have access to only one or a few OUIs. 
   Implementers are free to format the value field after their OUI into
   sub-TLVs so that it may be used for multiple purposes, and would be
   well advised to do this from the outset.  Note that if sub-TLVs are
   to be used then the very first implementation to exist will need to
   recognize the sub-TLV structure, and ignore sub-TLVs that it does
   not understand whilst searching for sub-TLVs that it does
   understand.

This is one way.  Another way would be to use EUI48 or EUI64 numbers
as type codes, especially for large organizations to allow hierarchical
assignment of type codes.  EUI numbers start with the OUI, and the
remainder is allocated by the organization owning the OUI.  Admittedly,
this doesn't allow as optimized use of a switch statement as sub-TLVs
would.

Regards,
Jeff

    5. Security Considerations
 
   The proprietary TLV raises no new security issues for IS-IS. 
   Information placed in an IS-IS TLV cannot be considered secure, and
   so if security is required then an implementation will need to
   encrypt the information using a suitable method.
   
6. References
   
   [1] ISO, "Intermediate system to Intermediate system routeing
   information exchange protocol for use in conjunction with the
   Protocol for providing the Connectionless-mode Network Service (ISO
   8473)", ISO/IEC 10589:1992.
   
   [2] draft-ietf-isis-wg-tlv-codepoints-02.txt, Reserved TLV
   Codepoints in ISIS, Tony Przygienda, November 2001
   
   [3] http://standards.ieee.org/regauth/oui/index.html
   
7. Acknowledgments
   
   The author takes no credit for this work as the concept was
   discussed in the IS-IS Working Group before the author even became
   an active participant.  Suggestions for acknowledgement gladly
   received.
   
8. Author's Addresses
   
   Philip Christian
   Nortel Networks Harlow Laboratories
   London Road, Harlow,
   Essex, CM17 9NA UK
   
   Email: christi@nortelnetworks.com
--=====================_55143622==_.ALT-- From wongkent@hotmail.com Wed Jun 12 20:38:21 2002 From: wongkent@hotmail.com (Kent Wong) Date: Wed, 12 Jun 2002 19:38:21 +0000 Subject: [Isis-wg] Questions and Comment on draft-ietf-isis-restart-01.txt Message-ID: Hi, I have some questions and comments on the isis restart draft: 1. On Page 6 "....a router MAY transmit one or more normal IIHs (containing a restart option, but with RR and RA clear) after the initial RR/RA exchange, but before synchronization has been achieved, in order to extend the holding time of the neighbors adjacencies, beyond that indicated in the remaining time field of the neighbors IIH with the RA bit set." When a router does this, should it also extend T3 to be the new holding time? Otherwise, even though we extend nbr's holding time for the adjacency, T3 will still expire in a short time and LSP with OL bit set will be generated and the graceful restart will fail anyway. 2. Instead of sending normal IIH after initial RR/RA exchange, would it make more sense that if this is a planned restart, a normal IIH with a large holding time is sent before the router going down so that nbr will hold the adjacency until restarting router finish the complete restart procedure. In that way, there is no need to send extra normal IIH after initial RR/RA exchange. 3. If T2 on both levels expires/cancelled, it means end of database resync and if T3 is still running, we should cancel T3 at this time. Is that correct? The draft did not say this explicitly. 4. On section 4.3.1.1, the draft mentions the behaviour of a router when it starts for the first time. Does it mean this draft intends to change the normal ISIS behaviour even though it is not a restart? That means we need to start T2 (but no T1, T3) for each level even we start for the first time. However, it may not be desirable to set the OL bit every time ISIS comes up. This should be decided by the network admin on individual cases whether to set the OL bit or not. 5. Just for clarification, in the draft, it mentions "own" LSP many times, sometimes it mention own non-pseudonode LSP, somes it mention own LSP including pseudonode. Sometimes, it simply mention "own" LSP. Should we interpretate the "own" LSP as including pseudonode LSP if it doesn't specify otherwise? Thanks! ---Kent Wong _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. From kentwong@stanfordalumni.org Wed Jun 12 21:53:14 2002 From: kentwong@stanfordalumni.org (Choto Wong) Date: Wed, 12 Jun 2002 20:53:14 -0000 Subject: [Isis-wg] Questions and Comment on draft-ietf-isis-restart-01.txt Message-ID: <20020612205314.7494.qmail@cmsweb26.cms.usa.net> Hi, I have some questions and comments on the isis restart draft: 1. On Page 6 "....a router MAY transmit one or more normal IIHs (containing a restart option, but with RR and RA clear) after the initial RR/RA exchange, but before synchronization has been achieved, in order to extend the holding time of the neighbors adjacencies, beyond that indicated in the remaining time field of the neighbors IIH with the RA bit set." When a router does this, should it also extend T3 to be the new holding time? Otherwise, even though we extend nbr's holding time for the adjacency, T3 will still expire in a short time and LSP with OL bit set will be generated and the graceful restart will fail anyway. 2. Instead of sending normal IIH after initial RR/RA exchange, would it make more sense that if this is a planned restart, a normal IIH with a large holding time is sent before the router going down so that nbr will hold the adjacency until restarting router finish the complete restart procedure. In that way, there is no need to send extra normal IIH after initial RR/RA exchange. 3. If T2 on both levels expires/cancelled, it means end of database resync and if T3 is still running, we should cancel T3 at this time. Is that correct? The draft did not say this explicitly. 4. On section 4.3.1.1, the draft mentions the behaviour of a router when it starts for the first time. Does it mean this draft intends to change the normal ISIS behaviour even though it is not a restart? That means we need to start T2 (but not T1, T3) for each level even we start for the first time. However, it may not be desirable to set the OL bit every time ISIS comes up. This should be decided by the network admin on individual cases whether to set the OL bit or not. 5. Just for clarification, in the draft, it mentions "own" LSP many times, sometimes it mention own non-pseudonode LSP, somes it mention own LSP including pseudonode. Sometimes, it simply mention "own" LSP. Should we interpretate the "own" LSP as including pseudonode LSP if it doesn't specify otherwise? Thanks! ---Kent Wong ____________________________________________________________________ From kentwong@stanfordalumni.org Thu Jun 13 02:54:28 2002 From: kentwong@stanfordalumni.org (Choto Wong) Date: Thu, 13 Jun 2002 01:54:28 -0000 Subject: [Isis-wg] Questions and comments on draft-ietf-isis-restart-01.txt Message-ID: <20020613015428.2923.qmail@uwdvg020.cms.usa.net> Hi, I have some questions and comments on the isis restart draft: 1. On Page 6 "....a router MAY transmit one or more normal IIHs (containing a restart option, but with RR and RA clear) after the initial RR/RA exchange, but before synchronization has been achieved, in order to extend the holding time of the neighbors adjacencies, beyond that indicated in the remaining time field of the neighbors IIH with the RA bit set." When a router does this, should it also extend T3 to be the new holding time? Otherwise, even though we extend nbr's holding time for the adjacency, T3 will still expire in a short time and LSP with OL bit set will be generated and the graceful restart will fail anyway. 2. Instead of sending normal IIH after initial RR/RA exchange, would it make more sense that if this is a planned restart, a normal IIH with a large holding time is sent before the router going down so that nbr will hold the adjacency until restarting router finishes the complete restart procedure. In that way, there is no need to send extra normal IIH after initial RR/RA exchange. 3. If T2 on both levels expires/cancelled, it means end of database resync and if T3 is still running, we should cancel T3 at this time. Is that correct? The draft did not say this explicitly. 4. Along the same line of thought, there is no need for a separate T2 and T3. Because when T2 expires/cancels before T3, T3 should be cancelled anyway. The only case T3 is supposed to be useful is when T3 expires before T2. The draft states that "If the timer T3 expires before all the T2 timers have expired, this indicates that the synchronization process is taking longer than minimum holding time of the neighbors. The router's own LSP(s) for levels which have not yet completed their first SPF computation are then flooded with the overload bit set to indicate that the router's LSPDB is not yet synchronized (and other routers should therefore not compute routes through this router)." However this assumes that the restarting router has acquired its own pre-start LSP before T3 expires. What if T3 expires even before it acquires its pre-start LSP? In that case, it doesn't know what sequence number it should use in its zero LSP to set the OL bit. If the seq num it uses is smaller than the seq num in its nbr's DB, then the zero LSP will be ignored by nbr anyway. So why not just combine T2 and T3 into a single timer and set the timer to be the min. remaining holding time of its nbr. If the timer expires before it DB re-sync, then graceful restart fails and everything reverts back to normal. Isn't this much more simpler and effective? 5. On section 4.3.1.1, the draft mentions the behavior of a router when it starts for the first time. Does it mean this draft intends to change the normal ISIS behavior even though it is not a restart? That means we need to start T2 (but no T1, T3) for each level even we start for the first time. However, it may not be desirable to set the OL bit every time ISIS comes up. This should be decided by the network admin on individual cases whether to set the OL bit or not. 6. Just for clarification, in the draft, it mentions "own" LSP many times, sometimes it mention own non-pseudonode LSP, sometimes it mention own LSP including pseudonode. Sometimes, it simply mention "own" LSP. Should we interpret the "own" LSP as including pseudonode LSP if it doesn't specify otherwise? Thanks! ---Kent Wong ____________________________________________________________________ From mshand@cisco.com Thu Jun 13 09:52:29 2002 From: mshand@cisco.com (mike shand) Date: Thu, 13 Jun 2002 09:52:29 +0100 Subject: [Isis-wg] Proprietary / Private TLV numbers? In-Reply-To: <4.3.2.7.2.20020612121454.01a53d48@dingdong.cisco.com> References: <4103264BC8D3D51180B7002048400C454FB710@zhard0jd.europe.nor tel.com> Message-ID: <4.3.2.7.2.20020613095137.00b730e0@jaws.cisco.com> At 12:27 12/06/2002 -0400, Jeff Learman wrote: >> TLV for Proprietary Use June 2002 >> >> On receipt of an LSP a router MAY ignore TLVs of type XXX that >> include an OUI from a different organization, however the router > >"unrecognized OUI" rather than "different organization". And I think >"MAY" should be "MUST", but I won't quibble. Yes, that's much better. Must ignore if you don't recognize. Mike From wongkent@hotmail.com Thu Jun 13 21:06:39 2002 From: wongkent@hotmail.com (Kent Wong) Date: Thu, 13 Jun 2002 20:06:39 +0000 Subject: [Isis-wg] Questions and comments on draft-ietf-isis-restart-01.txt Message-ID: Resent of e-mail because pervious e-mails were lost: ---------------------------------------------------- Hi, I have some questions and comments on the isis restart draft: 1. On Page 6 "....a router MAY transmit one or more normal IIHs (containing a restart option, but with RR and RA clear) after the initial RR/RA exchange, but before synchronization has been achieved, in order to extend the holding time of the neighbors adjacencies, beyond that indicated in the remaining time field of the neighbors IIH with the RA bit set." When a router does this, should it also extend T3 to be the new holding time? Otherwise, even though we extend nbr's holding time for the adjacency, T3 will still expire in a short time and LSP with OL bit set will be generated and the graceful restart will fail anyway. 2. Instead of sending normal IIH after initial RR/RA exchange, would it make more sense that if this is a planned restart, a normal IIH with a large holding time is sent before the router going down so that nbr will hold the adjacency until restarting router finishes the complete restart procedure. In that way, there is no need to send extra normal IIH after initial RR/RA exchange. 3. If T2 on both levels expires/cancelled, it means end of database resync and if T3 is still running, we should cancel T3 at this time. Is that correct? The draft did not say this explicitly. 4. Along the same line of thought, there is no need for a separate T2 and T3. Because when T2 expires/cancels before T3, T3 should be cancelled anyway. The only case T3 is supposed to be useful is when T3 expires before T2. The draft states that "If the timer T3 expires before all the T2 timers have expired, this indicates that the synchronization process is taking longer than minimum holding time of the neighbors. The router's own LSP(s) for levels which have not yet completed their first SPF computation are then flooded with the overload bit set to indicate that the router's LSPDB is not yet synchronized (and other routers should therefore not compute routes through this router)." However this assumes that the restarting router has acquired its own pre-start LSP before T3 expires. What if T3 expires even before it acquires its pre-start LSP? In that case, it doesn't know what sequence number it should use in its zero LSP to set the OL bit. If the seq num it uses is smaller than the seq num in its nbr's DB, then the zero LSP will be ignored by nbr anyway. So why not just combine T2 and T3 into a single timer and set the timer to be the min. remaining holding time of its nbr. If the timer expires before it DB re-sync, then graceful restart fails and everything reverts back to normal. Isn't this much more simpler and effective? 5. On section 4.3.1.1, the draft mentions the behavior of a router when it starts for the first time. Does it mean this draft intends to change the normal ISIS behavior even though it is not a restart? That means we need to start T2 (but no T1, T3) for each level even we start for the first time. However, it may not be desirable to set the OL bit every time ISIS comes up. This should be decided by the network admin on individual cases whether to set the OL bit or not. 6. Just for clarification, in the draft, it mentions "own" LSP many times, sometimes it mention own non-pseudonode LSP, sometimes it mention own LSP including pseudonode. Sometimes, it simply mention "own" LSP. Should we interpret the "own" LSP as including pseudonode LSP if it doesn't specify otherwise? Thanks! ---Kent Wong _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com From rja@extremenetworks.com Thu Jun 13 21:57:10 2002 From: rja@extremenetworks.com (RJ Atkinson) Date: Thu, 13 Jun 2002 16:57:10 -0400 Subject: [Isis-wg] Proprietary / Private TLV numbers? In-Reply-To: <4103264BC8D3D51180B7002048400C454FB710@zhard0jd.europe.nortel.com> Message-ID: <213ACF92-7F10-11D6-B00E-00039357A82A@extremenetworks.com> On Wednesday, June 12, 2002, at 08:33 , Philip Christian wrote: > 5. Security Considerations >   >    The proprietary TLV raises no new security issues for IS-IS.  Excuse me, but I don't think so. I think that it raises new security issues because different vendors might use it in different ways. In a multi-vendor environment there could be unintended consequences where A sends something with the new TLV that is syntactically valid with a different box B, but has unrelated semantics. Even if I'm confused, it is customary to outline *why* one thinks that no new security issues are raised, rather than making the assertion without supporting explanatory text. >    Information placed in an IS-IS TLV cannot be considered secure, You've not defined "secure". For "secure" == "authentic", then the IS-IS MD5 authentication can provide some security. If by "secure" you mean that "confidentiality" is provided, then please talk in terms of "confidentiality" rather than the vague term "secure". > and >    so if security is required then an implementation will need to >    encrypt the information using a suitable method. This also seems wrong. I'd suggest re-writing the whole section and in the re-write not using the word "secure" anyplace, instead using words like "integrity", "authentication", and/or "confidentiality" so that one's meaning is more crisp and clear. From wongkent@hotmail.com Fri Jun 14 06:53:42 2002 From: wongkent@hotmail.com (Kent Wong) Date: Fri, 14 Jun 2002 05:53:42 +0000 Subject: [Isis-wg] testing, please ignore Message-ID: _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com From mshand@cisco.com Fri Jun 14 08:33:31 2002 From: mshand@cisco.com (mike shand) Date: Fri, 14 Jun 2002 08:33:31 +0100 Subject: FW: [Isis-wg] I-D ACTION:draft-ietf-isis-interoperable-00.txt In-Reply-To: <20020613195021.6DFE43E0A@xmxpita.excite.com> Message-ID: <4.3.2.7.2.20020614082544.042183d0@jaws.cisco.com> 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 From jparker@axiowave.com Fri Jun 14 16:39:55 2002 From: jparker@axiowave.com (Jeff Parker) Date: Fri, 14 Jun 2002 11:39:55 -0400 Subject: FW: [Isis-wg] I-D ACTION:draft-ietf-isis-interoperable-00.txt Message-ID: 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" ? > > 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 > ..." ? > > 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 From wongkent@hotmail.com Fri Jun 14 19:03:09 2002 From: wongkent@hotmail.com (Kent Wong) Date: Fri, 14 Jun 2002 18:03:09 +0000 Subject: [Isis-wg] Comments on draft-ietf-isis-restart-01.txt Message-ID: Hi Mike, I have sent the following questions and comments for the isis restart draft on the ISIS mailing list a couple times but it never got through. So I am resending to your account directly in addition to the isis-wg account. Thanks! 1. On Page 6 "....a router MAY transmit one or more normal IIHs (containing a restart option, but with RR and RA clear) after the initial RR/RA exchange, but before synchronization has been achieved, in order to extend the holding time of the neighbors adjacencies, beyond that indicated in the remaining time field of the neighbors IIH with the RA bit set." When a router does this, should it also extend T3 to be the new holding time? Otherwise, even though we extend nbr's holding time for the adjacency, T3 will still expire in a short time and LSP with OL bit set will be generated and the graceful restart will fail anyway. 2. Instead of sending normal IIH after initial RR/RA exchange, would it make more sense that if this is a planned restart, a normal IIH with a large holding time is sent before the router going down so that nbr will hold the adjacency until restarting router finishes the complete restart procedure. In that way, there is no need to send extra normal IIH after initial RR/RA exchange. 3. If T2 on both levels expires/cancelled, it means end of database resync and if T3 is still running, we should cancel T3 at this time. Is that correct? The draft did not say this explicitly. 4. Along the same line of thought, there is no need for a separate T2 and T3. Because when T2 expires/cancels before T3, T3 should be cancelled anyway. The only case T3 is supposed to be useful is when T3 expires before T2. The draft states that "If the timer T3 expires before all the T2 timers have expired, this indicates that the synchronization process is taking longer than minimum holding time of the neighbors. The router's own LSP(s) for levels which have not yet completed their first SPF computation are then flooded with the overload bit set to indicate that the router's LSPDB is not yet synchronized (and other routers should therefore not compute routes through this router)." However this assumes that the restarting router has acquired its own pre-start LSP before T3 expires. What if T3 expires even before it acquires its pre-start LSP? In that case, it doesn't know what sequence number it should use in its zero LSP to set the OL bit. If the seq num it uses is smaller than the seq num in its nbr's DB, then the zero LSP will be ignored by nbr anyway. So why not just combine T2 and T3 into a single timer and set the timer to be the min. remaining holding time of its nbr. If the timer expires before it DB re-sync, then graceful restart fails and everything reverts back to normal. Isn't this much more simpler and effective? 5. On section 4.3.1.1, the draft mentions the behavior of a router when it starts for the first time. Does it mean this draft intends to change the normal ISIS behavior even though it is not a restart? That means we need to start T2 (but no T1, T3) for each level even we start for the first time. However, it may not be desirable to set the OL bit every time ISIS comes up. This should be decided by the network admin on individual cases whether to set the OL bit or not. 6. Just for clarification, in the draft, it mentions "own" LSP many times, sometimes it mention own non-pseudonode LSP, sometimes it mention own LSP including pseudonode. Sometimes, it simply mention "own" LSP. Should we interpret the "own" LSP as including pseudonode LSP if it doesn't specify otherwise? Thanks! ---Kent Wong _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com From wongkent@hotmail.com Tue Jun 18 01:40:50 2002 From: wongkent@hotmail.com (Kent Wong) Date: Tue, 18 Jun 2002 00:40:50 +0000 Subject: [Isis-wg] draft-ietf-isis-restart-01.txt [continued] Message-ID: Hi, Some more questions on the draft: 4. I don't understand why there is a need for two different timers T2 and T3. Because when T2 expires/cancels before T3, T3 should be cancelled anyway. The only case T3 is supposed to be useful is when T3 expires before T2. The draft states that if T3 expires before T2, router's own LSP for level which have not completed their first SPF should be flooded with the OL bit set. However this assumes that the restarting router has acquired its own pre-start LSP before T3 expires. What if T3 expires even before it acquires its pre-start LSP? In that case, it doesn't know what sequence number it should use in its zero LSP to set the OL bit. If the seq num it uses is smaller than the seq num in its nbr's DB, then the zero LSP will be ignored by the helper nbr anyway. So why not just combine T2 and T3 into a single timer and set the timer to be the min. remaining holding time of its nbrs. If the timer expires before it DB re-sync, then graceful restart fails and everything reverts back to normal. Isn't this much more simpler and effective? 5. On section 4.3.1.1, the draft mentions the behavior of a router when it starts for the first time. Does it mean this draft intends to change the normal ISIS behavior even though it is not a restart? That means we need to start T2 (but no T1, T3) for each level even we start for the first time. However, it may not be desirable to set the OL bit every time ISIS comes up. This should be decided by the network admin on individual cases whether to set the OL bit or not. 6. Just for clarification, in the draft, it mentions "own" LSP many times, sometimes it mention own non-pseudonode LSP, sometimes it mention own LSP including pseudonode. Sometimes, it simply mention "own" LSP. Should we interpret the "own" LSP as including pseudonode LSP if it doesn't specify otherwise? Thanks! Kent Wong _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From mshand@cisco.com Tue Jun 18 10:29:48 2002 From: mshand@cisco.com (mike shand) Date: Tue, 18 Jun 2002 10:29:48 +0100 Subject: [Isis-wg] draft-ietf-isis-restart-01.txt In-Reply-To: Message-ID: <4.3.2.7.2.20020618102504.04395e78@jaws.cisco.com> At 22:25 17/06/2002 +0000, Kent Wong wrote: >Hi, > >I have some questions and comments on the isis restart draft: > >1. On Page 6 >"....a router MAY transmit one or more normal IIHs >(containing a restart option, but with RR and RA clear) after the >initial RR/RA exchange, but before synchronization has been >achieved, in order to extend the holding time of the neighbors >adjacencies, beyond that indicated in the remaining time field of >the neighbors IIH with the RA bit set." > >When a router does this, should it also extend T3 to be the new >holding time? Otherwise, even though we extend nbr's holding time >for the adjacency, T3 will still expire in a short time and LSP >with OL bit set will be generated and the graceful restart will >fail anyway. Yes. That was the assumption. Sorry that wasn't made clear. >2. Instead of sending normal IIH after initial RR/RA exchange, >would it make more sense that if this is a planned restart, >a normal IIH with a large holding time is sent before the router >going down so that nbr will hold the adjacency until restarting >router finishes the complete restart procedure. In that way, there >is no need to send extra normal IIH after initial RR/RA exchange. Yes that is possible too. My take on this is that the protocol mechanisms described in the spec can be used in a variety of creative ways which do not necessarily need to be spelled out in the draft because they do not require explicit co-operation. This is an example of such a mechanism. >3. If T2 on both levels expires/cancelled, it means end of >database resync and if T3 is still running, we should cancel >T3 at this time. Is that correct? The draft did not say this explicitly. Yes. >Thanks. > >Kent Wong > >_________________________________________________________________ >MSN Photos is the easiest way to share and print your photos: >http://photos.msn.com/support/worldwide.aspx > >_______________________________________________ >Isis-wg mailing list - Isis-wg@spider.juniper.net >http://spider.juniper.net/mailman/listinfo/isis-wg From Russ White Tue Jun 18 11:59:10 2002 From: Russ White (Russ White) Date: Tue, 18 Jun 2002 06:59:10 -0400 (EDT) Subject: [Isis-wg] draft-ietf-isis-restart-01.txt In-Reply-To: Message-ID: > 1. On Page 6 > "....a router MAY transmit one or more normal IIHs > (containing a restart option, but with RR and RA clear) after the > initial RR/RA exchange, but before synchronization has been > achieved, in order to extend the holding time of the neighbors > adjacencies, beyond that indicated in the remaining time field of > the neighbors IIH with the RA bit set." > > When a router does this, should it also extend T3 to be the new > holding time? Otherwise, even though we extend nbr's holding time > for the adjacency, T3 will still expire in a short time and LSP > with OL bit set will be generated and the graceful restart will > fail anyway. Yes, that seems logical. > 2. Instead of sending normal IIH after initial RR/RA exchange, > would it make more sense that if this is a planned restart, > a normal IIH with a large holding time is sent before the router > going down so that nbr will hold the adjacency until restarting > router finishes the complete restart procedure. In that way, there > is no need to send extra normal IIH after initial RR/RA exchange. You could do this, though there's no reason to specify it, I don't think (?). > 3. If T2 on both levels expires/cancelled, it means end of > database resync and if T3 is still running, we should cancel > T3 at this time. Is that correct? The draft did not say this explicitly. Yes, this should be correct. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone From wongkent@hotmail.com Tue Jun 18 19:39:42 2002 From: wongkent@hotmail.com (Kent Wong) Date: Tue, 18 Jun 2002 18:39:42 +0000 Subject: [Isis-wg] draft-ietf-isis-restart-01.txt Message-ID: Hi Mike and Russ, Thanks for your reply. I have a couple more comments on the draft: 4. I don't understand why there is a need for two different timers T2 and T3. Because when T2 expires/cancels before T3, T3 would be cancelled anyway. The only case T3 is supposed to be useful is when T3 expires before T2. The draft states that if T3 expires before T2, router's own LSP for level which have not completed their first SPF should be flooded with the OL bit set. However this assumes that the restarting router has acquired its own pre-start LSP before T3 expires. What if T3 expires even before it acquires its pre-start LSP? In that case, it doesn't know what sequence number it should use in its zero LSP to set the OL bit. If the seq num it uses is smaller than the seq num in its nbr's DB, then the zero LSP will be ignored by the helper nbr anyway. So why not just combine T2 and T3 into a single timer and set the timer to be the min. remaining holding time of its nbrs. If the timer expires before it DB re-sync, then graceful restart fails and everything reverts back to normal. Isn't this much more simpler and effective? 5. On section 4.3.1.1, the draft mentions the behavior of a router when it starts for the first time. Does it mean this draft intends to change the normal ISIS behavior even though it is not a restart? That means we need to start T2 (but no T1, T3) for each level even we start for the first time. However, it may not be desirable to set the OL bit every time ISIS comes up. This should be decided by the network admin on individual cases whether to set the OL bit or not. 6. Just for clarification, in the draft, it mentions "own" LSP many times, sometimes it mention own non-pseudonode LSP, sometimes it mention own LSP including pseudonode. Sometimes, it simply mention "own" LSP. Should we interpret the "own" LSP as including pseudonode LSP if it doesn't specify otherwise? Thanks! Kent Wong >From: mike shand >To: "Kent Wong" >CC: isis-wg@spider.juniper.net >Subject: Re: [Isis-wg] draft-ietf-isis-restart-01.txt >Date: Tue, 18 Jun 2002 10:29:48 +0100 > >At 22:25 17/06/2002 +0000, Kent Wong wrote: >>Hi, >> >>I have some questions and comments on the isis restart draft: >> >>1. On Page 6 >>"....a router MAY transmit one or more normal IIHs >>(containing a restart option, but with RR and RA clear) after the >>initial RR/RA exchange, but before synchronization has been >>achieved, in order to extend the holding time of the neighbors >>adjacencies, beyond that indicated in the remaining time field of >>the neighbors IIH with the RA bit set." >> >>When a router does this, should it also extend T3 to be the new >>holding time? Otherwise, even though we extend nbr's holding time >>for the adjacency, T3 will still expire in a short time and LSP >>with OL bit set will be generated and the graceful restart will >>fail anyway. > >Yes. That was the assumption. Sorry that wasn't made clear. > > >>2. Instead of sending normal IIH after initial RR/RA exchange, >>would it make more sense that if this is a planned restart, >>a normal IIH with a large holding time is sent before the router >>going down so that nbr will hold the adjacency until restarting >>router finishes the complete restart procedure. In that way, there >>is no need to send extra normal IIH after initial RR/RA exchange. > >Yes that is possible too. My take on this is that the protocol mechanisms >described in the spec can be used in a variety of creative ways which do >not necessarily need to be spelled out in the draft because they do not >require explicit co-operation. This is an example of such a mechanism. > > >>3. If T2 on both levels expires/cancelled, it means end of >>database resync and if T3 is still running, we should cancel >>T3 at this time. Is that correct? The draft did not say this explicitly. > >Yes. > >>Thanks. >> >>Kent Wong >> >>_________________________________________________________________ >>MSN Photos is the easiest way to share and print your photos: >>http://photos.msn.com/support/worldwide.aspx >> >>_______________________________________________ >>Isis-wg mailing list - Isis-wg@spider.juniper.net >>http://spider.juniper.net/mailman/listinfo/isis-wg > _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com From jparker@axiowave.com Tue Jun 18 21:14:00 2002 From: jparker@axiowave.com (Jeff Parker) Date: Tue, 18 Jun 2002 16:14:00 -0400 Subject: [Isis-wg] IS-IS MIB Message-ID: > VM> Maybe the remaining lifetime could be given too. > Remaining lifetime is > used to identify an instance too, one with 0 Remaininglifetime and one > without are different instances. No. Two LSPs with different remaining lifetimes could be the same. The sequence number is what counts. - jdp From naiming@redback.com Tue Jun 18 23:40:27 2002 From: naiming@redback.com (Naiming Shen) Date: Tue, 18 Jun 2002 15:40:27 -0700 Subject: [Isis-wg] draft-ietf-isis-restart-01.txt In-Reply-To: Mail from mike shand dated Fri, 24 May 2002 09:20:07 BST <4.3.2.7.2.20020524091256.04406478@jaws.cisco.com> Message-ID: <20020618224027.D497E39B5BC@prattle.redback.com> Mike, ] I have retained the non-timer resetting behavior of the RR IIH because I ] think it is useful in some cases but have noted that if you want the ] resetting behavior you can easily get this by sending a normal IIH once you ] have acquired the necessary circuit IDs etc. So the way it would work is ] that you would re-start and get back the remaining time on each adjacency. ] If this is plenty of time you just carry on as normal. If you feel you need ] more time (and you are configured to allow that), then you send an IIH with ] the required holding time. I still have problem of this. yes, you may be able to send out "normal" IIHs with large holdtime, but that's an extra step. i don't see much reasoning this step is needed; Also more importantly, you may not be able to send this "normal" IIH over a LAN unless you are sure you got all the neighbors without missing one. this is too much dependancy without benefit. I can understand you don't want to change the current tlv format, since it's out there for a while and there may be some implementations running which can cause incompatibility. I would say let's just keep this format. the helper still send back whatever it thinks the holdtime is for this adjacency. We at least need to say that, if the implementation choose to ignore the holdtime in the re-start IIH, it SHOULD offer a config knob so this can be disabled when needed. This way ISPs can make sure its consistant within the network. We have already seen some implementation does NOT ignore this holdtime at least for the first re-start IIH. ] ] Similarly, I have retained the retries, but said that you may ] configurea retry count of zero. This does not matter too much comparing to the above. this is basically a local implementation issue. Probably should mentioning the p2p vs LAN problems here. thanks. - Naiming From Internet-Drafts@ietf.org Wed Jun 19 12:27:53 2002 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Wed, 19 Jun 2002 07:27:53 -0400 Subject: [Isis-wg] I-D ACTION:draft-ash-ospf-isis-congestion-control-02.txt Message-ID: <200206191127.HAA13572@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Proposed Mechanisms for Congestion Control/Failure Recovery in OSPF & ISIS Networks Author(s) : J. Ash et al. Filename : draft-ash-ospf-isis-congestion-control-02.txt Pages : Date : 18-Jun-02 Earlier papers and contributions identified issues of congestion control and failure recovery for link-state protocol networks, such as OSPF, ISIS, and PNNI networks [maunder, choudhury, pappalardo1, pappalardo2, atm01-0101]. The problem addressed is to enable link-state protocols to a) gracefully recover from massive loss of topology database information, and b) respond gracefully to network overloads and failures. This contribution proposes specific additional considerations for network congestion control/failure recovery. Candidate mechanisms are proposed for control of network congestion and failure recovery, in particular we initially propose to investigate the following mechanisms: a) throttle new connection setups, topology-state updates, and Hello updates based on automatic congestion control mechanisms, b) special marking of critical control messages (e.g., Hello and topology-state-update Ack) so that they may receive prioritized processing, c) database backup, in which a topology database could be automatically recovered from loss based on local backup mechanisms, and d) hitless restart, which allows routes to continue to be used if there is an uninterrupted data path, even if the control path is interrupted due to a failure. We propose that the OSPF and ISIS working groups include the candidate mechanisms in an evaluation of congestion control/failure recovery for OSPF and ISIS networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ash-ospf-isis-congestion-control-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ash-ospf-isis-congestion-control-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ash-ospf-isis-congestion-control-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020618132155.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ash-ospf-isis-congestion-control-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ash-ospf-isis-congestion-control-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020618132155.I-D@ietf.org> --OtherAccess-- --NextPart-- From wongkent@hotmail.com Thu Jun 20 02:37:25 2002 From: wongkent@hotmail.com (Kent Wong) Date: Thu, 20 Jun 2002 01:37:25 +0000 Subject: [Isis-wg] More comments on draft-ietf-isis-restart-01.txt Message-ID: Hi, Sorry if you got this e-mail more than once. I have trouble sending the e-mail to the ISIS WG mailing list. Some more comments on the draft: 1. On page 8, the draft states that SPF should not be run when T3 is running. But on page 9, it says that if T3 expires before T2, the level which have not completed their first SPF run should generate LSP with OL bit set. But no level will run their SPF before T3 expires anyway. Should this be interpreted as "level of which T2 is still running should generate their LSP with OL bit set"? 2. Along the same line of thought, I still don't understand why we need two different timers T2 and T3. When T2 finishes, T3 would be cancelled anyway. The only case T3 is supposed to be useful is if it expires before T2, the restarting router is supposed to generate own LSP with OL bit set. However, this assumes that the restarting router has acquired its own pre-start LSP before T3 expires. If not, what should the seq number it use to generate the zeroth LSP with OL bit set? If the seq num it uses in zeroth LSP is smaller than the nbr's DB copy, the zeroth LSP will be ignored by helper nbr anyway. So why not just combine T2 and T3 into a single timer per level and set the timer to be the min. remaining holding time of its nbr. If the timer expires before the DB re-sync finishes, then graceful restart fails and everything reverts back to normal. Isn't this much much simpler and effective? Thanks. Kent Wong _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. From amir@cwnt.com Thu Jun 20 10:38:55 2002 From: amir@cwnt.com (Amir Hermelin) Date: Thu, 20 Jun 2002 12:38:55 +0300 Subject: [Isis-wg] ISIS drafts status summary ... Message-ID: >> 1. draft-ietf-isis-ext-lsp-frags-00 last call ended >5/22/02. I still see comments on the list. >> From that I deduct last call is going on > >Amir and I exchanged a couple of messages off the list and I think the >discussion converged. Unless there were more comments besides mine, I >think we're expecting a new version. > I have an -01 version which only includes editorial changes and clarifications. Since the draft was on its way to AD already, what should I do with it (already sent to wg chairs)? -- Amir Hermelin < mailto:amir@cwnt.com> Charlotte's Web Networks Inc. < http://www.cwnt.com> From Alex Zinin Thu Jun 20 20:44:47 2002 From: Alex Zinin (Alex Zinin) Date: Thu, 20 Jun 2002 12:44:47 -0700 Subject: [Isis-wg] ISIS drafts status summary ... In-Reply-To: References: Message-ID: <1964104999.20020620124447@psg.com> Amir, I could do a quick review to make sure we haven't forgotten anything and then you will need to send the new version to internet-drafts. -- Alex Thursday, June 20, 2002, 2:38:55 AM, you wrote: >>> 1. draft-ietf-isis-ext-lsp-frags-00 last call ended >>5/22/02. I still see comments on the list. >>> From that I deduct last call is going on >> >>Amir and I exchanged a couple of messages off the list and I think the >>discussion converged. Unless there were more comments besides mine, I >>think we're expecting a new version. >> > I have an -01 version which only includes editorial changes and clarifications. Since the draft was on its way to AD already, what should I do with it (already sent to wg chairs)? > -- > Amir Hermelin < mailto:amir@cwnt.com> > Charlotte's Web Networks Inc. < http://www.cwnt.com> From jparker@axiowave.com Thu Jun 20 21:35:31 2002 From: jparker@axiowave.com (Jeff Parker) Date: Thu, 20 Jun 2002 16:35:31 -0400 Subject: [Isis-wg] Alternative Multicast Addresses for IS-IS Message-ID: 10589 defined an alternative set of multicast MAC addresses to be used on Token Ring, and warned the administrator to use these addresses with caution. (8.4.8) The new draft of 10589 drops this section. The MIB includes a knob to pick which set of addresses to use. Does anyone use the Token Ring set, or can we drop this knob? - jeff parker - axiowave networks - "Error, No Keyboard - Press F1 to continue" From amir@cwnt.com Thu Jun 20 22:13:05 2002 From: amir@cwnt.com (Amir Hermelin) Date: Fri, 21 Jun 2002 00:13:05 +0300 Subject: [Isis-wg] ISIS drafts status summary ... Message-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C2189F.450E745A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Here 'ya go - since these are mostly editorial/clarifications, I hope we = don't go into another couple of months worth of last calling it = (technical comments were all done 'bout 3-4 months ago..) thanks. -- Amir Hermelin < mailto:amir@cwnt.com> Charlotte's Web Networks Inc. < http://www.cwnt.com> >-----Original Message----- >From: Alex Zinin [mailto:zinin@psg.com] >Sent: Thursday, June 20, 2002 10:45 PM >To: Amir Hermelin >Cc: Tony Przygienda; isis-wg@juniper.net; Alex Zinin; Bill=20 >Fenner; David Ward; Tony Li >Subject: Re: [Isis-wg] ISIS drafts status summary ... > > >Amir, > > I could do a quick review to make sure we haven't > forgotten anything and then you will need to send > the new version to internet-drafts. > >--=20 >Alex > >Thursday, June 20, 2002, 2:38:55 AM, you wrote: >>>> 1. draft-ietf-isis-ext-lsp-frags-00 last call ended=20 >>>5/22/02. I still see comments on the list. >>>> From that I deduct last call is going on >>> >>>Amir and I exchanged a couple of messages off the list and I=20 >think the >>>discussion converged. Unless there were more comments besides mine, I >>>think we're expecting a new version. >>> > >> I have an -01 version which only includes editorial changes=20 >and clarifications. Since the draft was on its way to AD=20 >already, what should I do with it (already sent to wg chairs)? > >> -- >> Amir Hermelin < mailto:amir@cwnt.com> >> Charlotte's Web Networks Inc. < http://www.cwnt.com> > > > ------_=_NextPart_001_01C2189F.450E745A Content-Type: text/plain; name="draft-ietf-isis-ext-lsp-frags-01.txt" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-isis-ext-lsp-frags-01.txt Content-Disposition: attachment; filename="draft-ietf-isis-ext-lsp-frags-01.txt" DQoNCg0KDQoNCg0KTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBBbWlyIEhlcm1lbGluDQpJbnRlcm5ldCBEcmFmdCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBDaGFybG90dGUncyBXZWIgTmV0d29ya3MNCkV4cGlyYXRpb24g RGF0ZTogRGVjZW1iZXIgMjAwMg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgU3RlZmFubyBQcmV2aWRpDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1pa2UgU2hhbmQNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Q2lzY28gU3lzdGVtcw0KDQoNCiAgICBFeHRlbmRpbmcgdGhlIE51bWJlciBvZiBJUy1JUyBMU1Ag RnJhZ21lbnRzIEJleW9uZCB0aGUgMjU2IExpbWl0DQoNCiAgICAgICAgICAgICAgICAgIGRyYWZ0 LWlldGYtaXNpcy1leHQtbHNwLWZyYWdzLTAxLnR4dA0KDQoNCg0KU3RhdHVzDQoNCiAgIFRoaXMg ZG9jdW1lbnQgaXMgYW4gSW50ZXJuZXQtRHJhZnQgYW5kIGlzIGluIGZ1bGwgY29uZm9ybWFuY2Ug d2l0aA0KICAgYWxsIHByb3Zpc2lvbnMgb2YgU2VjdGlvbiAxMCBvZiBSRkMyMDI2Lg0KDQogICBJ bnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdp bmVlcmluZw0KICAgVGFzayBGb3JjZSAoSUVURiksIGl0cyBhcmVhcywgYW5kIGl0cyB3b3JraW5n IGdyb3Vwcy4gIE5vdGUgdGhhdA0KICAgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUg d29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtDQogICBEcmFmdHMuDQoNCiAgIEludGVybmV0 LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1v bnRocw0KICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90 aGVyIGRvY3VtZW50cyBhdCBhbnkNCiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVz ZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlDQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRo ZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iDQoNCiAgIFRoZSBsaXN0IG9mIGN1 cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgaHR0cDovL3d3dy5p ZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0DQoNCiAgIFRoZSBsaXN0IG9mIEludGVybmV0 LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6Ly93 d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuDQoNCg0KQWJzdHJhY3QNCg0KICAgVGhpcyBkb2N1bWVu dCBkZXNjcmliZXMgYSBtZWNoYW5pc20gdGhhdCBhbGxvd3MgYSBzeXN0ZW0gdG8gb3JpZ2luYXRl DQogICBtb3JlIHRoYW4gMjU2IExTUCBmcmFnbWVudHMsIGEgbGltaXQgc2V0IGJ5IHRoZSBvcmln aW5hbCBJbnRlcm1lZGlhdGUNCiAgIFN5c3RlbSB0byBJbnRlcm1lZGlhdGUgU3lzdGVtIChJUy1J UykgUm91dGluZyBwcm90b2NvbCwgYXMgZGVzY3JpYmVkDQogICBpbiBJU08gMTA1ODkuICBUaGlz IG1lY2hhbmlzbSBjYW4gYmUgdXNlZCBpbiBJUC1vbmx5LCBPU0ktb25seSwgYW5kDQogICBkdWFs IHJvdXRlcnMuDQoNCg0KDQoNCg0KDQoNCkEuIEhlcm1lbGluLCBldCBhbC4gICAgICAgRXhwaXJl cyBEZWNlbWJlciAyMDAyICAgICAgICAgICAgICAgICBbUGFnZSAxXQ0KDA0KSW50ZXJuZXQgRHJh ZnQgICAgZHJhZnQtaWV0Zi1pc2lzLWV4dC1sc3AtZnJhZ3MtMDEudHh0ICAgICAgICAgSnVuZSAy MDAyDQoNCg0KMS4gIEludHJvZHVjdGlvbg0KDQogICBJbiB0aGUgSVMtSVMgcHJvdG9jb2wsIGEg c3lzdGVtIGZsb29kcyBpdHMgbGluay1zdGF0ZSBpbmZvcm1hdGlvbiBpbg0KICAgTGluayBTdGF0 ZSBQcm90b2NvbCBEYXRhIFVuaXRzLCBvciBMU1BzIGZvciBzaG9ydC4gIFRoZXNlIGxvZ2ljYWwN CiAgIExTUHMgY2FuIGJlY29tZSBxdWl0ZSBsYXJnZSwgdGhlcmVmb3JlIHRoZSBwcm90b2NvbCBz cGVjaWZpZXMgYSBtZWFucw0KICAgb2YgZnJhZ21lbnRpbmcgdGhpcyBpbmZvcm1hdGlvbiBpbnRv IG11bHRpcGxlIExTUCBmcmFnbWVudHMuICBUaGUNCiAgIG51bWJlciBvZiBmcmFnbWVudHMgYSBz eXN0ZW0gY2FuIGdlbmVyYXRlIGlzIGxpbWl0ZWQgYnkgSVNPIDEwNTg5DQogICBbSVNJUy1JU09d IHRvIDI1NiBmcmFnbWVudHMsIHdoZXJlIGVhY2ggZnJhZ21lbnQncyBzaXplIGlzIGFsc28NCiAg IGxpbWl0ZWQuICBIZW5jZSwgdGhlcmUgaXMgYSBsaW1pdCBvbiB0aGUgYW1vdW50IG9mIGxpbmst c3RhdGUNCiAgIGluZm9ybWF0aW9uIGEgc3lzdGVtIGNhbiBnZW5lcmF0ZS4NCg0KICAgQSBudW1i ZXIgb2YgZmFjdG9ycyBjYW4gY29udHJpYnV0ZSB0byBleGNlZWRpbmcgdGhpcyBsaW1pdDoNCiAg ICAgLSAgSW50cm9kdWN0aW9uIG9mIG5ldyBUTFZzIGFuZCBzdWItVExWcyB0byBiZSBpbmNsdWRl ZCBpbiBMU1BzLg0KICAgICAtICBUaGUgdXNlIG9mIExTUHMgdG8gcHJvcGFnYXRlIHZhcmlvdXMg dHlwZXMgb2YgaW5mb3JtYXRpb24gKHN1Y2gNCiAgICAgYXMgdHJhZmZpYy1lbmdpbmVlcmluZyBp bmZvcm1hdGlvbikuDQogICAgIC0gIFRoZSBpbmNyZWFzaW5nIG51bWJlciBvZiBkZXN0aW5hdGlv bnMgYW5kIEFTIHRvcG9sb2dpZXMuDQogICAgIC0gIEZpbmVyIGdyYW51bGFyaXR5IHJvdXRpbmcs IGFuZCB0aGUgYWJpbGl0eSB0byBpbmplY3QgZXh0ZXJuYWwNCiAgICAgcm91dGVzIGludG8gYXJl YXMgW0RPTUFJTi1XSURFXS4NCiAgICAgLSAgT3RoZXIgZW1lcmdpbmcgdGVjaG5vbG9naWVzLCBz dWNoIGFzIG9wdGljYWwsIElQdjYsIGV0Yy4NCg0KICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMg bWVjaGFuaXNtcyB0byByZWxheCB0aGUgbGltaXQgb24gdGhlIG51bWJlcg0KICAgb2YgTFNQIGZy YWdtZW50cy4NCg0KDQoxLjEgIEtleXdvcmRzDQoNCiAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAi TVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwNCiAgICJTSE9VTEQi LCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4g dGhpcw0KICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBS RkMgMjExOSBbQkNQMTRdLg0KDQoNCjEuMiAgRGVmaW5pdGlvbnMgb2YgQ29tbW9ubHkgVXNlZCBU ZXJtcw0KDQogICBUaGlzIHNlY3Rpb24gcHJvdmlkZXMgZGVmaW5pdGlvbnMgZm9yIHRlcm1zIHRo YXQgYXJlIHVzZWQgdGhyb3VnaG91dA0KICAgdGhlIHRleHQuDQoNCiAgICAgT3JpZ2luYXRpbmcg U3lzdGVtDQogICAgICAgIEEgcm91dGVyIHBoeXNpY2FsbHkgcnVubmluZyB0aGUgSVMtSVMgcHJv dG9jb2wuICBBcyB0aGlzDQogICAgICAgIGRvY3VtZW50IGRlc2NyaWJlcyBtZXRob2RzIGFsbG93 aW5nIGEgc2luZ2xlIElTLUlTIHByb2Nlc3MgdG8NCiAgICAgICAgYWR2ZXJ0aXNlIGl0cyBMU1Bz IGFzIG11bHRpcGxlICJ2aXJ0dWFsIiByb3V0ZXJzLCB0aGUNCiAgICAgICAgT3JpZ2luYXRpbmcg U3lzdGVtIHJlcHJlc2VudHMgdGhlIHNpbmdsZSAicGh5c2ljYWwiIElTLUlTDQogICAgICAgIHBy b2Nlc3MuDQoNCiAgICAgTm9ybWFsIHN5c3RlbS1pZA0KICAgICAgICBUaGUgc3lzdGVtLWlkIG9m IGFuIE9yaWdpbmF0aW5nIFN5c3RlbS4NCg0KICAgICBBZGRpdGlvbmFsIHN5c3RlbS1pZA0KDQoN Cg0KQS4gSGVybWVsaW4sIGV0IGFsLiAgICAgICBFeHBpcmVzIERlY2VtYmVyIDIwMDIgICAgICAg ICAgICAgICAgIFtQYWdlIDJdDQoMDQpJbnRlcm5ldCBEcmFmdCAgICBkcmFmdC1pZXRmLWlzaXMt ZXh0LWxzcC1mcmFncy0wMS50eHQgICAgICAgICBKdW5lIDIwMDINCg0KDQogICAgICAgIEFuIEFk ZGl0aW9uYWwgc3lzdGVtLWlkIHRoYXQgaXMgYXNzaWduZWQgYnkgdGhlIG5ldHdvcmsNCiAgICAg ICAgYWRtaW5pc3RyYXRvci4gIEVhY2ggQWRkaXRpb25hbCBzeXN0ZW0taWQgYWxsb3dzIGdlbmVy YXRpb24gb2YNCiAgICAgICAgMjU2IGFkZGl0aW9uYWwsIG9yIGV4dGVuZGVkLCBMU1AgZnJhZ21l bnRzLiAgVGhlIEFkZGl0aW9uYWwNCiAgICAgICAgc3lzdGVtLWlkLCBsaWtlIHRoZSBOb3JtYWwg c3lzdGVtLWlkLCBtdXN0IGJlIHVuaXF1ZSB0aHJvdWdob3V0DQogICAgICAgIHRoZSByb3V0aW5n IGRvbWFpbi4NCg0KICAgICBWaXJ0dWFsIFN5c3RlbQ0KICAgICAgICBUaGUgc3lzdGVtLCBpZGVu dGlmaWVkIGJ5IGFuIEFkZGl0aW9uYWwgc3lzdGVtLWlkLCBhZHZlcnRpc2VkIGFzDQogICAgICAg IG9yaWdpbmF0aW5nIHRoZSBleHRlbmRlZCBMU1AgZnJhZ21lbnRzLiAgVGhlc2UgZnJhZ21lbnRz IHNwZWNpZnkNCiAgICAgICAgdGhlIEFkZGl0aW9uYWwgc3lzdGVtLWlkIGluIHRoZWlyIExTUCBJ RHMuDQoNCiAgICAgT3JpZ2luYWwgTFNQDQogICAgICAgIEFuIExTUCB1c2luZyB0aGUgTm9ybWFs IHN5c3RlbS1pZCBpbiBpdHMgTFNQIElELg0KDQogICAgIEV4dGVuZGVkIExTUA0KICAgICAgICBB biBMU1AgdXNpbmcgYW4gQWRkaXRpb25hbCBzeXN0ZW0taWQgaW4gaXRzIExTUCBJRC4NCg0KICAg ICBMU1Agc2V0DQogICAgICAgIExvZ2ljYWwgTFNQLiAgVGhpcyB0ZXJtIGlzIHVzZWQgb25seSB0 byByZXNvbHZlIHRoZSBhbWJpZ3VpdHkNCiAgICAgICAgYmV0d2VlbiBhIGxvZ2ljYWwgTFNQIGFu ZCBhbiBMU1AgZnJhZ21lbnQsIGJvdGggb2Ygd2hpY2ggYXJlDQogICAgICAgIHNvbWV0aW1lcyB0 ZXJtZWQgIkxTUCIuDQoNCiAgICAgRXh0ZW5kZWQgTFNQIHNldA0KICAgICAgICBBIGdyb3VwIG9m IExTUCBmcmFnbWVudHMgdXNpbmcgYW4gQWRkaXRpb25hbCBzeXN0ZW0taWQsIGFuZA0KICAgICAg ICBvcmlnaW5hdGVkIGJ5IHRoZSBPcmlnaW5hdGluZyBTeXN0ZW0uDQoNCiAgICAgRXh0ZW5zaW9u LWNhcGFibGUgSVMNCiAgICAgICAgQW4gSVMgaW1wbGVtZW50aW5nIHRoaXMgZXh0ZW5zaW9uLg0K DQoNCjEuMyAgT3BlcmF0aW9uIE1vZGVzDQoNCiAgIFR3byBhZG1pbmlzdHJhdGl2ZSBvcGVyYXRp b24gbW9kZXMgYXJlIHByb3ZpZGVkOg0KDQogICAgICAgLSBPcGVyYXRpb24gTW9kZSAxIHByb3Zp ZGVzIGJlaGF2aW9yIHRoYXQgYWxsb3dzIGltcGxlbWVudGF0aW9ucw0KICAgICAgIHRoYXQgZG9u J3Qgc3VwcG9ydCB0aGlzIGV4dGVuc2lvbiwgdG8gY29ycmVjdGx5IHByb2Nlc3MgdGhlDQogICAg ICAgZXh0ZW5kZWQgZnJhZ21lbnQgaW5mb3JtYXRpb24sIHdpdGhvdXQgYW55IG1vZGlmaWNhdGlv bnMuICBUaGlzDQogICAgICAgbW9kZSBoYXMgc29tZSByZXN0cmljdGlvbnMgb24gd2hhdCBtYXkg YmUgYWR2ZXJ0aXNlZCBpbiB0aGUNCiAgICAgICBleHRlbmRlZCBMU1AgZnJhZ21lbnRzLiAgTmFt ZWx5LCBvbmx5IGxlYWYgaW5mb3JtYXRpb24gbWF5IGJlDQogICAgICAgYWR2ZXJ0aXNlZCBpbiB0 aGUgZXh0ZW5kZWQgTFNQcy4NCg0KICAgICAgIC0gT3BlcmF0aW9uIE1vZGUgMiBleHRlbmRzIHRo ZSBwcmV2aW91cyBtb2RlIGFuZCByZWxheGVzIGl0cw0KICAgICAgIGFkdmVydGlzZW1lbnQgcmVz dHJpY3Rpb25zLiAgQW55IGxpbmstc3RhdGUgaW5mb3JtYXRpb24gbWF5IGJlDQogICAgICAgYWR2 ZXJ0aXNlZCBpbiB0aGUgZXh0ZW5kZWQgTFNQcy4gIEhvd2V2ZXIsIGl0IG1hbmRhdGVzIGEgY2hh bmdlDQogICAgICAgdG8gdGhlIHdheSBMU1BzIGFyZSBjb25zaWRlcmVkIGR1cmluZyB0aGUgU1BG IGFsZ29yaXRobSwgaW4gYSB3YXkNCiAgICAgICB0aGF0IGlzbid0IGNvbXBhdGlibGUgd2l0aCBw cmV2aW91cyBpbXBsZW1lbnRhdGlvbnMuDQoNCg0KDQoNCkEuIEhlcm1lbGluLCBldCBhbC4gICAg ICAgRXhwaXJlcyBEZWNlbWJlciAyMDAyICAgICAgICAgICAgICAgICBbUGFnZSAzXQ0KDA0KSW50 ZXJuZXQgRHJhZnQgICAgZHJhZnQtaWV0Zi1pc2lzLWV4dC1sc3AtZnJhZ3MtMDEudHh0ICAgICAg ICAgSnVuZSAyMDAyDQoNCg0KICAgVGhlc2UgbW9kZXMgYXJlIGNvbmZpZ3VyZWQgb24gYSBwZXIt bGV2ZWwgYW5kIGFyZWEgYmFzaXMuICBUaGF0IGlzLA0KICAgYWxsIExTUHMgY29uc2lkZXJlZCBp biB0aGUgc2FtZSBTUEYgaW5zdGFuY2UgTVVTVCB1c2UgdGhlIHNhbWUgTW9kZS4NCiAgIFRoZXJl IGlzIG5vIHJlc3RyaWN0aW9uIHRoYXQgYW4gTDEvTDIgSVMgb3BlcmF0ZXMgaW4gdGhlIHNhbWUg bW9kZSwNCiAgIGZvciBib3RoIGl0cyBMMSBhbmQgTDIgaW5zdGFuY2VzLiAgSXQgY2FuIHVzZSBN b2RlIDEgZm9yIGl0cyBMMSBMU1BzLA0KICAgYW5kIE1vZGUgMiBmb3IgaXRzIEwyIExTUHMsIG9y IHZpY2UgdmVyc2EuDQoNCiAgIFJvdXRlcnMgTUFZIGltcGxlbWVudCBPcGVyYXRpb25hbCBNb2Rl IDIgd2l0aG91dCBzdXBwb3J0aW5nIHJ1bm5pbmcNCiAgIGluIE9wZXJhdGlvbmFsIE1vZGUgMS4g IFRoZXkgd2lsbCBzdGlsbCBpbnRlcm9wZXJhdGUgY29ycmVjdGx5IHdpdGgNCiAgIHJvdXRlcnMg dGhhdCBzdXBwb3J0IGJvdGggbW9kZXMuDQoNCg0KMS40ICBPdmVydmlldw0KDQogICBVc2luZyBB ZGRpdGlvbmFsIHN5c3RlbS1pZHMgYXNzaWduZWQgYnkgdGhlIGFkbWluaXN0cmF0b3IsIHRoZQ0K ICAgT3JpZ2luYXRpbmcgU3lzdGVtIGNhbiBhZHZlcnRpc2UgdGhlIGV4Y2VzcyBsaW5rLXN0YXRl IGluZm9ybWF0aW9uIGluDQogICBleHRlbmRlZCBMU1BzIHVuZGVyIHRoZXNlIEFkZGl0aW9uYWwg c3lzdGVtLWlkcy4gIEl0IHdvdWxkIGRvIHNvIGFzDQogICBpZiBvdGhlciByb3V0ZXJzLCBvciAi VmlydHVhbCBTeXN0ZW1zIiwgd2VyZSBhZHZlcnRpc2luZyB0aGlzDQogICBpbmZvcm1hdGlvbi4g IFRoZXNlIGV4dGVuZGVkIExTUHMgd2lsbCBhbHNvIGhhdmUgdGhlIHNwZWNpZmllZCBsaW1pdA0K ICAgb24gdGhlaXIgTFNQIGZyYWdtZW50czsgaG93ZXZlciwgdGhlIE9yaWdpbmF0aW5nIFN5c3Rl bSBtYXkgZ2VuZXJhdGUNCiAgIGV4dGVuZGVkIExTUHMgdW5kZXIgbnVtZXJvdXMgVmlydHVhbCBT eXN0ZW1zLg0KDQogICBGb3IgT3BlcmF0aW9uIE1vZGUgMSwgMC1jb3N0IGFkamFjZW5jaWVzIGFy ZSBhZHZlcnRpc2VkIGZyb20gdGhlDQogICBPcmlnaW5hdGluZyBTeXN0ZW0gdG8gaXRzIFZpcnR1 YWwgU3lzdGVtKHMpLiAgTm8gYWRqYWNlbmNpZXMgKG90aGVyDQogICB0aGFuIGJhY2sgdG8gdGhl IE9yaWdpbmF0aW5nIFN5c3RlbSkgYXJlIGFkdmVydGlzZWQgaW4gdGhlIGV4dGVuZGVkDQogICBM U1BzLiAgQXMgYSBjb25zZXF1ZW5jZSwgdGhlIFZpcnR1YWwgU3lzdGVtcyBhcmUgJ3N0dWInLCBt ZWFuaW5nIHRoZXkNCiAgIGNhbiBvbmx5IGJlIHJlYWNoZWQgdGhyb3VnaCB0aGVpciBPcmlnaW5h dGluZyBTeXN0ZW0uICBUaGVyZWZvcmUsDQogICBvbGRlciBpbXBsZW1lbnRhdGlvbnMgZG8gbm90 IG5lZWQgbW9kaWZpY2F0aW9ucyBpbiBvcmRlciB0byBjb3JyZWN0bHkNCiAgIHByb2Nlc3MgdGhl c2UgZXh0ZW5kZWQgTFNQcy4NCg0KICAgRm9yIGJvdGggbW9kZXMsIGVhY2ggTFNQIChzZXQpIGNy ZWF0ZWQgYnkgYSBub2RlIHdpbGwgY29udGFpbiBvbiBpdHMNCiAgIGZyYWdtZW50LTAgYSBuZXcg VExWIChJUyBBbGlhcyBJRCBUTFYpIHRoYXQgY29udGFpbnMgdGhlIE5vcm1hbA0KICAgc3lzdGVt LWlkIGFuZCBQTiBOdW1iZXIgb2YgdGhlIChmaXJzdCkgTFNQIGNyZWF0ZWQgYnkgdGhlIHJvdXRl ci4NCiAgIEV4dGVuc2lvbi1jYXBhYmxlIElTcyBjYW4gdGhlbiB1c2UgdGhpcyBpbmZvcm1hdGlv biBhbmQgc3RvcmUgdGhlDQogICBvcmlnaW5hbCBhbmQgZXh0ZW5kZWQgTFNQcyBhcyBvbmUgbG9n aWNhbCBMU1AuDQoNCg0KMi4wICBJUyBBbGlhcyBJRCBUTFYgKElTLUEpDQoNCiAgIFRoZSBwcm9w b3NlZCBJUy1BIFRMViBhbGxvd3MgZXh0ZW5zaW9uLWNhcGFibGUgSVNzIHRvIHJlY29nbml6ZSBh bGwNCiAgIExTUHMgb2YgYW4gT3JpZ2luYXRpbmcgU3lzdGVtLCBhbmQgY29tYmluZSB0aGUgb3Jp Z2luYWwgYW5kIGV4dGVuZGVkDQogICBMU1BzIGZvciB0aGUgcHVycG9zZSBvZiBTUEYgY29tcHV0 YXRpb24uICBJdCBpZGVudGlmaWVzIHRoZSBOb3JtYWwNCiAgIHN5c3RlbS1pZCBvZiB0aGUgT3Jp Z2luYXRpbmcgU3lzdGVtLg0KDQogICBUaGUgSVMgQWxpYXMgSUQgVExWIGlzIHR5cGUgMjQsIGFu ZCBjb250YWlucyBhIG5ldyBkYXRhIHN0cnVjdHVyZSwNCiAgIGNvbnNpc3Rpbmcgb2Y6DQogICAg IDcgb2N0ZXRzIGNvbnNpc3Rpbmcgb2YgdGhlIG5vcm1hbCBzeXN0ZW0tSWQgYW5kIHBzZXVkb25v ZGUgbnVtYmVyDQogICAgIDEgb2N0ZXQgb2YgbGVuZ3RoIG9mIHN1Yi1UTFZzDQoNCg0KDQpBLiBI ZXJtZWxpbiwgZXQgYWwuICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjAwMiAgICAgICAgICAgICAg ICAgW1BhZ2UgNF0NCgwNCkludGVybmV0IERyYWZ0ICAgIGRyYWZ0LWlldGYtaXNpcy1leHQtbHNw LWZyYWdzLTAxLnR4dCAgICAgICAgIEp1bmUgMjAwMg0KDQoNCiAgICAgMC0yNDcgb2N0ZXRzIG9m IHN1Yi1UTFZzLA0KICAgICAgICB3aGVyZSBlYWNoIHN1Yi1UTFYgY29uc2lzdHMgb2YgYSBzZXF1 ZW5jZSBvZg0KICAgICAgICAgICAxIG9jdGV0IG9mIHN1Yi10eXBlDQogICAgICAgICAgIDEgb2N0 ZXQgb2YgbGVuZ3RoDQogICAgICAgICAgIDAtMjQ1IG9jdGV0cyBvZiB2YWx1ZQ0KDQogICBGb3Ig YW4gZXhwbGFuYXRpb24gb24gc3ViLVRMViBoYW5kbGluZywgc2VlIFtJU0lTLVRFXS4NCg0KICAg V2l0aG91dCBzdWItVExWcywgdGhpcyBzdHJ1Y3R1cmUgY29uc3VtZXMgOCBvY3RldHMgcGVyIExT UCBzZXQuICBUaGlzDQogICBUTFYgTVVTVCBiZSBpbmNsdWRlZCBpbiBmcmFnbWVudCAwIG9mIGV2 ZXJ5IExTUCBzZXQgYmVsb25naW5nIHRvIGFuDQogICBPcmlnaW5hdGluZyBTeXN0ZW0uICBDdXJy ZW50bHksIHRoZXJlIGFyZSBubyBzdWItVExWcyBkZWZpbmVkLg0KDQogICBBcyBhbiBleGFtcGxl LCBhc3N1bWUgYW4gbm9ybWFsIHN5c3RlbSB1c2luZyBERUFELkJFRUYuQ0FDQSBhcyBpdHMNCiAg IChvcmlnaW5hbCkgc3lzdGVtLWlkLCAgYW5kIG5vIHN1Yi1UTFZzLiAgVGhlIGZvbGxvd2luZyBp cyB0aGUNCiAgIGVuY29uZGluZyBvZiB0aGUgVExWIHRvIGJlIHVzZWQgaW4gYWxsIG9mIGl0cyBM U1Agc2V0czoNCg0KICAgICAgIHggQ09ERSAtIDI0Lg0KDQogICAgICAgeCBMRU5HVEggLSA4Lg0K DQogICAgICAgeCBWQUxVRSAtDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOby4g b2YgT2N0ZXRzICAgTWVhbmluZw0KICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLSsNCiAg ICAgICAgICAgICB8IERFQUQuQkVFRi5DQUNBICB8ICAgICAgNiAgICAgICAgICBOb3JtYWwgc3lz dGVtLWlkDQogICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgIHwg MCAgICAgICAgICAgICAgIHwgICAgICAxICAgICAgICAgIHBzZXVkb25vZGUgbnVtYmVyDQogICAg ICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgIHwgMCAgICAgICAgICAg ICAgIHwgICAgICAxICAgICAgICAgIHN1Yi10bHZzIGxlbmd0aA0KICAgICAgICAgICAgICstLS0t LS0tLS0tLS0tLS0tLSsNCg0KDQogICBGb3IgYSBjb21wbGV0ZSBsaXN0IG9mIHVzZWQgSVMtSVMg VExWIG51bWJlcnMsIHNlZSBbSVNJUy1DT0RFU10uDQoNCg0KMy4wICBHZW5lcmF0aW5nIExTUHMN Cg0KMy4xICBCb3RoIE9wZXJhdGlvbiBNb2Rlcw0KDQogICBVbmRlciBib3RoIG1vZGVzLCB0aGUg T3JpZ2luYXRpbmcgU3lzdGVtIE1VU1QgaW5jbHVkZSBpbmZvcm1hdGlvbg0KICAgYmluZGluZyB0 aGUgT3JpZ2luYWwgTFNQIGFuZCB0aGUgRXh0ZW5kZWQgb25lcy4gIEl0IGNhbiBkbyB0aGlzIHNp bmNlDQogICBpdCBpcyB0cml2aWFsbHkgYW4gZXh0ZW5zaW9uLWNhcGFibGUgSVMuICBUaGlzIGlz IHRvIGVuc3VyZSBvdGhlcg0KICAgZXh0ZW5zaW9uLWNhcGFibGUgcm91dGVycyBjb3JyZWN0bHkg cHJvY2VzcyB0aGUgZXh0cmEgaW5mb3JtYXRpb24gaW4NCiAgIHRoZWlyIFNQRiBjYWxjdWxhdGlv bi4gIFRoaXMgYmluZGluZyBpcyBhZHZlcnRpc2VkIHZpYSBhIG5ldyBJUyBBbGlhcw0KICAgSUQg VExWLCB3aGljaCBpcyBhZHZlcnRpc2VkIGluIGFsbCBmcmFnbWVudCAwLCB3aGV0aGVyIHRoZXkg YmVsb25nIHRvDQogICB0aGUgb3JpZ2luYWwgTFNQIG9yIHRvIHRoZSBleHRlbmRlZCBvbmVzLg0K DQoNCg0KDQoNCkEuIEhlcm1lbGluLCBldCBhbC4gICAgICAgRXhwaXJlcyBEZWNlbWJlciAyMDAy ICAgICAgICAgICAgICAgICBbUGFnZSA1XQ0KDA0KSW50ZXJuZXQgRHJhZnQgICAgZHJhZnQtaWV0 Zi1pc2lzLWV4dC1sc3AtZnJhZ3MtMDEudHh0ICAgICAgICAgSnVuZSAyMDAyDQoNCg0KICAgKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgIHwgIE9yaWdp bmF0aW5nIFN5c3RlbSAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICB8ICBzeXN0ZW0taWQg ICA9IFMgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgfCAgaXMtYWxpYXMtaWQgPSBT ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQoNCiAgICstLS0tLS0tLS0tLS0tLS0tLS0tKyAgICAg Ky0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICB8ICBWaXJ0dWFsIFN5c3RlbSAgIHwgICAgIHwgIFZp cnR1YWwgU3lzdGVtICAgfA0KICAgfCAgc3lzdGVtLWlkICAgPSBTJyB8ICAgICB8ICBzeXN0ZW0t aWQgICA9IFMnJ3wNCiAgIHwgIGlzLWFsaWFzLWlkID0gUyAgfCAgICAgfCAgaXMtYWxpYXMtaWQg PSBTICB8DQogICArLS0tLS0tLS0tLS0tLS0tLS0tLSsgICAgICstLS0tLS0tLS0tLS0tLS0tLS0t Kw0KDQogICBGaWd1cmUgMS4gQWR2ZXJ0aXNpbmcgYmluZGluZyBiZXR3ZWVuIGFsbCBvZiBhIHN5 c3RlbSdzIExTUHMgKGJvdGgNCiAgIG1vZGVzKS4gIFMnIGFuZCBTJycgYXJlIGNvbmZpZ3VyZWQg YXMgQWRkaXRpb25hbCBzeXN0ZW0taWRzLg0KDQogICBXaGVuIG5ldyBleHRlbmRlZCBMU1AgZnJh Z21lbnRzIGFyZSBnZW5lcmF0ZWQsIHRoZXNlIGZyYWdtZW50cyBzaG91bGQNCiAgIGJlIGdlbmVy YXRlZCBhcyBzcGVjaWZpZWQgaW4gSVNPIDEwNTg5IFtJU0lTLUlTT10uICBGdXJ0aGVybW9yZSwg YQ0KICAgc3lzdGVtIFNIT1VMRCB0cmVhdCBpdHMgZXh0ZW5kZWQgTFNQcyB0aGUgc2FtZSBhcyBp dCB0cmVhdHMgaXRzDQogICBvcmlnaW5hbCBMU1BzLCB3aXRoIHRoZSBleGNlcHRpb25zIG5vdGVk IGluIHRoZSBmb2xsb3dpbmcgc2VjdGlvbnMuDQogICBTcGVjaWZpY2FsbHksIGNyZWF0aW5nLCBm bG9vZGluZywgcmVuZXdpbmcsIHB1cmdpbmcgYW5kIGFsbCBvdGhlcg0KICAgb3BlcmF0aW9ucyBh cmUgc2ltaWxhciBmb3IgYm90aCBvcmlnaW5hbCBhbmQgZXh0ZW5kZWQgTFNQcywgdW5sZXNzDQog ICBzdGF0ZWQgb3RoZXJ3aXNlLiAgVGhlIGV4dGVuZGVkIExTUHMgd2lsbCB1c2Ugb25lIG9mIHRo ZSBBZGRpdGlvbmFsDQogICBzeXN0ZW0taWRzIGNvbmZpZ3VyZWQgZm9yIHRoZSByb3V0ZXIsIGlu IHRoZWlyIExTUCBJRC4NCg0KICAgRXh0ZW5kZWQgTFNQcyBmcmFnbWVudCB6ZXJvIHNob3VsZCBi ZSByZWdhcmRlZCBpbiB0aGUgc2FtZSBzcGVjaWFsDQogICBtYW5uZXIgYXMgc3BlY2lmaWVkIGlu IDEwNTg5IGZvciBMU1BzIHdpdGggbnVtYmVyIHplcm8sIGFuZCBzaG91bGQNCiAgIGluY2x1ZGUg dGhlIHNhbWUgdHlwZSBvZiBleHRyYSBpbmZvcm1hdGlvbiBhcyBzcGVjaWZpZWQgaW4gMTA1ODkg YW5kDQogICBSRkMgMTE5NSBbSVNJUy1JUF0uICBTbywgZm9yIGV4YW1wbGUsIHdoZW4gYSBzeXN0 ZW0gcmVpc3N1ZXMgaXRzIExTUA0KICAgZnJhZ2VtbnQgemVybyBkdWUgdG8gYW4gYXJlYSBhZGRy ZXNzIGNoYW5nZSwgaXQgc2hvdWxkIHJlaXNzdWUgYWxsDQogICBleHRlbmRlZCBMU1BzIGZyYWdt ZW50IHplcm8gYXMgd2VsbC4NCg0KICAgQW4gZXh0ZW5kZWQgTFNQIGZyYWdtZW50IHplcm8gTVVT VCBiZSBnZW5lcmF0ZWQgZm9yIGV2ZXJ5IGV4dGVuZGVkDQogICBMU1Agc2V0LCB0byBhbGxvdyBh IHJvdXRlcidzIFNQRiBjYWxjdWxhdGlvbiB0byBjb25zaWRlciB0aG9zZQ0KICAgZnJhZ21lbnRz IGluIHRoYXQgc2V0Lg0KDQoNCjMuMS4xICBUaGUgQXR0YWNoZWQgQml0cw0KDQogICBUaGUgQXR0 YWNoZWQgKEFUVCkgYml0cyBTSE9VTEQgYmUgc2V0IHRvIHplcm8gZm9yIGFsbCBmb3VyIG1ldHJp Yw0KICAgdHlwZXMsIG9uIGFsbCBleHRlbmRlZCBMU1BzLiAgVGhpcyBpcyBkdWUgdG8gdGhlIGZv bGxvd2luZzogaWYgYQ0KICAgVmlydHVhbCBTeXN0ZW0gaXMgcmVhY2hhYmxlLCBzbyBpcyBpdHMg T3JpZ2luYXRpbmcgU3lzdGVtLiAgSXQgaXMNCiAgIHByZWZlcmFibGUsIHRoZW4sIHRoYXQgYW4g TDEgSVMgY2hvb3NlcyB0aGUgT3JpZ2luYXRpbmcgU3lzdGVtIGFuZA0KICAgbm90IHRoZSBWaXJ0 dWFsIFN5c3RlbSBhcyBpdHMgbmVhcmVzdCBMMiBleGl0IHBvaW50LCBhcyBjb25uZWN0aXZpdHkN CiAgIHRvIHRoZSBWaXJ0dWFsIFN5c3RlbSBoYXMgYSBoaWdoZXIgcHJvYmFiaWxpdHkgb2YgYmVp bmcgbG9zdCAoYQ0KICAgcmVzdWx0IG9mIHRoZSBleHRlbmRlZCBMU1Agbm8gbG9uZ2VyIGJlaW5n IGFkdmVydGlzZWQpLiAgVGhpcyBjb3VsZA0KICAgY2F1c2UgdW5uZWNlc3NhcnkgY29tcHV0YXRp b25zIG9uIHNvbWUgaW1wbGVtZW50YXRpb25zLg0KDQoNCg0KDQpBLiBIZXJtZWxpbiwgZXQgYWwu ICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjAwMiAgICAgICAgICAgICAgICAgW1BhZ2UgNl0NCgwN CkludGVybmV0IERyYWZ0ICAgIGRyYWZ0LWlldGYtaXNpcy1leHQtbHNwLWZyYWdzLTAxLnR4dCAg ICAgICAgIEp1bmUgMjAwMg0KDQoNCjMuMS4yICBUaGUgUGFydGl0aW9uIFJlcGFpciBCaXQNCg0K ICAgVGhlIFBhcnRpdGlvbiBSZXBhaXIgKFApIGJpdCBTSE9VTEQgYmUgc2V0IHRvIHplcm8gb24g YWxsIGV4dGVuZGVkDQogICBMU1BzLiAgVGhpcyBpcyBmb3IgdGhlIHNhbWUgcmVhc29ucyBhcyBm b3IgdGhlIEF0dGFjaGVkIGJpdHMuDQoNCg0KMy4xLjMgIEVTIE5laWdoYm9ycyBUTFYNCg0KICAg SVNPIDEwNTg5IFtJU0lTLUlTT10gc2VjdGlvbiA3LjMuNyBzcGVjaWZpZXMgaW5zZXJ0aW5nIGFu IEVTIE5laWdoYm9yDQogICBUTFYgaW4gTDEgTFNQcywgd2l0aCB0aGUgc3lzdGVtIElEIG9mIHRo ZSByb3V0ZXIuICBSRkMgMTE5NSBbSVNJUy1JUF0NCiAgIHJlbGlldmVzIElQLW9ubHkgcm91dGVy cyBvZiB0aGlzIHJlcXVpcmVtZW50LiAgSG93ZXZlciwgZm9yIHJvdXRlcnMNCiAgIHRoYXQgZG8g aW5zZXJ0IHRoaXMgRVNOIFRMViBpbiBMMSBMU1BzICh3aGV0aGVyIElQLW9ubHkgb3IgT1NJLQ0K ICAgY2FwYWJsZSksIHRoZW4gaW4gYW4gZXh0ZW5kZWQgTFNQLCB0aGUgRVNOIFRMViBzaG91bGQg aW5jbHVkZSB0aGUNCiAgIHJlbGV2YW50IEFkZGl0aW9uYWwgc3lzdGVtLWlkLiAgRnVydGhlcm1v cmUsIE9TSS1jYXBhYmxlIHJvdXRlcnMNCiAgIHNob3VsZCBhY2NlcHQgcGFja2V0cyBkZXN0aW5l ZCBmb3IgdGhpcyBBZGRpdGlvbmFsIHN5c3RlbS1pZC4NCg0KDQozLjEuNCAgT3ZlcmxvYWQgQml0 DQoNCiAgIFRoZSBvdmVybG9hZCBiaXQgc2hvdWxkIGJlIHNldCBjb25zaXN0ZW50bHkgYWNyb3Nz IGFsbCBMU1BzLCBvcmlnaW5hbA0KICAgYW5kIGV4dGVuZGVkLCBiZWxvbmdpbmcgdG8gYW4gb3Jp Z2luYXRpbmcgc3lzdGVtLCBhbmQgc2hvdWxkIHJlZmxlY3QNCiAgIHRoZSBvcmlnaW5hdGluZyBz eXN0ZW0ncyBvdmVybG9hZCBzdGF0ZS4NCg0KDQozLjEuNSAgT3RoZXIgRmllbGRzIGFuZCBUTFZz DQoNCiAgIE90aGVyIGZpZWxkcyBhbmQgVExWcyBub3QgbWVudGlvbmVkIGFib3ZlIHJlbWFpbiB0 aGUgc2FtZSwgYm90aCBmb3INCiAgIG9yaWdpbmFsIGFuZCBleHRlbmRlZCBMU1BzLg0KDQoNCjMu MiAgT3BlcmF0aW9uIE1vZGUgMSBBZGRpdGlvbnMNCg0KICAgVGhlIGZvbGxvd2luZyBhZGRpdGlv bnMgYXBwbHkgb25seSB0byByb3V0ZXJzIGdlbmVyYXRpbmcgTFNQcyBpbiBNb2RlDQogICAxLiAg Um91dGVycywgd2hpY2ggYXJlIGNvbmZpZ3VyZWQgdG8gb3BlcmF0ZSBpbiBPcGVyYXRpb24gTW9k ZSAyLA0KICAgU0hPVUxEIE5PVCBhcHBseSB0aGVzZSBhZGRpdGlvbnMgdG8gdGhlaXIgYWR2ZXJ0 aXNlbWVudHMuDQoNCiAgIFVuZGVyIE9wZXJhdGlvbiBNb2RlIDEsIGFkamFjZW5jaWVzIGJldHdl ZW4gdGhlIG5vcm1hbCBzeXN0ZW0gYW5kIGl0cw0KICAgVmlydHVhbCBTeXN0ZW1zIGFyZSBhZHZl cnRpc2VkIHVzaW5nIHRoZSBzdGFuZGFyZCBuZWlnaGJvciBUTFZzLiAgVGhlDQogICBtZXRyaWMg Zm9yIHRoZXNlIGNvbm5lY3Rpb25zIE1VU1QgYmUgemVybywgc2luY2UgdGhlIGNvc3Qgb2YgcmVh Y2hpbmcNCiAgIGEgVmlydHVhbCBTeXN0ZW0gaXMgdGhlIHNhbWUgYXMgdGhlIGNvc3Qgb2YgcmVh Y2hpbmcgaXRzIE9yaWdpbmF0aW5nDQogICBTeXN0ZW0uDQoNCiAgIFRvIG9sZGVyIGltcGxlbWVu dGF0aW9ucywgVmlydHVhbCBTeXN0ZW1zIHdvdWxkIGFwcGVhciByZWFjaGFibGUgb25seQ0KICAg dGhyb3VnaCB0aGVpciBPcmlnaW5hdGluZyBTeXN0ZW0sIGhlbmNlIGxvc3Mgb2YgY29ubmVjdGl2 aXR5IHRvIHRoZQ0KICAgT3JpZ2luYXRpbmcgU3lzdGVtIG1lYW5zIGxvc3Mgb2YgY29ubmVjdGl2 aXR5IHRvIGFsbCBvZiBpdHMNCiAgIGluZm9ybWF0aW9uLCBpbmNsdWRpbmcgdGhhdCBhZHZlcnRp c2VkIGluIGl0cyBleHRlbmRlZCBMU1BzLg0KICAgRnVydGhlcm1vcmUsIHRoZSBjb3N0IG9mIHJl YWNoaW5nIGluZm9ybWF0aW9uIGFkdmVydGlzZWQgaW4gbm9uLQ0KDQoNCg0KQS4gSGVybWVsaW4s IGV0IGFsLiAgICAgICBFeHBpcmVzIERlY2VtYmVyIDIwMDIgICAgICAgICAgICAgICAgIFtQYWdl IDddDQoMDQpJbnRlcm5ldCBEcmFmdCAgICBkcmFmdC1pZXRmLWlzaXMtZXh0LWxzcC1mcmFncy0w MS50eHQgICAgICAgICBKdW5lIDIwMDINCg0KDQogICBleHRlbmRlZCBMU1BzIGlzIHRoZSBzYW1l IGFzIHRoZSBjb3N0IG9mIHJlYWNoaW5nIGluZm9ybWF0aW9uDQogICBhZHZlcnRpc2VkIGluIHRo ZSBuZXcgZXh0ZW5kZWQgTFNQcywgd2l0aCBhbiBhZGRpdGlvbmFsIGhvcC4NCg0KICAgKy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgIHwgIE9yaWdpbmF0 aW5nIFN5c3RlbSAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICB8ICBzeXN0ZW0taWQgICA9 IFMgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgfCAgaXMtYWxpYXMtaWQgPSBTICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICAgICAgICAgfCAgICAvXCAgICAgICAgICAgICAgICAg ICAgfCAgICAvXA0KICAgY29zdD0wIHwgICAgfGNvc3Q9bWF4LTEgICAgY29zdD0wIHwgICAgfGNv c3Q9bWF4LTENCiAgICAgICAgICB8ICAgIHwgICAgICAgICAgICAgICAgICAgICB8ICAgIHwNCiAg ICAgICAgICBcLyAgIHwgICAgICAgICAgICAgICAgICAgICBcLyAgIHwNCiAgICstLS0tLS0tLS0t LS0tLS0tLS0tKyAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICB8ICBWaXJ0dWFsIFN5c3Rl bSAgIHwgICAgIHwgIFZpcnR1YWwgU3lzdGVtICAgfA0KICAgfCAgc3lzdGVtLWlkICAgPSBTJyB8 ICAgICB8ICBzeXN0ZW0taWQgICA9IFMnJ3wNCiAgIHwgIGlzLWFsaWFzLWlkID0gUyAgfCAgICAg fCAgaXMtYWxpYXMtaWQgPSBTICB8DQogICArLS0tLS0tLS0tLS0tLS0tLS0tLSsgICAgICstLS0t LS0tLS0tLS0tLS0tLS0tKw0KDQogICBGaWd1cmUgMi4gQWR2ZXJ0aXNpbmcgY29ubmVjdGlvbnMg dG8gVmlydHVhbCBTeXN0ZW1zIHVuZGVyIE9wZXJhdGlvbg0KICAgTW9kZSAxLiAgUycgYW5kIFMn JyBhcmUgY29uZmlndXJlZCBhcyBBZGRpdGlvbmFsIHN5c3RlbS1pZHMuDQoNCiAgIFVuZGVyIE9w ZXJhdGlvbiBNb2RlIDEsIG9ubHkgImxlYWYiIGluZm9ybWF0aW9uLCBpLmUuIGluZm9ybWF0aW9u DQogICB0aGF0IHNlcnZlcyBvbmx5IGFzIGxlYXZlcyBpbiBhIHNob3J0ZXN0IHBhdGggdHJlZSwg Y2FuIGJlIGFkdmVydGlzZWQNCiAgIGluIGV4dGVuZGVkIExTUHMuDQoNCiAgIFdoZW4gYW4gZXh0 ZW5kZWQgTFNQIGJlbG9uZ2luZyB0byBBZGRpdGlvbmFsIHN5c3RlbS1pZCBTJyBpcyBmaXJzdA0K ICAgY3JlYXRlZCwgdGhlIG9yaWdpbmFsIExTUCBNVVNUIHNwZWNpZnkgUycgYXMgYSBuZWlnaGJv ciwgd2l0aCBtZXRyaWMNCiAgIHNldCB0byB6ZXJvLiAgVGhpcyBpbiBvcmRlciB0byBjb25zaWRl ciB0aGUgY29zdCBvZiByZWFjaGluZyB0aGUNCiAgIFZpcnR1YWwgU3lzdGVtIFMnIHRoZSBzYW1l IGFzIHRoZSBjb3N0IG9mIHJlYWNoaW5nIGl0cyBPcmlnaW5hdGluZw0KICAgU3lzdGVtLiAgRnVy dGhlcm1vcmUsIHRoZSBleHRlbmRlZCBMU1AgTVVTVCBzcGVjaWZ5IHRoZSBOb3JtYWwNCiAgIHN5 c3RlbS1pZCBhcyBhIG5laWdoYm9yLCB3aXRoIG1ldHJpYyBzZXQgdG8gKE1heExpbmtNZXRyaWMg LSAxKS4NCiAgIFRoaXMgaW4gb3JkZXIgdG8gc2F0aXNmeSB0aGUgdHdvLXdheSBjb25uZWN0aXZp dHkgY2hlY2sgb24gb3RoZXINCiAgIHJvdXRlcnMuICBXaGVyZSByZWxldmFudCwgdGhpcyBhZGph Y2VuY3kgU0hPVUxEIGJlIGNvbnNpZGVyZWQgYXMNCiAgIHBvaW50LXRvLXBvaW50Lg0KDQogICBO b3RlLCB0aGF0IHRoZSByZXN0cmljdGlvbiBzcGVjaWZpZWQgaW4gSVNPIDEwNTg5IHNlY3Rpb24g Ny4yLjUNCiAgIGhvbGRzOiAgaWYgYW4gTFNQIE51bWJlciB6ZXJvIG9mIHRoZSBPcmlnaW5hdGlu ZyBTeXN0ZW0gaXMgbm90DQogICBwcmVzZW50LCBub25lIG9mIHRoYXQgc3lzdGVtJ3MgbmVpZ2hi b3IgZW50cmllcyB3b3VsZCBiZSBwcm9jZXNzZWQNCiAgIGR1cmluZyBTUEYsIGhlbmNlIG5vbmUg b2YgaXRzIGV4dGVuZGVkIExTUHMgd291bGQgYmUgcHJvY2Vzc2VkIGFzDQogICB3ZWxsLg0KDQoN CjMuMi4xICBJUyBOZWlnaGJvcnMgVExWDQoNCiAgIEFuIEV4dGVuZGVkIExTUCBtdXN0IHNwZWNp Znkgb25seSB0aGUgT3JpZ2luYXRpbmcgU3lzdGVtIGFzIGENCiAgIG5laWdoYm9yLCB3aXRoIHRo ZSBtZXRyaWMgc2V0IHRvIChNYXhMaW5rTWV0cmljIC0gMSkuICBXaGVyZQ0KICAgcmVsZXZhbnQs IHRoaXMgYWRqYWNlbmN5IHNob3VsZCBiZSBjb25zaWRlcmVkIGFzIHBvaW50LXRvLXBvaW50Lg0K DQoNCg0KQS4gSGVybWVsaW4sIGV0IGFsLiAgICAgICBFeHBpcmVzIERlY2VtYmVyIDIwMDIgICAg ICAgICAgICAgICAgIFtQYWdlIDhdDQoMDQpJbnRlcm5ldCBEcmFmdCAgICBkcmFmdC1pZXRmLWlz aXMtZXh0LWxzcC1mcmFncy0wMS50eHQgICAgICAgICBKdW5lIDIwMDINCg0KDQogICBPdGhlciBu ZWlnaGJvcnMgTVVTVCBOT1QgYmUgc3BlY2lmaWVkIGluIGFuIEV4dGVuZGVkIExTUCwgYmVjYXVz ZQ0KICAgdGhvc2Ugb3RoZXIgbmVpZ2hib3JzIHdvdWxkIG9ubHkgc3BlY2lmeSB0aGUgT3JpZ2lu YXRpbmcgU3lzdGVtIGFuZA0KICAgbm90IHRoZSBhZGRpdGlvbmFsIHN5c3RlbSwgYW5kIGhlbmNl IHdvdWxkIG5vdCBzYXRpc2Z5IHRoZSBiaS0NCiAgIGRpcmVjdGlvbmFsaXR5IGNoZWNrIGluIHRo ZSBTUEYgY29tcHV0YXRpb24uDQoNCg0KNC4gIFB1cmdpbmcgRXh0ZW5kZWQgTFNQIEZyYWdtZW50 cw0KDQogICBJU08gMTA1ODkgW0lTSVMtSVNPXSBzZWN0aW9uIDcuMy40LjQgbm90ZSAyMSBzdWdn ZXN0cyB0aGF0IGFuDQogICBpbXBsZW1lbnRhdGlvbiBrZWVwcyB0aGUgbnVtYmVyIG9mIExTUCBm cmFnbWVudHMgd2l0aGluIGEgY2VydGFpbg0KICAgbGltaXQgYmFzZWQgb24gdGhlIG9wdGltYWwg KG1pbmltYWwpIG51bWJlciBvZiBmcmFnbWVudHMgbmVlZGVkLg0KICAgU2VjdGlvbiA3LjMuNC42 IGFsc28gcmVjb21tZW5kcyB0aGF0IGFuIElTIHB1cmdlIGl0cyBlbXB0eSBMU1BzIHRvDQogICBj b25zZXJ2ZSByZXNvdXJjZXMuICBUaGVzZSByZWNvbW1lbmRhdGlvbnMgaG9sZCBmb3IgdGhlIGV4 dGVuZGVkIExTUA0KICAgZnJhZ21lbnRzIGFzIHdlbGwuICBIb3dldmVyLCBhbiBleHRlbmRlZCBM U1AgZnJhZ21lbnQgemVybyBzaG91bGQgbm90DQogICBiZSBwdXJnZWQgdW50aWwgYWxsIG9mIHRo ZSBmcmFnbWVudHMgaW4gaXRzIHNldCAoaS5lLiBiZWxvbmdpbmcgdG8gYQ0KICAgcGFydGljdWxh ciBBZGRpdGlvbmFsIHN5c3RlbS1pZCksIGFyZSBlbXB0eSBhcyB3ZWxsLiAgVGhpcyBpcyB0bw0K ICAgZW5zdXJlIGltcGxlbWVudGF0aW9ucyBjb25zaWRlciB0aGUgZnJhZ21lbnRzIGluIHRoZWly IFNQRg0KICAgY29tcHV0YXRpb25zLCBhcyBzcGVjaWZpZWQgaW4gc2VjdGlvbiA3LjIuNS4NCg0K ICAgSW4gT3BlcmF0aW9uYWwgTW9kZSAxLCB3aGVuIGFsbCB0aGUgZXh0ZW5kZWQgTFNQIGZyYWdt ZW50cyBvZiBhDQogICBwYXJ0aWN1bGFyIEFkZGl0aW9uYWwgc3lzdGVtLWlkIFMnIGhhdmUgYmVl biBwdXJnZWQsIHRoZSBPcmlnaW5hdGluZw0KICAgU3lzdGVtIFNIT1VMRCByZW1vdmUgdGhlIG5l aWdoYm9yIGluZm9ybWF0aW9uIHRvIFMnIGZyb20gaXRzIG9yaWdpbmFsDQogICBMU1BzLg0KDQoN CjUuICBNb2RpZmljYXRpb25zIHRvIExTUCBoYW5kbGluZyBpbiBTUEYNCg0KICAgVGhpcyBzZWN0 aW9uIGRlc2NyaWJlcyBtb2RpZmljYXRpb25zIHRvIHRoZSB3YXkgZXh0ZW5zaW9uLWNhcGFibGUg SVNzDQogICBoYW5kbGUgTFNQcyBmb3IgdGhlIFNQRiBjb21wdXRhdGlvbi4NCg0KICAgV2hlbiBj b25zaWRlcmluZyBMU1BzIG9mIGFuIGV4dGVuc2lvbi1jYXBhYmxlIElTIChpZGVudGlmaWVkIGJ5 IHRoZQ0KICAgaW5jbHVzaW9uIG9mIHRoZSBJUyBBbGlhcyBJRCBUTFYpLCB0aGUgb3JpZ2luYWwg YW5kIGV4dGVuZGVkIExTUHMgYXJlDQogICBjb21iaW5lZCB0byBmb3JtIG9uZSBsYXJnZSBsb2dp Y2FsIExTUC4gIElmIHRoZSBMU1AgYmVsb25ncyB0byBhbiBJUw0KICAgcnVubmluZyBPcGVyYXRp b25hbCBNb2RlIDEsIHRoZXJlIG1pZ2h0IGJlIGFkamFjZW5jaWVzIGJldHdlZW4gdGhlDQogICBv cmlnaW5hbCBhbmQgZXh0ZW5kZWQgTFNQcy4gVGhlc2UgYXJlIHRyaXZpYWxseSBpZ25vcmVkIChz aW5jZSB3aGVuDQogICBwcm9jZXNzaW5nIHRoZW0gdGhlIGxhcmdlIGxvZ2ljYWwgTFNQIGlzIGFs cmVhZHkgb24gUEFUSFMpLCBhbmQNCiAgIGRvZXNuJ3QgY29tcGxpY2F0ZSB0aGUgU1BGLiAgRnVy dGhlcm1vcmUsIHRoaXMgY2hlY2sgc2hvdWxkIGFscmVhZHkNCiAgIGJlIGltcGxlbWVudGVkICh0 aGlzIHNjZW5hcmlvIGNvdWxkIG9jY3VyIG9uIGVycm9yLCB3aXRob3V0IHRoaXMNCiAgIGV4dGVu c2lvbikNCg0KICAgSWYgTFNQIGZyYWdtZW50IDAgb2YgdGhlIG9yaWdpbmFsIExTUCBzZXQgaXMg bWlzc2luZyBvciBpdHMNCiAgIFJlbWFpbmluZ0xpZmV0aW1lIGlzIHplcm8sIGFsbCBvZiB0aGUg TFNQcyBnZW5lcmF0ZWQgYnkgdGhhdA0KICAgT3JpZ2luYXRpbmcgU3lzdGVtIChleHRlbmRlZCBh cyB3ZWxsKSBNVVNUIE5PVCBiZSBjb25zaWRlcmVkIGluIHRoZQ0KICAgU1BGLiAgVGhhdCBpcywg dGhlIGxhcmdlIGxvZ2ljYWwgTFNQIGlzbid0IGNvbnNpZGVyZWQgaW4gdGhlIFNQRi4NCiAgIFRo ZSBvcmlnaW5hbCBMU1AgZnJhZ21lbnRzIGFyZSBpZGVudGlmaWVkIHdoZW4gdGhlIGlzLWFsaWFz LWlkIHZhbHVlDQogICBpcyB0aGUgc2FtZSBhcyB0aGUgc3lzdGVtLWlkIG9mIHRob3NlIExTUHMu ICBJZiBhbiBMU1AgZnJhZ21lbnQgMCBvZg0KICAgYW4gZXh0ZW5kZWQgTFNQIHNldCBpcyBtaXNz aW5nIG9yIGl0cyBSZW1haW5pbmdMaWZldGltZSBpcyB6ZXJvLCBvbmx5DQoNCg0KDQpBLiBIZXJt ZWxpbiwgZXQgYWwuICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjAwMiAgICAgICAgICAgICAgICAg W1BhZ2UgOV0NCgwNCkludGVybmV0IERyYWZ0ICAgIGRyYWZ0LWlldGYtaXNpcy1leHQtbHNwLWZy YWdzLTAxLnR4dCAgICAgICAgIEp1bmUgMjAwMg0KDQoNCiAgIHRoYXQgTFNQIHNldCBNVVNUIE5P VCBiZSBjb25zaWRlcmVkIGluIHRoZSBTUEYuICBUaGVzZSBydWxlcyBhcmUNCiAgIHByZXNlbnQg dG8gZW5zdXJlIGNvbnNpc3RlbnQgU1BGIHJlc3VsdHMgb24gTW9kZSAxIGFuZCBNb2RlIDIgTFNQ cy4NCg0KICAgTm90ZSwgdGhhdCB0aGUgYWJvdmUgYmVoYXZpb3IgaXMgY29uc2lzdGVudCB3aXRo IGhvdyBwcmV2aW91cw0KICAgaW1wbGVtZW50YXRpb25zIHdpbGwgaW50ZXJwcmV0IE1vZGUgMSBM U1BzLg0KDQoNCjYuICBGb3JtaW5nIEFkamFjZW5jaWVzDQoNCiAgIEl0IHNob3VsZCBiZSBub3Rl ZCwgdGhhdCBhbiBJUyBNVVNUIHVzZSB0aGUgc3lzdGVtLWlkIG9mIHRoZSBMU1AgdGhhdA0KICAg d2lsbCBpbmNsdWRlIGEgbmVpZ2hib3IsIHdoZW4gZm9ybWluZyBhbiBhZGphY2VuY3kgd2l0aCB0 aGF0DQogICBuZWlnaGJvci4gIFRoYXQgaXMsIGlmIGEgbmVpZ2hib3IgaXMgdG8gYmUgaW5jbHVk ZWQgaW4gZXh0ZW5kZWQgTFNQDQogICBTJywgdGhlbiBTJyBzaG91bGQgYmUgdXNlZCBhcyB0aGUg c3lzdGVtLWlkIGluIElTIEhlbGxvcyBbM10gYW5kIElTLQ0KICAgSVMgSGVsbG9zIHdoZW4gZm9y bWluZyBhbiBhZGphY2VuY3kgd2l0aCB0aGF0IG5laWdoYm9yLiAgVGhpcyBpcw0KICAgcmVnYXJk bGVzcyBvZiB0aGUgT3BlcmF0aW9uYWwgTW9kZS4gIE9mIGNvdXJzZSwgaW4gTW9kZSAxIHRoaXMg bWVhbnMNCiAgIHRoYXQgb25seSB0aGUgTm9ybWFsIHN5c3RlbS1pZCB3aWxsIGJlIHVzZWQgd2hl biBzZW5kaW5nIGhlbGxvcy4NCg0KDQo3LiAgSW50ZXJvcGVyYXRpbmcgYmV0d2VlbiBleHRlbnNp b24tY2FwYWJsZSBhbmQgbm9uLWV4dGVuc2lvbi1jYXBhYmxlDQogICBJU3MuDQoNCiAgIEluIG9y ZGVyIHRvIGNvcnJlY3RseSBhZHZlcnRpc2UgbGluay1zdGF0ZSBpbmZvcm1hdGlvbiB1bmRlcg0K ICAgT3BlcmF0aW9uIE1vZGUgMiwgYWxsIElTcyBpbiBhbiBhcmVhIG11c3QgYmUgZXh0ZW5zaW9u LWNhcGFibGUuDQogICBIb3dldmVyLCBpdCBpcyBwb3NzaWJsZSB0byBub3QgdXBncmFkZSBldmVy eSByb3V0ZXIgaW4gdGhlIG5ldHdvcmssDQogICBpZiB0aGUgZXh0ZW5kZWQgaW5mb3JtYXRpb24g aXMgbm90IHJvdXRpbmcgaW5mb3JtYXRpb24sIGJ1dCByYXRoZXINCiAgIGRhdGEgdGhhdCBpcyBv ZiB1c2UgdG8gb25seSBhIHN1YnNldCBvZiByb3V0ZXJzIChlLmcuIG9wdGljYWwNCiAgIHN3aXRj aGVzIHVzaW5nIElTSVMgY291bGQgY2Fycnkgb3B0aWNhbC1zcGVjaWZpYyBpbmZvcm1hdGlvbiBp bg0KICAgZXh0ZW5kZWQgTFNQcykNCg0KICAgSWYgYSBsaXZlIG5ldHdvcmsgY29udGFpbnMgcm91 dGVycyBleGNlZWRpbmcgdGhlIDI1NiBmcmFnbWVudCBsaW1pdCwNCiAgIGFuZCBmb3Igc29tZSBy ZWFzb24gdGhlIHVwZ3JhZGUgaGFzIHRvIGJlIGRvbmUgaW5jcmVtZW50YWxseSwgaXQgaXMNCiAg IHBvc3NpYmxlIHRvIHRyYW5zaXRpb24gdGhlIG5ldHdvcmssIHVzaW5nIHRoZSBmb2xsb3dpbmcg c3RlcHM6DQogICAgIC0gVXBncmFkZSB0aGUgcm91dGVycywgb25lLWJ5LW9uZSwgdG8gcnVuIHRo aXMgZXh0ZW5zaW9uIGluDQogICAgIE9wZXJhdGlvbiBNb2RlIDEuIFRoZSBvdGhlciBub24tZXh0 ZW5zaW9uLWNhcGFibGUgcm91dGVycyB3aWxsDQogICAgIGludGVyb3BlcmF0ZSBjb3JyZWN0bHku DQogICAgIC0gV2hlbiBhbGwgcm91dGVycyBhcmUgZXh0ZW5zaW9uLWNhcGFibGUsIGNvbmZpZ3Vy ZSB0aGVtIG9uZS1ieS1vbmUNCiAgICAgdG8gcnVuIGluIE9wZXJhdGlvbiBNb2RlIDIuICBBbGwg ZXh0ZW5zaW9uLWNhcGFibGUgcm91dGVycw0KICAgICBpbnRlcm9wZXJhdGUgY29ycmVjdGx5LCBy ZWdhcmRsZXNzIG9mIHdoYXQgbW9kZSB0aGV5J3JlIHJ1biBpbi4NCg0KICAgICBJbXBsZW1lbnRh dGlvbnMgYXJlIGVuY291cmFnZWQgdG8gYWxsb3cgbm90IHJ1bm5pbmcgaW4gYW55IG9mIHRoZQ0K ICAgICBtb2RlcyAoaS5lLiB3aXRob3V0IHRoaXMgbWVjaGFuaXNtKSwgZm9yIHRoZSBzYWtlIG9m IGZpcnN0DQogICAgIHVwZ3JhZGluZyB0aGUgcmVsZXZhbnQgcm91dGVycyBhbmQgb25seSB0aGVu IGVuYWJsaW5nIHRoaXMNCiAgICAgbWVjaGFuaXNtIG9uIGVhY2ggb2YgdGhlbS4NCg0KDQo4LiAg U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCg0KDQoNCg0KQS4gSGVybWVsaW4sIGV0IGFsLiAgICAg ICBFeHBpcmVzIERlY2VtYmVyIDIwMDIgICAgICAgICAgICAgICAgW1BhZ2UgMTBdDQoMDQpJbnRl cm5ldCBEcmFmdCAgICBkcmFmdC1pZXRmLWlzaXMtZXh0LWxzcC1mcmFncy0wMS50eHQgICAgICAg ICBKdW5lIDIwMDINCg0KDQogICBUaGlzIGRvY3VtZW50IHJhaXNlcyBubyBuZXcgc2VjdXJpdHkg aXNzdWVzIGZvciBJUy1JUy4NCg0KDQo5LiAgQWNrbm93bGVkZ21lbnRzDQoNCiAgIFRoZSBhdXRo b3JzIHdvdWxkIGxpa2UgdG8gdGhhbmsgVG9ueSBMaSBhbmQgUmFkaWEgUGVybG1hbiBmb3IgaGVs cGZ1bA0KICAgY29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zIG9uIHRoZSBzdWJqZWN0Lg0KDQoNCjEw LiAgUmVmZXJlbmNlcw0KDQogICBbSVNJUy1JU09dIElTTyAxMDU4OSwgIkludGVybWVkaWF0ZSBT eXN0ZW0gdG8gSW50ZXJtZWRpYXRlIFN5c3RlbQ0KICAgSW50cmEtRG9tYWluIFJvdXRlaW5nIEV4 Y2hhbmdlIFByb3RvY29sIGZvciB1c2UgaW4gQ29uanVuY3Rpb24gd2l0aA0KICAgdGhlIFByb3Rv Y29sIGZvciBQcm92aWRpbmcgdGhlIENvbm5lY3Rpb25sZXNzLW1vZGUgTmV0d29yayBTZXJ2aWNl DQogICAoSVNPIDg0NzMpIg0KDQogICBbSVNJUy1JUF0gUkZDIDExOTUsICJVc2Ugb2YgT1NJIElT LUlTIGZvciByb3V0aW5nIGluIFRDUC9JUCBhbmQgZHVhbA0KICAgZW52aXJvbm1lbnRzIiwgUi5X LiBDYWxsb24sIERlYy4gMTk5MA0KDQogICBbRE9NQUlOLVdJREVdIFJGQyAyOTY2LCAiRG9tYWlu LXdpZGUgUHJlZml4IERpc3RyaWJ1dGlvbiB3aXRoIFR3by0NCiAgIExldmVsIElTLUlTIiwgVC4g TGksIFQuIFByenlnaWVuZGEsIEguIFNtaXQsIE9jdG9iZXIgMjAwMA0KDQogICBbQkNQMTRdIFJG QyAyMTE5LCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZSBSZXF1aXJlbWVu dA0KICAgTGV2ZWxzIiwgUy4gQnJhZG5lciwgTWFyY2ggMTk5Nw0KDQogICBbSVNJUy1DT0RFU10g V29yayBpbiBwcm9ncmVzcywgIlJlc2VydmVkIFRMViBDb2RlcG9pbnRzIGluIElTSVMiLCBULg0K ICAgUHJ6eWdpZW5kYQ0KDQogICBbSVNJUy1URV0gV29yayBpbiBwcm9ncmVzcywgIklTLUlTIGV4 dGVuc2lvbnMgZm9yIFRyYWZmaWMNCiAgIEVuZ2luZWVyaW5nIiwgVC4gTGksIEguIFNtaXQNCg0K DQoxMS4gIEF1dGhvcnMnIEFkZHJlc3Nlcw0KDQogICBBbWlyIEhlcm1lbGluICAgICAgICAgICAg ICAgICAgICAgICAgRW1haWw6IGFtaXJAY3dudC5jb20NCiAgIENoYXJsb3R0ZSdzIFdlYiBOZXR3 b3JrcywgSW5jLiAgICAgICBQaG9uZTogKzk3MiA0IDk1OTIyMDMNCiAgIDIgSGEnbWFkYSBTdC4g ICAgICAgICAgICAgICAgICAgICAgICBGYXg6ICAgKzk3MiA0IDk1OTMzMjUNCiAgIFBPQiA2NTAN CiAgIFlva25lYW0sIDIwNjkyDQogICBJU1JBRUwNCg0KDQogICBNaWtlIFNoYW5kLCAgICAgICAg ICAgICAgICAgICAgICAgICAgRW1haWw6IG1zaGFuZEBjaXNjby5jb20NCiAgIENpc2NvIFN5c3Rl bXMsICAgICAgICAgICAgICAgICAgICAgICBQaG9uZTogKzQ0IDAyMCA4ODI0IDg2OTANCiAgIDQs IFRoZSBTcXVhcmUsDQogICBTdG9ja2xleSBQYXJrLA0KICAgVVhCUklER0UsDQoNCg0KDQpBLiBI ZXJtZWxpbiwgZXQgYWwuICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjAwMiAgICAgICAgICAgICAg ICBbUGFnZSAxMV0NCgwNCkludGVybmV0IERyYWZ0ICAgIGRyYWZ0LWlldGYtaXNpcy1leHQtbHNw LWZyYWdzLTAxLnR4dCAgICAgICAgIEp1bmUgMjAwMg0KDQoNCiAgIE1pZGRsZXNleCwNCiAgIFVC MTEgMUJOLA0KICAgVUsNCg0KDQogICBTdGVmYW5vIFByZXZpZGkgICAgICAgICAgICAgICAgICAg ICAgZW1haWw6IHNwcmV2aWRpQGNpc2NvLmNvbQ0KICAgQ2lzY28gU3lzdGVtcywgSW5jLiAgICAg ICAgICAgICAgICAgIFBob25lOiArMzIgMiA3MDQ2NTkwDQogICBEZSBLbGVldGxhYW4gNkENCiAg IDE4MzEgRGllZ2VtDQogICBCZWxnaXVtDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkEuIEhlcm1l bGluLCBldCBhbC4gICAgICAgRXhwaXJlcyBEZWNlbWJlciAyMDAyICAgICAgICAgICAgICAgIFtQ YWdlIDEyXQ0KDA0K ------_=_NextPart_001_01C2189F.450E745A-- From jparker@axiowave.com Thu Jun 20 23:31:29 2002 From: jparker@axiowave.com (Jeff Parker) Date: Thu, 20 Jun 2002 18:31:29 -0400 Subject: [Isis-wg] Alternative Multicast Addresses for IS-IS Message-ID: > > 10589 defined an alternative set of multicast MAC addresses > > to be used on Token Ring... Does anyone use the > > Token Ring set of addresses, or can we drop this knob? > > > > - jeff parker > This stemmed from the old TI chipset that did not support multicast > receive, but only "functional addresses." I haven't seen token ring > in years, but that doesn't mean that somebody isn't still using it... > > Dave Katz Thanks, Dave. So we should be able to support any Token Ring system that uses more recent chips? It doesn't sound like we need to keep this around. - jeff parker From mshand@cisco.com Fri Jun 21 09:43:09 2002 From: mshand@cisco.com (mike shand) Date: Fri, 21 Jun 2002 09:43:09 +0100 Subject: [Isis-wg] draft-ietf-isis-restart-01.txt In-Reply-To: Message-ID: <4.3.2.7.2.20020621093939.026916b8@jaws.cisco.com> At 18:39 18/06/2002 +0000, Kent Wong wrote: >Hi Mike and Russ, > >Thanks for your reply. I have a couple more comments on the draft: > >4. I don't understand why there is a need for two different timers >T2 and T3. Because when T2 expires/cancels before T3, T3 would be >cancelled anyway. When BOTH T2s have expired >The only case T3 is supposed to be useful is >when T3 expires before T2. The draft states that if T3 expires >before T2, router's own LSP for level which have not completed >their first SPF should be flooded with the OL bit set. > >However this assumes that the restarting router has acquired its >own pre-start LSP before T3 expires. What if T3 expires even before >it acquires its pre-start LSP? In that case, it doesn't know what >sequence number it should use in its zero LSP to set the OL bit. >If the seq num it uses is smaller than the seq num in its nbr's DB, >then the zero LSP will be ignored by the helper nbr anyway. No it won't, the neighbor will send back the latest version, and the restarting router will override it with the next highest value. >So why not just combine T2 and T3 into a single timer and set the >timer to be the min. remaining holding time of its nbrs. If the timer >expires before it DB re-sync, then graceful restart fails >and everything reverts back to normal. Isn't this much more simpler >and effective? Yes you could have a single timer for each level, which you set to the value of T3. If it goes off for either level, then you abort the whole thing (as if T3 had gone off). But I think that is rather harder to describe. >5. On section 4.3.1.1, the draft mentions the behavior of a router >when it starts for the first time. Does it mean this draft intends to >change the normal ISIS behavior even though it is not a restart? Yes, optionally. The idea is to get the equivalent of the OSPF adjacency start behaviour so that you avoid the black hole on startup problem. >That means we need to start T2 (but no T1, T3) for each level even >we start for the first time. However, it may not be desirable to set >the OL bit every time ISIS comes up. This should be decided by the >network admin on individual cases whether to set the OL bit or not. No you need T1 as well. The whole point is that you have a RELIABLE CSNP exchange, and so you can correctly determine when you are synchronized and hence clear the overload bit at the right time, rather than (as we do now) simply waiting for some time pulled out of the air. >6. Just for clarification, in the draft, it mentions "own" LSP >many times, sometimes it mention own non-pseudonode LSP, sometimes >it mention own LSP including pseudonode. Sometimes, it simply >mention "own" LSP. Should we interpret the "own" LSP as including >pseudonode LSP if it doesn't specify otherwise? Yes (hopefully). Mike >Thanks! > >Kent Wong > >>From: mike shand >>To: "Kent Wong" >>CC: isis-wg@spider.juniper.net >>Subject: Re: [Isis-wg] draft-ietf-isis-restart-01.txt >>Date: Tue, 18 Jun 2002 10:29:48 +0100 >> >>At 22:25 17/06/2002 +0000, Kent Wong wrote: >>>Hi, >>> >>>I have some questions and comments on the isis restart draft: >>> >>>1. On Page 6 >>>"....a router MAY transmit one or more normal IIHs >>>(containing a restart option, but with RR and RA clear) after the >>>initial RR/RA exchange, but before synchronization has been >>>achieved, in order to extend the holding time of the neighbors >>>adjacencies, beyond that indicated in the remaining time field of >>>the neighbors IIH with the RA bit set." >>> >>>When a router does this, should it also extend T3 to be the new >>>holding time? Otherwise, even though we extend nbr's holding time >>>for the adjacency, T3 will still expire in a short time and LSP >>>with OL bit set will be generated and the graceful restart will >>>fail anyway. >> >>Yes. That was the assumption. Sorry that wasn't made clear. >> >> >>>2. Instead of sending normal IIH after initial RR/RA exchange, >>>would it make more sense that if this is a planned restart, >>>a normal IIH with a large holding time is sent before the router >>>going down so that nbr will hold the adjacency until restarting >>>router finishes the complete restart procedure. In that way, there >>>is no need to send extra normal IIH after initial RR/RA exchange. >> >>Yes that is possible too. My take on this is that the protocol mechanisms >>described in the spec can be used in a variety of creative ways which do >>not necessarily need to be spelled out in the draft because they do not >>require explicit co-operation. This is an example of such a mechanism. >> >> >>>3. If T2 on both levels expires/cancelled, it means end of >>>database resync and if T3 is still running, we should cancel >>>T3 at this time. Is that correct? The draft did not say this explicitly. >> >>Yes. >> >>>Thanks. >>> >>>Kent Wong >>> >>>_________________________________________________________________ >>>MSN Photos is the easiest way to share and print your photos: >>>http://photos.msn.com/support/worldwide.aspx >>> >>>_______________________________________________ >>>Isis-wg mailing list - Isis-wg@spider.juniper.net >>>http://spider.juniper.net/mailman/listinfo/isis-wg > > > > >_________________________________________________________________ >Send and receive Hotmail on your mobile device: http://mobile.msn.com > From mshand@cisco.com Fri Jun 21 09:46:54 2002 From: mshand@cisco.com (mike shand) Date: Fri, 21 Jun 2002 09:46:54 +0100 Subject: [Isis-wg] draft-ietf-isis-restart-01.txt In-Reply-To: <20020618224027.D497E39B5BC@prattle.redback.com> References: <4.3.2.7.2.20020524091256.04406478@jaws.cisco.com> Message-ID: <4.3.2.7.2.20020621094451.026ad460@jaws.cisco.com> At 15:40 18/06/2002 -0700, Naiming Shen wrote: >Mike, > > ] I have retained the non-timer resetting behavior of the RR IIH because I > ] think it is useful in some cases but have noted that if you want the > ] resetting behavior you can easily get this by sending a normal IIH > once you > ] have acquired the necessary circuit IDs etc. So the way it would work is > ] that you would re-start and get back the remaining time on each > adjacency. > ] If this is plenty of time you just carry on as normal. If you feel you > need > ] more time (and you are configured to allow that), then you send an IIH > with > ] the required holding time. > >I still have problem of this. yes, you may be able to send out "normal" >IIHs with large holdtime, but that's an extra step. i don't see much >reasoning this step is needed; Also more importantly, you may not be >able to send this "normal" IIH over a LAN unless you are sure you got >all the neighbors without missing one. this is too much dependancy >without benefit. > >I can understand you don't want to change the current tlv format, since >it's out there for a while and there may be some implementations running >which can cause incompatibility. I would say let's just keep this format. >the helper still send back whatever it thinks the holdtime is for this >adjacency. We at least need to say that, if the implementation choose >to ignore the holdtime in the re-start IIH, it SHOULD offer a config >knob so this can be disabled when needed. This way ISPs can make sure >its consistant within the network. We have already seen some >implementation does NOT ignore this holdtime at least for the first >re-start IIH. This seems reasonable. So we return the actual holding time with the RA and use the minimum of those as the time we have left to get re-synched. That way it doesn't matter whether a neighbor resets the adjacency holding time or not. AS long as it tells us the result we are cool. Mike > ] > ] Similarly, I have retained the retries, but said that you may > ] configurea retry count of zero. > >This does not matter too much comparing to the above. this is basically >a local implementation issue. Probably should mentioning the p2p vs >LAN problems here. > >thanks. >- Naiming From Internet-Drafts@ietf.org Fri Jun 21 12:36:12 2002 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Fri, 21 Jun 2002 07:36:12 -0400 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-interoperable-01.txt Message-ID: <200206211136.HAA07899@ietf.org> --NextPart 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 : Recommendations for Interoperable IP Networks using IS-IS Author(s) : J. Parker Filename : draft-ietf-isis-interoperable-01.txt Pages : 20 Date : 20-Jun-02 In theory, there is no difference between theory and practice. But in practice, there is. Jan L.A. van de Snepscheut This document discusses a number of differences between the IS-IS protocol as described in ISO 10589 [1] and RFC 1195 [3] and the protocol as it is deployed today. These differences are discussed as a service to those implementing, testing, and deploying the IS-IS Protocol to route IP traffic. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-interoperable-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-interoperable-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-interoperable-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020620141511.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-interoperable-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-interoperable-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020620141511.I-D@ietf.org> --OtherAccess-- --NextPart-- From ramsrm@tdd.sj.nec.com" hi all, could u please explain me the following doubts? In the ISIS extensions for TE draft, * IPV4 Address sub TLV gives the IPv4 Address of the interface described by the main TLV. Main TLV is IS extended reachability TLV. And IS extended reachability describes about the link to the neighbour. So the IPv4 Address of the interface described is the IPv4 Address of the neighbour. is this right? if so, what does the IPv4 neighbour address sub TLV describe? * we have IP reachability TLV also. Could u please explain me the reason why all the TE properties sub TLVs are added to IS reachability TLV rather than IP reachability TLV?. thanks rams. From naiming@redback.com Mon Jun 24 21:04:13 2002 From: naiming@redback.com (Naiming Shen) Date: Mon, 24 Jun 2002 13:04:13 -0700 Subject: [Isis-wg] draft-ietf-isis-restart-01.txt In-Reply-To: Mail from mike shand dated Fri, 21 Jun 2002 09:46:54 BST <4.3.2.7.2.20020621094451.026ad460@jaws.cisco.com> Message-ID: <20020624200414.03D0839B5A3@prattle.redback.com> ] At 15:40 18/06/2002 -0700, Naiming Shen wrote: ] ] >Mike, ] > ] > ] I have retained the non-timer resetting behavior of the RR IIH because I ] > ] think it is useful in some cases but have noted that if you want the ] > ] resetting behavior you can easily get this by sending a normal IIH ] > once you ] > ] have acquired the necessary circuit IDs etc. So the way it would work i s ] > ] that you would re-start and get back the remaining time on each ] > adjacency. ] > ] If this is plenty of time you just carry on as normal. If you feel you ] > need ] > ] more time (and you are configured to allow that), then you send an IIH ] > with ] > ] the required holding time. ] > ] >I still have problem of this. yes, you may be able to send out "normal" ] >IIHs with large holdtime, but that's an extra step. i don't see much ] >reasoning this step is needed; Also more importantly, you may not be ] >able to send this "normal" IIH over a LAN unless you are sure you got ] >all the neighbors without missing one. this is too much dependancy ] >without benefit. ] > ] >I can understand you don't want to change the current tlv format, since ] >it's out there for a while and there may be some implementations running ] >which can cause incompatibility. I would say let's just keep this format. ] >the helper still send back whatever it thinks the holdtime is for this ] >adjacency. We at least need to say that, if the implementation choose ] >to ignore the holdtime in the re-start IIH, it SHOULD offer a config ] >knob so this can be disabled when needed. This way ISPs can make sure ] >its consistant within the network. We have already seen some ] >implementation does NOT ignore this holdtime at least for the first ] >re-start IIH. ] ] This seems reasonable. So we return the actual holding time with the RA and ] use the minimum of those as the time we have left to get re-synched. That ] way it doesn't matter whether a neighbor resets the adjacency holding time ] or not. AS long as it tells us the result we are cool. exactly. thanks. ] ] Mike ] ] ] > ] ] > ] Similarly, I have retained the retries, but said that you may ] > ] configurea retry count of zero. ] > ] >This does not matter too much comparing to the above. this is basically ] >a local implementation issue. Probably should mentioning the p2p vs ] >LAN problems here. ] > ] >thanks. ] >- Naiming ] - Naiming From naiming@redback.com Mon Jun 24 21:06:46 2002 From: naiming@redback.com (Naiming Shen) Date: Mon, 24 Jun 2002 13:06:46 -0700 Subject: [Isis-wg] I-D ACTION:draft-shen-isis-iih-sequence-00.txt Message-ID: <20020624200647.0B33326280D@prattle.redback.com> this draft on isis seq# just posted. pls review and send any comment you may have. thanks. - Naiming ------- Forwarded Message To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-shen-isis-iih-sequence-00.txt Date: Fri, 21 Jun 2002 07:36:50 -0400 Sender: nsyracus@cnri.reston.va.us - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : ISIS IIH Sequence Number Scheme Author(s) : N. Shen, S. Luong Filename : draft-shen-isis-iih-sequence-00.txt Pages : 4 Date : 20-Jun-02 This draft describes an optional sequence number TLV inside the ISIS IIH packets. This sequence number TLV can be used for ISIS adjacency troubleshooting especially in the case where a large number of adjacencies are maintained and/or a low adjacency holddown time is used for the purpose of fast convergence. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-shen-isis-iih-sequence-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-shen-isis-iih-sequence-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-shen-isis-iih-sequence-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020620141640.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-shen-isis-iih-sequence-00.txt - --OtherAccess Content-Type: Message/External-body; name="draft-shen-isis-iih-sequence-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020620141640.I-D@ietf.org> - --OtherAccess-- - --NextPart-- ------- End of Forwarded Message From ramsrm@tdd.sj.nec.com" hi all, could u please explain me the following doubts? In the ISIS extensions for TE draft, * IPV4 Address sub TLV gives the IPv4 Address of the interface described by the main TLV. Main TLV is IS extended reachability TLV. And IS extended reachability describes about the link to the neighbour. So the IPv4 Address of the interface described is the IPv4 Address of the neighbour. is this right? if so, what does the IPv4 neighbour address sub TLV describe? * we have IP reachability TLV also. Could u please explain me the reason why all the TE properties sub TLVs are added to IS reachability TLV rather than IP reachability TLV?. thanks rams. From ramsrm@tdd.sj.nec.com" hi all, could u please explain me the following doubts? In the ISIS extensions for TE draft, * IPV4 Address sub TLV gives the IPv4 Address of the interface described by the main TLV. Main TLV is IS extended reachability TLV. And IS extended reachability describes about the link to the neighbour. So the IPv4 Address of the interface described is the IPv4 Address of the neighbour. is this right? if so, what does the IPv4 neighbour address sub TLV describe? * we have IP reachability TLV also. Could u please explain me the reason why all the TE properties sub TLVs are added to IS reachability TLV rather than IP reachability TLV?. thanks rams. From Internet-Drafts@ietf.org Wed Jun 26 11:40:37 2002 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Wed, 26 Jun 2002 06:40:37 -0400 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-gmpls-extensions-13.txt Message-ID: <200206261040.GAA10269@ietf.org> --NextPart 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 : IS-IS Extensions in Support of Generalized MPLS Author(s) : K. Kompella, Y. Rekhter Filename : draft-ietf-isis-gmpls-extensions-13.txt Pages : 11 Date : 25-Jun-02 This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-gmpls-extensions-13.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-gmpls-extensions-13.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-gmpls-extensions-13.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020625141630.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-gmpls-extensions-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-gmpls-extensions-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020625141630.I-D@ietf.org> --OtherAccess-- --NextPart-- From dang@nexthop.com Wed Jun 26 21:42:42 2002 From: dang@nexthop.com (Daniel Gryniewicz) Date: Wed, 26 Jun 2002 16:42:42 -0400 Subject: [Isis-wg] 3 Way Handshake In-Reply-To: References: Message-ID: <20020626164242.24881bdc.dang@nexthop.com> On Wed, 26 Jun 2002 20:11:31 +0000 "Suresh Boddapati" wrote: > I have a question regarding the 3 way handshake draft (I guess now it is in > limbo land where it is waiting to become an informational RFC). > > The state machine indicates that if the existing 3 way adjacency state is UP > and we receive a 3 way adjacency state of DOWN, the action should be INIT. > > This does not seem right. The fact that you had a 3 way state that was up > and now the nbr says it is down, shouldnt we restart the adjacency? This may > be one way of the nbr wanting to restart the adjacency. I think the state > should be DOWN and not INIT. > If you ever receive a 3-way with state DOWN, you go to INIT. Doesn't matter if you're DOWN, INIT, UP, whatever. If you're DOWN and go to INIT, why not go to INIT if you're UP? Saves you one IIH round trip. Daniel From ramsrm@tdd.sj.nec.com" hi all, could u please explain me the following doubts? In the ISIS extensions for TE draft, * IPV4 Address sub TLV gives the IPv4 Address of the interface described by the main TLV. Main TLV is IS extended reachability TLV. And IS extended reachability describes about the link to the neighbour. So the IPv4 Address of the interface described is the IPv4 Address of the neighbour. is this right? if so, what does the IPv4 neighbour address sub TLV describe? * we have IP reachability TLV also. Could u please explain me the reason why all the TE properties sub TLVs are added to IS reachability TLV rather than IP reachability TLV?. thanks rams. From jparker@axiowave.com Wed Jun 26 21:56:26 2002 From: jparker@axiowave.com (Jeff Parker) Date: Wed, 26 Jun 2002 16:56:26 -0400 Subject: [Isis-wg] 3 Way Handshake Message-ID: Initializing The system has received IIH packet containing the three-way handshake option from a neighbor but does not know whether the neighbor is receiving its IIH packet. > The state machine indicates that if the existing 3 way > adjacency state is UP and we receive a 3 way adjacency > state of DOWN, the action should be INIT. Do you see a case where this leads to problems? INIT simply tells us that there is something out there: it doesn't imply any adjacency. It -will- allow you to shortcut the steps needed to move through the FSM to get to UP. > If you already had a 3 way nbr > state of UP and let's say the IS got switched with > another IS that does not support 3 way TLV, going > by the draft, we will not detect the change in the > system. We will continue to keep the adjacency > when in fact we should restart it. > > Suresh Good point, though I wouldn't expect to see it often in practice. - jeff parker From rsaluja@nortelnetworks.com Wed Jun 26 22:04:52 2002 From: rsaluja@nortelnetworks.com (Rajesh Saluja) Date: Wed, 26 Jun 2002 17:04:52 -0400 Subject: [Isis-wg] 3 Way Handshake References: Message-ID: <3D1A2C74.B9390F92@nortelnetworks.com> Suresh Boddapati wrote: > I have a question regarding the 3 way handshake draft (I guess now it is in > limbo land where it is waiting to become an informational RFC). > > The state machine indicates that if the existing 3 way adjacency state is UP > and we receive a 3 way adjacency state of DOWN, the action should be INIT. > > This does not seem right. The fact that you had a 3 way state that was up > and now the nbr says it is down, shouldnt we restart the adjacency? This may > be one way of the nbr wanting to restart the adjacency. I think the state > should be DOWN and not INIT. INIT means that the system has heard from its neighbor but not sure whether the neighbor has heard it. This is the first step in restarting the adjacency. The neighbor will detect the reinitialization of the system when it receives the Hello from the system with the three-way state as Initializing. I do not understand why you need to go to DOWN state which will take an extra hello packet for adjacency to restart. > > > Same thing applies in the case where you receive a ptop IIH with the 3 way > state TLV being absent. The draft says "A received ptop IIH PDU may or may > not contain the PTOP 3 way adj option. If it does not, the link is assumed > to be functional in both directions....". If you already had a 3 way nbr > state of UP and let's say the IS got switched with another IS that does not > support 3 way TLV, going by the draft, we will not detect the change in the > system. We will continue to keep the adjacency when in fact we should > restart it. Since the system is no more supporting three-way handshake, the adjacency flap can not be detected. This is one of the reasons why you need three-way handshake mechanism in the first place. Hope it helps. Thanks, Rajesh > > > Comments? > > Suresh > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. > > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg -- ------------------------------------------------------------- Rajesh Saluja Nortel Networks Inc 600 Technology Park Billerica, MA 01821 Ph: (978) 288-7791 Fax: (978) 670-8760 -------------------------------------------------------------- From sboddapa@hotmail.com Wed Jun 26 22:45:11 2002 From: sboddapa@hotmail.com (Suresh Boddapati) Date: Wed, 26 Jun 2002 21:45:11 +0000 Subject: [Isis-wg] 3 Way Handshake Message-ID: >From: "Rajesh Saluja" >To: Suresh Boddapati >CC: isis-wg@spider.juniper.net >Subject: Re: [Isis-wg] 3 Way Handshake >Date: Wed, 26 Jun 2002 17:04:52 -0400 > >Suresh Boddapati wrote: > > > I have a question regarding the 3 way handshake draft (I guess now it is >in > > limbo land where it is waiting to become an informational RFC). > > > > The state machine indicates that if the existing 3 way adjacency state >is UP > > and we receive a 3 way adjacency state of DOWN, the action should be >INIT. > > > > This does not seem right. The fact that you had a 3 way state that was >up > > and now the nbr says it is down, shouldnt we restart the adjacency? This >may > > be one way of the nbr wanting to restart the adjacency. I think the >state > > should be DOWN and not INIT. > >INIT means that the system has heard from its neighbor but not sure whether >the >neighbor has heard it. This is the first step in restarting the adjacency. >The >neighbor will detect the reinitialization of the system when it receives >the >Hello from the system with the three-way state as Initializing. I do not >understand why you need to go to DOWN state which will take an extra hello >packet for adjacency to restart. > In this case we are referring to 3 way state of INIT, not the adjacency state of INIT. You have declared the adjacency to be UP and are using the 3 way mechanism to ensure that you always have adjacency to the same system. Now, if you transition from 3 way state of UP to 3 way state of INIT, that does not take down the adjacency per the current specification, does it?. Consider the initial case. Both sides support 3 way handshake. Both sides send each other IIH with 3 way state of DOWN. Do you consider the adjacency UP? You dont. You just consider it initializing. You will not report this adjacency to anybody since it is not up. In the case I was referring to, you are already considering the adjacency UP because the previous IIH did indicate the 3 way state to be UP. Now, if you constantly get IIHs with 3 way state DOWN, you will continue to treat the adjacency as UP even though it should no longer be treated as UP. Am I missing something? This extra step in adjacency formation does have an advantage IMO, other than making the state machine foolproof. Typically well behaved implementations (even OSPF implementations for that matter) do send out "empty" hellos when they are shutting down (due to a manual configuration change) which helps the other side detect that the adjacency needs to be taken out immediately since the other side does not see itself in the hello. For ptop hellos, since there is no nbr info TLV sent out, the 3 way handshake scheme can be used to bring down the adjacency immediately like the way I mentioned. Otherwise the hold time has to expire for bringing the adjacency down. Since the mechanism already exists, why not use it? > > > > > > > Same thing applies in the case where you receive a ptop IIH with the 3 >way > > state TLV being absent. The draft says "A received ptop IIH PDU may or >may > > not contain the PTOP 3 way adj option. If it does not, the link is >assumed > > to be functional in both directions....". If you already had a 3 way nbr > > state of UP and let's say the IS got switched with another IS that does >not > > support 3 way TLV, going by the draft, we will not detect the change in >the > > system. We will continue to keep the adjacency when in fact we should > > restart it. > >Since the system is no more supporting three-way handshake, the adjacency >flap >can not be detected. This is one of the reasons why you need three-way >handshake mechanism in the first place. But you CAN detect it because the previous IIH did indicate that the nbr supported 3 way. It is better to recycle the adjacency to take care of the case that I mentioned than to let it continue to be UP. Dont you think? > >Hope it helps. > >Thanks, >Rajesh > > > > > > > > Comments? > > > > Suresh > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at >http://explorer.msn.com/intl.asp. > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@spider.juniper.net > > http://spider.juniper.net/mailman/listinfo/isis-wg > >-- > >------------------------------------------------------------- >Rajesh Saluja >Nortel Networks Inc 600 Technology Park Billerica, MA 01821 >Ph: (978) 288-7791 Fax: (978) 670-8760 >-------------------------------------------------------------- _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx From dkatz@juniper.net Wed Jun 26 23:58:29 2002 From: dkatz@juniper.net (Dave Katz) Date: Wed, 26 Jun 2002 15:58:29 -0700 (PDT) Subject: [Isis-wg] 3 Way Handshake In-Reply-To: (sboddapa@hotmail.com) References: Message-ID: <200206262258.g5QMwTY13684@cirrus.juniper.net> INIT state is appropriate because it indicates that the adjacency is half-up (which it is.) Since it is not in UP state, the adjacency is not functioning and is removed from the advertised LSPs. From the standpoint of the network topology, there is no difference between INIT and DOWN--I'm not sure what you think the impact of choosing DOWN vs. INIT would be (other than an additional packet to bring the adjacency back up.) As far as the loss of the 3-way option goes, the case that you describe would bring down the adjacency anyhow because of the changed system ID (though it would have to time out first.) The language is there simply to be backward compatible. I don't think the disappearance of the option is a case worth optimizing (particularly at this point in the life cycle of the document.) --Dave X-Originating-IP: [63.104.212.252] From: "Suresh Boddapati" Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 26 Jun 2002 20:11:32.0016 (UTC) FILETIME=[A9E9E300:01C21D4D] Sender: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 26 Jun 2002 20:11:31 +0000 I have a question regarding the 3 way handshake draft (I guess now it is in limbo land where it is waiting to become an informational RFC). The state machine indicates that if the existing 3 way adjacency state is UP and we receive a 3 way adjacency state of DOWN, the action should be INIT. This does not seem right. The fact that you had a 3 way state that was up and now the nbr says it is down, shouldnt we restart the adjacency? This may be one way of the nbr wanting to restart the adjacency. I think the state should be DOWN and not INIT. Same thing applies in the case where you receive a ptop IIH with the 3 way state TLV being absent. The draft says "A received ptop IIH PDU may or may not contain the PTOP 3 way adj option. If it does not, the link is assumed to be functional in both directions....". If you already had a 3 way nbr state of UP and let's say the IS got switched with another IS that does not support 3 way TLV, going by the draft, we will not detect the change in the system. We will continue to keep the adjacency when in fact we should restart it. Comments? Suresh _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From sboddapa@hotmail.com Thu Jun 27 00:14:52 2002 From: sboddapa@hotmail.com (Suresh Boddapati) Date: Wed, 26 Jun 2002 23:14:52 +0000 Subject: [Isis-wg] 3 Way Handshake Message-ID: >From: Dave Katz >To: sboddapa@hotmail.com >CC: isis-wg@spider.juniper.net >Subject: Re: [Isis-wg] 3 Way Handshake >Date: Wed, 26 Jun 2002 15:58:29 -0700 (PDT) > >INIT state is appropriate because it indicates that the adjacency is >half-up (which it is.) Since it is not in UP state, the adjacency is >not functioning and is removed from the advertised LSPs. From the >standpoint of the network topology, there is no difference between >INIT and DOWN--I'm not sure what you think the impact of choosing DOWN >vs. INIT would be (other than an additional packet to bring the >adjacency back up.) My confusion arose from (see my reply to Rajesh's mail) my assumption that the draft seems to create a distinction between what is termed as "3 way adjacency state" and what is implicit to be an "Adjacency state" which is the 10589 adj state. Is this assumption wrong? Considering that the side that supports three way handshake lets the adjacency to be formed even if he does not receive the 3way option supports this assumption since you will have the adjacency state as UP and the three way adjacency state as DOWN. If my assumption is right, the specific case that I am concerned about is when you have both the adj state and the 3 way state in UP state AND you receive a IIH that has the 3 way option and the 3 way state is set to DOWN. Per the draft, the new action is INIT and the draft says "If the new action is INIT, the adjacency three way state shall be set to INIT". It does not say what to do with the existing adj state (not the 3 way state) that is UP. Assuming that is UP, if you continue to get IIHs with the 3 way state being DOWN, your adjacency will continue to stay UP and the 3 way state just stays at INIT which is wrong because you should not consider the adjacency as UP until the 3 way state has gone to UP. Maybe the text needs to be explicit and say that the adj state also needs to be INITed, i.e. an adjacencyStateChangeEvent(INIT) needs to be generated. > >As far as the loss of the 3-way option goes, the case that you describe >would bring down the adjacency anyhow because of the changed system ID >(though it would have to time out first.) The language is there simply >to be backward compatible. I don't think the disappearance of the option >is a case worth optimizing (particularly at this point in the life cycle >of the document.) > >--Dave > > X-Originating-IP: [63.104.212.252] > From: "Suresh Boddapati" > Content-Type: text/plain; format=flowed > X-OriginalArrivalTime: 26 Jun 2002 20:11:32.0016 (UTC) >FILETIME=[A9E9E300:01C21D4D] > Sender: isis-wg-admin@spider.juniper.net > X-BeenThere: isis-wg@spider.juniper.net > X-Mailman-Version: 2.0rc1 > Precedence: bulk > List-Help: > List-Post: > List-Subscribe: , > > List-Id: IETF IS-IS working group > List-Unsubscribe: , > > List-Archive: > Date: Wed, 26 Jun 2002 20:11:31 +0000 > > I have a question regarding the 3 way handshake draft (I guess now it >is in > limbo land where it is waiting to become an informational RFC). > > The state machine indicates that if the existing 3 way adjacency state >is UP > and we receive a 3 way adjacency state of DOWN, the action should be >INIT. > > This does not seem right. The fact that you had a 3 way state that was >up > and now the nbr says it is down, shouldnt we restart the adjacency? >This may > be one way of the nbr wanting to restart the adjacency. I think the >state > should be DOWN and not INIT. > > Same thing applies in the case where you receive a ptop IIH with the 3 >way > state TLV being absent. The draft says "A received ptop IIH PDU may or >may > not contain the PTOP 3 way adj option. If it does not, the link is >assumed > to be functional in both directions....". If you already had a 3 way >nbr > state of UP and let's say the IS got switched with another IS that does >not > support 3 way TLV, going by the draft, we will not detect the change in >the > system. We will continue to keep the adjacency when in fact we should > restart it. > > > Comments? > > Suresh > > _________________________________________________________________ > Get your FREE download of MSN Explorer at >http://explorer.msn.com/intl.asp. > > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com From dkatz@juniper.net Thu Jun 27 00:37:21 2002 From: dkatz@juniper.net (Dave Katz) Date: Wed, 26 Jun 2002 16:37:21 -0700 (PDT) Subject: [Isis-wg] 3 Way Handshake In-Reply-To: (sboddapa@hotmail.com) References: Message-ID: <200206262337.g5QNbLo13805@cirrus.juniper.net> It's been a long time since I looked at the text, but yes, if the 3-way state transitions to INIT, the adjacency should be affected as well. --Dave X-JNPR-Received-From: outside X-Originating-IP: [63.104.212.252] From: "Suresh Boddapati" Cc: isis-wg@spider.juniper.net Date: Wed, 26 Jun 2002 23:14:52 +0000 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 26 Jun 2002 23:14:52.0922 (UTC) FILETIME=[46F6EDA0:01C21D67] X-Scanned-By: MIMEDefang 2.15 (www dot roaringpenguin dot com slash mimedefang) >From: Dave Katz >To: sboddapa@hotmail.com >CC: isis-wg@spider.juniper.net >Subject: Re: [Isis-wg] 3 Way Handshake >Date: Wed, 26 Jun 2002 15:58:29 -0700 (PDT) > >INIT state is appropriate because it indicates that the adjacency is >half-up (which it is.) Since it is not in UP state, the adjacency is >not functioning and is removed from the advertised LSPs. From the >standpoint of the network topology, there is no difference between >INIT and DOWN--I'm not sure what you think the impact of choosing DOWN >vs. INIT would be (other than an additional packet to bring the >adjacency back up.) My confusion arose from (see my reply to Rajesh's mail) my assumption that the draft seems to create a distinction between what is termed as "3 way adjacency state" and what is implicit to be an "Adjacency state" which is the 10589 adj state. Is this assumption wrong? Considering that the side that supports three way handshake lets the adjacency to be formed even if he does not receive the 3way option supports this assumption since you will have the adjacency state as UP and the three way adjacency state as DOWN. If my assumption is right, the specific case that I am concerned about is when you have both the adj state and the 3 way state in UP state AND you receive a IIH that has the 3 way option and the 3 way state is set to DOWN. Per the draft, the new action is INIT and the draft says "If the new action is INIT, the adjacency three way state shall be set to INIT". It does not say what to do with the existing adj state (not the 3 way state) that is UP. Assuming that is UP, if you continue to get IIHs with the 3 way state being DOWN, your adjacency will continue to stay UP and the 3 way state just stays at INIT which is wrong because you should not consider the adjacency as UP until the 3 way state has gone to UP. Maybe the text needs to be explicit and say that the adj state also needs to be INITed, i.e. an adjacencyStateChangeEvent(INIT) needs to be generated. > >As far as the loss of the 3-way option goes, the case that you describe >would bring down the adjacency anyhow because of the changed system ID >(though it would have to time out first.) The language is there simply >to be backward compatible. I don't think the disappearance of the option >is a case worth optimizing (particularly at this point in the life cycle >of the document.) > >--Dave > > X-Originating-IP: [63.104.212.252] > From: "Suresh Boddapati" > Content-Type: text/plain; format=flowed > X-OriginalArrivalTime: 26 Jun 2002 20:11:32.0016 (UTC) >FILETIME=[A9E9E300:01C21D4D] > Sender: isis-wg-admin@spider.juniper.net > X-BeenThere: isis-wg@spider.juniper.net > X-Mailman-Version: 2.0rc1 > Precedence: bulk > List-Help: > List-Post: > List-Subscribe: , > > List-Id: IETF IS-IS working group > List-Unsubscribe: , > > List-Archive: > Date: Wed, 26 Jun 2002 20:11:31 +0000 > > I have a question regarding the 3 way handshake draft (I guess now it >is in > limbo land where it is waiting to become an informational RFC). > > The state machine indicates that if the existing 3 way adjacency state >is UP > and we receive a 3 way adjacency state of DOWN, the action should be >INIT. > > This does not seem right. The fact that you had a 3 way state that was >up > and now the nbr says it is down, shouldnt we restart the adjacency? >This may > be one way of the nbr wanting to restart the adjacency. I think the >state > should be DOWN and not INIT. > > Same thing applies in the case where you receive a ptop IIH with the 3 >way > state TLV being absent. The draft says "A received ptop IIH PDU may or >may > not contain the PTOP 3 way adj option. If it does not, the link is >assumed > to be functional in both directions....". If you already had a 3 way >nbr > state of UP and let's say the IS got switched with another IS that does >not > support 3 way TLV, going by the draft, we will not detect the change in >the > system. We will continue to keep the adjacency when in fact we should > restart it. > > > Comments? > > Suresh > > _________________________________________________________________ > Get your FREE download of MSN Explorer at >http://explorer.msn.com/intl.asp. > > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com From rsaluja@nortelnetworks.com Thu Jun 27 15:36:01 2002 From: rsaluja@nortelnetworks.com (Rajesh Saluja) Date: Thu, 27 Jun 2002 10:36:01 -0400 Subject: [Isis-wg] 3 Way Handshake References: Message-ID: <3D1B22D1.B85AA8C3@nortelnetworks.com> > > In this case we are referring to 3 way state of INIT, not the adjacency > state of INIT. You have declared the adjacency to be UP and are using the 3 > way mechanism to ensure that you always have adjacency to the same system. > Now, if you transition from 3 way state of UP to 3 way state of INIT, that > does not take down the adjacency per the current specification, does it?. > Consider the initial case. Both sides support 3 way handshake. Both sides > send each other IIH with 3 way state of DOWN. Do you consider the adjacency > UP? You dont. You just consider it initializing. You will not report this > adjacency to anybody since it is not up. In the case I was referring to, you > are already considering the adjacency UP because the previous IIH did > indicate the 3 way state to be UP. Now, if you constantly get IIHs with 3 > way state DOWN, you will continue to treat the adjacency as UP even though > it should no longer be treated as UP. Am I missing something? IMHO I think we are talking about implementation details here. Conceptually we have two states i.e. 10589 and 3way but one could implement three-way handshake even without maintaining two states internally. The draft describes three-way state transitions and as I mentioned earlier, we did not want to delete the adjacency and again create it for the same neighbor. Thanks, Rajesh From sboddapa@hotmail.com Thu Jun 27 17:49:31 2002 From: sboddapa@hotmail.com (Suresh Boddapati) Date: Thu, 27 Jun 2002 16:49:31 +0000 Subject: [Isis-wg] 3 Way Handshake Message-ID: In summary, the text of the draft does not refer raising an adjacencyChangeEvent(INIT) when you transition from UP state upon receiving a 3way state of down in the IIH, which led to the confusion. It does require to raise these events for the UP and DOWN cases explicitly which seemed to give the impression that the adjacency needs to be kept up even if you received a 3 way state of DOWN. I am fine with transitioning the adjacency to INIT state. The text could have been a little more explicit, IMHO. >From: "Rajesh Saluja" >To: Suresh Boddapati >CC: "Rajesh Saluja" , >isis-wg@spider.juniper.net >Subject: Re: [Isis-wg] 3 Way Handshake >Date: Thu, 27 Jun 2002 10:36:01 -0400 > > > > > In this case we are referring to 3 way state of INIT, not the adjacency > > state of INIT. You have declared the adjacency to be UP and are using >the 3 > > way mechanism to ensure that you always have adjacency to the same >system. > > Now, if you transition from 3 way state of UP to 3 way state of INIT, >that > > does not take down the adjacency per the current specification, does >it?. > > Consider the initial case. Both sides support 3 way handshake. Both >sides > > send each other IIH with 3 way state of DOWN. Do you consider the >adjacency > > UP? You dont. You just consider it initializing. You will not report >this > > adjacency to anybody since it is not up. In the case I was referring to, >you > > are already considering the adjacency UP because the previous IIH did > > indicate the 3 way state to be UP. Now, if you constantly get IIHs with >3 > > way state DOWN, you will continue to treat the adjacency as UP even >though > > it should no longer be treated as UP. Am I missing something? > >IMHO I think we are talking about implementation details here. >Conceptually we >have two states i.e. 10589 and 3way but one could implement three-way >handshake >even without maintaining two states internally. The draft describes >three-way >state transitions and as I mentioned earlier, we did not want to delete the >adjacency and again create it for the same neighbor. > >Thanks, >Rajesh _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. From prz@net4u.ch Fri Jun 28 20:09:28 2002 From: prz@net4u.ch (Tony Przygienda) Date: Fri, 28 Jun 2002 12:09:28 -0700 Subject: [Isis-wg] Inclusion of zero Length VLF References: <8AC36D3167EED41184C800508BD9540502DD6B64@apollo.adtech-inc.com> Message-ID: <3D1CB468.30007@net4u.ch> Chan, Chung Ming wrote: >Hi, > I just observed from one of the routers in our lab include VLF which >has zero length in its PDU. > For example, in the IIH, it contains an IS Neighbor VLF with no MAC >address in it. > > It looks to me that it won't do any harm, it will be ignored anyway >by the receiving router; >But it is meaningless to include something like that also. > >Is this one of the common ways of encoding a PDU? > I do not think anything in the spec prevents you from doing that but it's just one IF in the code to squelch it off for the given implementaiton and surely more prudent than advertising 0 length TLVs -- tony > From Yongjun Im" Dear IS-IS Experts, As you know, IS-IS packets are encapsulated directly over Layer-2 frames, including Ethernet frame, AAL5 PDU, PPP frame. First of all, let me briefly describe the L2 header of each encapsulation below. 1. IS-IS packet over Ethernet frame. DA = 0x01-80-C2-00-00-14 (reserved MAC address of ISIS) SA = 0xXX-XX-XX-XX-XX-XX Length = 0xXX-XX DSAP = 0xFE SSAP = 0xFE Control = 0x03 NLPID = 0x83 ISIS PDU (variable) FCS 2. IS-IS packet over AAL5 PDU DSAP = 0xFE SSAP = 0xFE Control = 0x03 NLPID = 0x83 ISIS PDU (variable) AAL5 Trailer (8 bytes) 3. IS-IS packet over PPP/HDLC Flag = 0x7E (HDLC) Address = 0xFF Control = 0x03 Protocol = 0x23 NLPID = 0x83 ISIS PDU (variable) FCS (4bytes) Flag = 0x7E (HDLC) I think I'm pretty much sure regarding the Ethernet and AAL5 PDU encapsulation, while I'm wondering the PPP/HDLC encapsulation since I couldn't find any standard or implementation documentation about that. I would greatly appreciate if you could verify whether the PPP/HDLC encapsulation above is correct. In addition, I was told that Cisco uses the proprietary PPP/HDLC implementaion for ISIS packet that is described in Section 4.3.1 of RFC 1547. [Except from RFC 1547] "The Cisco Systems gateway supports both asynchronous links using SLIP and synchronous links using either simple HDLC framing, X.25 LAPB or full X.25. The HDLC framing procedure includes a four byte header. The first octet (address) is either 0x0F (unicast intent) or 0x8F (multicast intent). The second octet (control byte) is left zero and is not checked on reception. The third and fourth octets contain a standard 16 bit Ethernet protocol type code." In accordance with the description above, I think the L2 header format might be as follows; Flag = 0x7E (HDLC) Address = 0x8F Control = 0x00 DSAP = 0xFE SSAP = 0xFE Control = 0x03 NLPID = 0x83 ISIS PDU (variable) FCS (4bytes) Flag = 0x7E (HDLC) If the encapsulation I assumed above is correct, is that popular or just Cisco's proprietary? Which one is the most typical PPP/HDLC encapsulation for ISIS packet? When we operate the IS-IS protocol over PoS interface, which HDLC/PPP encapsulation is preferred and what kind of encapsulation options are available? Any interoperabilty issues? Any response or pointer to the related documentation will be greatly appreciated. Especially I would like to get reponse from Cisco and Juniper engineers. Take care, Yongjun.