From Alex Zinin <zinin@psg.com> Mon Jun 3 20:18:12 2002
From: Alex Zinin <zinin@psg.com> (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: <C7DF4400240AFB4095D98C7C6EC2A34A5EA476@bart.cwnt.com>
References: <C7DF4400240AFB4095D98C7C6EC2A34A5EA476@bart.cwnt.com>
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
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D001484113-04062002>Hello,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D001484113-04062002></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D001484113-04062002>Is =
there any=20
limitation on maximum number of Intermediate System can be =
configured in an=20
Area.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D001484113-04062002>If any =
one knows=20
please let me know.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D001484113-04062002></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D001484113-04062002>Thanks =
in=20
advance.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D001484113-04062002></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D001484113-04062002>Regards,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D001484113-04062002>Ramesh</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D001484113-04062002></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D001484113-04062002> </SPAN></FONT></DIV></BODY></HTML>
------=_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: <EB5FFC72F183D411B38200062957342901E576B6@r2d2.axiowave.com>
> 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: <H0000c0804978c2b.1023203478.mailw02@MHS>
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: <H0000c0804978c2b.1023203478.mailw02@MHS>
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: <EB5FFC72F183D411B38200062957342901E576C7@r2d2.axiowave.com>
> 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"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2655.35">
<TITLE>RE: [Isis-wg] last call on draft draft-ietf-isis-ext-lsp-frags-00 ...</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=2>> ...</FONT>
<BR><FONT SIZE=2>> >> > Extended system-id</FONT>
<BR><FONT SIZE=2>> >> </FONT>
<BR><FONT SIZE=2>> >> Sounds like we're stretching out the normal system-id.</FONT>
<BR><FONT SIZE=2>> >> Maybe "Virtual system-id" would be a better choice?</FONT>
<BR><FONT SIZE=2>> >> </FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> > again, could be bad naming. However, I originally thought </FONT>
<BR><FONT SIZE=2>> "Virtual" to be a little confusing,</FONT>
<BR><FONT SIZE=2>> > as a "virtual link" term is already used in the IS-IS spec, </FONT>
<BR><FONT SIZE=2>> for a completely different purpose. The</FONT>
<BR><FONT SIZE=2>> > draft uses "extended" for LSPs, since they really extend </FONT>
<BR><FONT SIZE=2>> the original LS information an IS could advertise,</FONT>
<BR><FONT SIZE=2>> > as opposed to "Virtual System", which doesn't really add </FONT>
<BR><FONT SIZE=2>> any additional info. Does that</FONT>
<BR><FONT SIZE=2>> > make sense?</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> "extended" LSPs, though not perfect, make more sense--I couldn't come</FONT>
<BR><FONT SIZE=2>> up with a better name, maybe native English speakers can :)</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> </FONT>
</P>
<P><FONT SIZE=2>Is this is a similar concept to "Extended Local Circuit ID" in three way handshaking?</FONT>
<BR><FONT SIZE=2>it sounds as though it is, in which case consistency is a good thing.</FONT>
</P>
<P><FONT SIZE=2>Philip</FONT>
</P>
</BODY>
</HTML>
------_=_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"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META content="MSHTML 5.00.2614.3500" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial size=2><SPAN class=680360110-10062002>Looking at <FONT
color=#000000 size=2>draft-ietf-isis-wg-tlv-codepoints-02.txt
</FONT></SPAN></FONT><FONT face=Arial size=2><SPAN class=680360110-10062002>I
notice that there is not really any mechanism for private or proprietary use of
a TLV.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=680360110-10062002></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=680360110-10062002>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?</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=680360110-10062002></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=680360110-10062002>Is there a way that
we could define that a certain TLV number is for private / proprietary /
experimental purposes?</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=680360110-10062002></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=680360110-10062002>This would then stop
people just picking one.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=680360110-10062002></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=680360110-10062002>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.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=680360110-10062002></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=680360110-10062002>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.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=680360110-10062002></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=680360110-10062002>Or maybe there is a
better way to identify a particular company / entity (like a MAC address)?
Maybe ISO 8348?</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=680360110-10062002></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=680360110-10062002>What do people
think?</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=680360110-10062002></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN
class=680360110-10062002>Philip</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=680360110-10062002></SPAN></FONT> </DIV></BODY></HTML>
------_=_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
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>RE: [Isis-wg] Proprietary / Private TLV numbers?</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>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</FONT></P>
<P><FONT SIZE=3D2>Then folks could use whichever mechanism they prefer, =
as long as it is a globally unique identifier.</FONT>
</P>
<P><FONT SIZE=3D2>Or is that too complex?</FONT>
</P>
<P><FONT SIZE=3D2>Philip</FONT>
</P>
<P><FONT SIZE=3D2>> -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>> From: mike shand [<A =
HREF=3D"mailto:mshand@cisco.com">mailto:mshand@cisco.com</A>]</FONT>
<BR><FONT SIZE=3D2>> Sent: Monday, June 10, 2002 12:24 PM</FONT>
<BR><FONT SIZE=3D2>> To: Christian, Philip [HAL02:GI50:EXCH]</FONT>
<BR><FONT SIZE=3D2>> Cc: isis-wg@spider.juniper.net</FONT>
<BR><FONT SIZE=3D2>> Subject: Re: [Isis-wg] Proprietary / Private =
TLV numbers?</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> At 11:29 10/06/2002 +0100, Philip Christian =
wrote:</FONT>
<BR><FONT SIZE=3D2>> >Looking at =
draft-ietf-isis-wg-tlv-codepoints-02.txt I notice </FONT>
<BR><FONT SIZE=3D2>> that there is </FONT>
<BR><FONT SIZE=3D2>> >not really any mechanism for private or =
proprietary use of a TLV.</FONT>
<BR><FONT SIZE=3D2>> ></FONT>
<BR><FONT SIZE=3D2>> >Thus various companies (including my own) =
have just pcked </FONT>
<BR><FONT SIZE=3D2>> one and used it </FONT>
<BR><FONT SIZE=3D2>> >for their own purpose. Eventually =
this will create an </FONT>
<BR><FONT SIZE=3D2>> interop problem, </FONT>
<BR><FONT SIZE=3D2>> >but what else is a company to do?</FONT>
<BR><FONT SIZE=3D2>> ></FONT>
<BR><FONT SIZE=3D2>> >Is there a way that we could define that a =
certain TLV number is for </FONT>
<BR><FONT SIZE=3D2>> >private / proprietary / experimental =
purposes?</FONT>
<BR><FONT SIZE=3D2>> ></FONT>
<BR><FONT SIZE=3D2>> >This would then stop people just picking =
one.</FONT>
<BR><FONT SIZE=3D2>> ></FONT>
<BR><FONT SIZE=3D2>> >I am thinking that there would have to be =
some sort of </FONT>
<BR><FONT SIZE=3D2>> entity identifier </FONT>
<BR><FONT SIZE=3D2>> >in there so that when you see this TLV you =
know whether it </FONT>
<BR><FONT SIZE=3D2>> is yours or not.</FONT>
<BR><FONT SIZE=3D2>> ></FONT>
<BR><FONT SIZE=3D2>> >Maybe we could define that the first four =
bytes are an IP </FONT>
<BR><FONT SIZE=3D2>> address for </FONT>
<BR><FONT SIZE=3D2>> >example. Any entity large enough to =
want to use a </FONT>
<BR><FONT SIZE=3D2>> proprietary TLV would </FONT>
<BR><FONT SIZE=3D2>> >have a public IP address to put in there, I =
would have </FONT>
<BR><FONT SIZE=3D2>> thought. After the </FONT>
<BR><FONT SIZE=3D2>> >first for bytes then the rest would be =
free.</FONT>
<BR><FONT SIZE=3D2>> ></FONT>
<BR><FONT SIZE=3D2>> >Or maybe there is a better way to identify =
a particular </FONT>
<BR><FONT SIZE=3D2>> company / entity </FONT>
<BR><FONT SIZE=3D2>> >(like a MAC address)? Maybe ISO =
8348?</FONT>
<BR><FONT SIZE=3D2>> ></FONT>
<BR><FONT SIZE=3D2>> >What do people think?</FONT>
<BR><FONT SIZE=3D2>> ></FONT>
<BR><FONT SIZE=3D2>> >Philip</FONT>
<BR><FONT SIZE=3D2>> ></FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> This has been suggested before, but never came =
to anything. I </FONT>
<BR><FONT SIZE=3D2>> think if it </FONT>
<BR><FONT SIZE=3D2>> WERE to be done then using something link the =
MAC OUI would </FONT>
<BR><FONT SIZE=3D2>> probably work. </FONT>
<BR><FONT SIZE=3D2>> What do you mean by ISO 8348? Do you mean ISO =
6523? I hope not :-)</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT =
SIZE=3D2>> =
Mike</FONT>
<BR><FONT SIZE=3D2>> </FONT>
</P>
</BODY>
</HTML>
------_=_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>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>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
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>RE: [Isis-wg] Proprietary / Private TLV numbers?</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>A vendor code of 4 octets could be an IPv4 =
address.</FONT>
<BR><FONT SIZE=3D2>Then no-one would have to assign them. The vendor =
just uses a global IPv4 address that he has.</FONT>
</P>
<P><FONT SIZE=3D2>Even the smallest vendor can buy a /32 IP address for =
this purpose.</FONT>
</P>
<P><FONT SIZE=3D2>That would work.</FONT>
</P>
<P><FONT SIZE=3D2>Philip</FONT>
</P>
<P><FONT SIZE=3D2>> -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>> From: Mike Truskowski [<A =
HREF=3D"mailto:truskows@cisco.com">mailto:truskows@cisco.com</A>]</FONT>=
<BR><FONT SIZE=3D2>> Sent: Monday, June 10, 2002 2:42 PM</FONT>
<BR><FONT SIZE=3D2>> To: mshand@cisco.com</FONT>
<BR><FONT SIZE=3D2>> Cc: Christian, Philip [HAL02:GI50:EXCH]; =
isis-wg@spider.juniper.net</FONT>
<BR><FONT SIZE=3D2>> Subject: Re: [Isis-wg] Proprietary / Private =
TLV numbers?</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Why not just do the following?</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> =
+-------------------------------------------------+</FONT>
<BR><FONT SIZE=3D2>> | Type | Length =
| =
Value &=
nbsp; |</FONT>
<BR><FONT SIZE=3D2>> =
+-------------------------------------------------+</FONT>
<BR><FONT SIZE=3D2>> | TLV # | Length | =
vendor code | "value" |</FONT>
<BR><FONT SIZE=3D2>> =
+-------------------------------------------------+</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Where the vendor code is a fixed 3-4 =
octets?</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> I guess one could do this on their own... =
couldn't they?</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> The major problem I see here is what Philip =
said he wanted to fix...</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> If vendors are doing this already and this is =
trying to avoid </FONT>
<BR><FONT SIZE=3D2>> interoperability</FONT>
<BR><FONT SIZE=3D2>> problems... then it would seem reasonable that =
the carrier </FONT>
<BR><FONT SIZE=3D2>> would go back and</FONT>
<BR><FONT SIZE=3D2>> install new images or force the vendor to fix =
the embedded </FONT>
<BR><FONT SIZE=3D2>> base.. but they </FONT>
<BR><FONT SIZE=3D2>> won't do either.. thus leaving the problem to =
stumble over some day...</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Mike</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> > At 13:43 10/06/2002 +0100, Philip =
Christian wrote:</FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > >I suppose that we could define =
different sub-TLVs, a </FONT>
<BR><FONT SIZE=3D2>> sub-TLV if the </FONT>
<BR><FONT SIZE=3D2>> > >identifier is an IPv4 address, a =
different sub-TLV if it </FONT>
<BR><FONT SIZE=3D2>> is a MAC address, etc</FONT>
<BR><FONT SIZE=3D2>> > ></FONT>
<BR><FONT SIZE=3D2>> > >Then folks could use whichever =
mechanism they prefer, as </FONT>
<BR><FONT SIZE=3D2>> long as it is a </FONT>
<BR><FONT SIZE=3D2>> > >globally unique identifier.</FONT>
<BR><FONT SIZE=3D2>> > ></FONT>
<BR><FONT SIZE=3D2>> > >Or is that too complex?</FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > Yes! That's how NSAP addresses got to be =
so awful :-)</FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> =
> Mike</FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > >Philip</FONT>
<BR><FONT SIZE=3D2>> > ></FONT>
<BR><FONT SIZE=3D2>> > > > -----Original =
Message-----</FONT>
<BR><FONT SIZE=3D2>> > > > From: mike shand </FONT>
<BR><FONT SIZE=3D2>> [<<A =
HREF=3D"mailto:mshand@cisco.com">mailto:mshand@cisco.com</A>><A =
HREF=3D"mailto:mshand@cisco.com">mailto:mshand@cisco.com</A>]</FONT>
<BR><FONT SIZE=3D2>> > > > Sent: Monday, June 10, 2002 =
12:24 PM</FONT>
<BR><FONT SIZE=3D2>> > > > To: Christian, Philip =
[HAL02:GI50:EXCH]</FONT>
<BR><FONT SIZE=3D2>> > > > Cc: =
isis-wg@spider.juniper.net</FONT>
<BR><FONT SIZE=3D2>> > > > Subject: Re: [Isis-wg] =
Proprietary / Private TLV numbers?</FONT>
<BR><FONT SIZE=3D2>> > > ></FONT>
<BR><FONT SIZE=3D2>> > > ></FONT>
<BR><FONT SIZE=3D2>> > > > At 11:29 10/06/2002 +0100, =
Philip Christian wrote:</FONT>
<BR><FONT SIZE=3D2>> > > > >Looking at =
draft-ietf-isis-wg-tlv-codepoints-02.txt I notice</FONT>
<BR><FONT SIZE=3D2>> > > > that there is</FONT>
<BR><FONT SIZE=3D2>> > > > >not really any mechanism for =
private or proprietary </FONT>
<BR><FONT SIZE=3D2>> use of a TLV.</FONT>
<BR><FONT SIZE=3D2>> > > > ></FONT>
<BR><FONT SIZE=3D2>> > > > >Thus various companies =
(including my own) have just pcked</FONT>
<BR><FONT SIZE=3D2>> > > > one and used it</FONT>
<BR><FONT SIZE=3D2>> > > > >for their own purpose. =
Eventually this will create an</FONT>
<BR><FONT SIZE=3D2>> > > > interop problem,</FONT>
<BR><FONT SIZE=3D2>> > > > >but what else is a company =
to do?</FONT>
<BR><FONT SIZE=3D2>> > > > ></FONT>
<BR><FONT SIZE=3D2>> > > > >Is there a way that we could =
define that a certain TLV </FONT>
<BR><FONT SIZE=3D2>> number is for</FONT>
<BR><FONT SIZE=3D2>> > > > >private / proprietary / =
experimental purposes?</FONT>
<BR><FONT SIZE=3D2>> > > > ></FONT>
<BR><FONT SIZE=3D2>> > > > >This would then stop people =
just picking one.</FONT>
<BR><FONT SIZE=3D2>> > > > ></FONT>
<BR><FONT SIZE=3D2>> > > > >I am thinking that there =
would have to be some sort of</FONT>
<BR><FONT SIZE=3D2>> > > > entity identifier</FONT>
<BR><FONT SIZE=3D2>> > > > >in there so that when you =
see this TLV you know whether it</FONT>
<BR><FONT SIZE=3D2>> > > > is yours or not.</FONT>
<BR><FONT SIZE=3D2>> > > > ></FONT>
<BR><FONT SIZE=3D2>> > > > >Maybe we could define that =
the first four bytes are an IP</FONT>
<BR><FONT SIZE=3D2>> > > > address for</FONT>
<BR><FONT SIZE=3D2>> > > > >example. Any entity =
large enough to want to use a</FONT>
<BR><FONT SIZE=3D2>> > > > proprietary TLV would</FONT>
<BR><FONT SIZE=3D2>> > > > >have a public IP address to =
put in there, I would have</FONT>
<BR><FONT SIZE=3D2>> > > > thought. After the</FONT>
<BR><FONT SIZE=3D2>> > > > >first for bytes then the =
rest would be free.</FONT>
<BR><FONT SIZE=3D2>> > > > ></FONT>
<BR><FONT SIZE=3D2>> > > > >Or maybe there is a better =
way to identify a particular</FONT>
<BR><FONT SIZE=3D2>> > > > company / entity</FONT>
<BR><FONT SIZE=3D2>> > > > >(like a MAC address)? =
Maybe ISO 8348?</FONT>
<BR><FONT SIZE=3D2>> > > > ></FONT>
<BR><FONT SIZE=3D2>> > > > >What do people think?</FONT>
<BR><FONT SIZE=3D2>> > > > ></FONT>
<BR><FONT SIZE=3D2>> > > > >Philip</FONT>
<BR><FONT SIZE=3D2>> > > > ></FONT>
<BR><FONT SIZE=3D2>> > > ></FONT>
<BR><FONT SIZE=3D2>> > > > This has been suggested before, =
but never came to anything. I</FONT>
<BR><FONT SIZE=3D2>> > > > think if it</FONT>
<BR><FONT SIZE=3D2>> > > > WERE to be done then using =
something link the MAC OUI would</FONT>
<BR><FONT SIZE=3D2>> > > > probably work.</FONT>
<BR><FONT SIZE=3D2>> > > > What do you mean by ISO 8348? Do =
you mean ISO 6523? I </FONT>
<BR><FONT SIZE=3D2>> hope not :-)</FONT>
<BR><FONT SIZE=3D2>> > > ></FONT>
<BR><FONT SIZE=3D2>> > > =
> Mike</FONT>
<BR><FONT SIZE=3D2>> > > ></FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>> > Isis-wg mailing list - =
Isis-wg@spider.juniper.net</FONT>
<BR><FONT SIZE=3D2>> > <A =
HREF=3D"http://spider.juniper.net/mailman/listinfo/isis-wg" =
TARGET=3D"_blank">http://spider.juniper.net/mailman/listinfo/isis-wg</A>=
</FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
</P>
</BODY>
</HTML>
------_=_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
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>RE: [Isis-wg] Proprietary / Private TLV numbers?</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>I have done an update, see below</FONT>
</P>
<P><FONT SIZE=3D2>Philip</FONT>
</P>
<P><FONT SIZE=3D2>> -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>> From: mike shand [<A =
HREF=3D"mailto:mshand@cisco.com">mailto:mshand@cisco.com</A>]</FONT>
<BR><FONT SIZE=3D2>> Sent: Tuesday, June 11, 2002 3:56 PM</FONT>
<BR><FONT SIZE=3D2>> To: Christian, Philip [HAL02:GI50:EXCH]</FONT>
<BR><FONT SIZE=3D2>> Cc: 'Tony Przygienda'; =
isis-wg@spider.juniper.net; 'Mike Truskowski'</FONT>
<BR><FONT SIZE=3D2>> Subject: RE: [Isis-wg] Proprietary / Private =
TLV numbers?</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> At 15:38 11/06/2002 +0100, Philip Christian =
wrote:</FONT>
<BR><FONT SIZE=3D2>> >On receipt of an LSP a router MUST ignore =
TLVs of type XXX that</FONT>
<BR><FONT SIZE=3D2>> > include an OUI from a =
different organization,</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> MUST is a bit strong here. SHOULD or MAY, =
perhaps. If you </FONT>
<BR><FONT SIZE=3D2>> know how to parse </FONT>
<BR><FONT SIZE=3D2>> company X's subTLVs you should be allowed to do =
so.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> I'm not sure we want to get into mentioning =
non-standard OUIs </FONT>
<BR><FONT SIZE=3D2>> with G or L </FONT>
<BR><FONT SIZE=3D2>> bits set.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT =
SIZE=3D2>> =
Mike</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
</P>
<P><FONT SIZE=3D2>Internet Engineering Task =
Force &=
nbsp; &=
nbsp; P. Christian </FONT>
<BR><FONT SIZE=3D2>INTERNET =
DRAFT &=
nbsp; &=
nbsp; &=
nbsp; Nortel Networks </FONT>
<BR><FONT =
SIZE=3D2> &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; June 2002 </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT =
SIZE=3D2> &nb=
sp; &nb=
sp; TLV for Proprietary Use </FONT>
<BR><FONT =
SIZE=3D2> &nb=
sp; =
draft-ietf-isis-private-tlv-forlist2.txt </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2>Status of this Memo </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> This document is an Internet-Draft and =
is in full conformance with </FONT>
<BR><FONT SIZE=3D2> all provisions of Section 10 of RFC =
2026. </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> Internet Drafts are working documents =
of the Internet Engineering </FONT>
<BR><FONT SIZE=3D2> Task Force (IETF), its Areas, and its =
Working Groups. Note that </FONT>
<BR><FONT SIZE=3D2> other groups may also distribute =
working documents as Internet </FONT>
<BR><FONT SIZE=3D2> Drafts. </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> Internet Drafts are draft documents =
valid for a maximum of six </FONT>
<BR><FONT SIZE=3D2> months. Internet Drafts may be =
updated, replaced, or obsoleted by </FONT>
<BR><FONT SIZE=3D2> other documents at any time. It =
is not appropriate to use Internet </FONT>
<BR><FONT SIZE=3D2> Drafts as reference material or to cite =
them other than as a </FONT>
<BR><FONT SIZE=3D2> "working draft" or "work =
in progress". </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> The list of current Internet-Drafts can =
be accessed at </FONT>
<BR><FONT SIZE=3D2> <A =
HREF=3D"http://www.ietf.org/ietf/1id-abstracts.txt" =
TARGET=3D"_blank">http://www.ietf.org/ietf/1id-abstracts.txt</A> =
</FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> The list of Internet-Draft Shadow =
Directories can be accessed at </FONT>
<BR><FONT SIZE=3D2> <A =
HREF=3D"http://www.ietf.org/shadow.html" =
TARGET=3D"_blank">http://www.ietf.org/shadow.html</A>. </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> This memo provides information for the =
Internet community. This memo </FONT>
<BR><FONT SIZE=3D2> does not specify an Internet standard =
of any kind. </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> Distribution of this draft is =
unlimited. </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2>1. Abstract </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> This document defines a TLV that may be =
used for vendor specific or </FONT>
<BR><FONT SIZE=3D2> experimental extensions to the IS-IS =
routing protocol, and defines </FONT>
<BR><FONT SIZE=3D2> the format of the TLV. </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2>2. Conventions used in this document </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> The key words "MUST", =
"MUST NOT", "REQUIRED", "SHALL", =
"SHALL NOT", </FONT>
<BR><FONT SIZE=3D2> "SHOULD", "SHOULD =
NOT", "RECOMMENDED", "MAY", and =
"OPTIONAL" in </FONT>
<BR><FONT SIZE=3D2> this document are to be interpreted as =
described in RFC 2119. </FONT>
<BR><FONT SIZE=3D2> </FONT>
</P>
<BR>
<BR>
<BR>
<BR>
<P><FONT SIZE=3D2> </FONT>
<BR><FONT =
SIZE=3D2> &nb=
sp; =
TLV for Proprietary =
Use &nb=
sp; June 2002 </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2>3. Introduction </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> IS-IS as defined in [1] has always been =
an extensible routing </FONT>
<BR><FONT SIZE=3D2> protocol. Extensions to IS-IS are =
encoded as a TLV. Critically [1] </FONT>
<BR><FONT SIZE=3D2> has always defined that an IS-IS router =
SHALL flood entire LSPs that </FONT>
<BR><FONT SIZE=3D2> it receives on to other IS-IS routers =
in the network, whether or not </FONT>
<BR><FONT SIZE=3D2> it understands the TLVs that are =
included in the LSP. Also IS-IS </FONT>
<BR><FONT SIZE=3D2> LSPs are structured such that a router =
can find TLVs that it </FONT>
<BR><FONT SIZE=3D2> understands, whilst ignoring ones that =
it does not. </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> Thus information that is encoded into a =
TLV and placed into an LSP </FONT>
<BR><FONT SIZE=3D2> by a router will be propagated to every =
other router in an IS-IS </FONT>
<BR><FONT SIZE=3D2> level-1 area or level-2 subdomain. =
</FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> The basic function of an IS-IS TLV is =
identified by the first byte </FONT>
<BR><FONT SIZE=3D2> of the TLV. Thus there are only =
256 possible basic types of TLV. </FONT>
<BR><FONT SIZE=3D2> Certain types of TLV have been defined =
to include sub-TLVs so that a </FONT>
<BR><FONT SIZE=3D2> single TLV type can be used for =
multiple functions. </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> No single authority assigns TLV type =
numbers, [2] lists all known </FONT>
<BR><FONT SIZE=3D2> TLV type numbers at this time. =
Also no TLV type number was ever </FONT>
<BR><FONT SIZE=3D2> defined for private, proprietary or =
experimental use. </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> The extensible nature of IS-IS has made =
the use of TLVs in LSPs for </FONT>
<BR><FONT SIZE=3D2> proprietary purposes so useful that in =
the absence of a central </FONT>
<BR><FONT SIZE=3D2> authority for assigning TLV type =
numbers vendors have occasionally </FONT>
<BR><FONT SIZE=3D2> simply chosen a number and hoped for =
the best. The risk is that </FONT>
<BR><FONT SIZE=3D2> such a TLV type number may then be =
chosen by another organization at </FONT>
<BR><FONT SIZE=3D2> a later time for a different function, =
thus creating an </FONT>
<BR><FONT SIZE=3D2> interoperability problem. Also this =
accelerates the burning of the </FONT>
<BR><FONT SIZE=3D2> 256 possible TLV type numbers. </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> This document specifies a TLV type =
number that may be used for </FONT>
<BR><FONT SIZE=3D2> proprietary, private or experimental =
purposes, and a mechanism that </FONT>
<BR><FONT SIZE=3D2> insures that implementations from =
different sources can use the TLV </FONT>
<BR><FONT SIZE=3D2> for different purposes in the same =
network without creating </FONT>
<BR><FONT SIZE=3D2> interoperability problems. </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> By using this new TLV, companies, =
individuals or institutions may </FONT>
<BR><FONT SIZE=3D2> use extensions to IS-IS without fear of =
interoperability problems </FONT>
<BR><FONT SIZE=3D2> with other organizations in the future, =
and the available pool of </FONT>
<BR><FONT SIZE=3D2> TLV type numbers will no longer be =
diminished by proprietary use. </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2>4. TLV type number for proprietary use </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> The type field for this TLV SHALL be =
XXX. </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> TLVs that use XXX for the type field =
MUST include a valid IEEE </FONT>
<BR><FONT SIZE=3D2> assigned OUI as the first three bytes =
of the value field of the TLV. </FONT>
<BR><FONT SIZE=3D2> For more information about OUIs see =
[3]. </FONT>
<BR><FONT SIZE=3D2> </FONT>
</P>
<BR>
<P><FONT SIZE=3D2> </FONT>
<BR><FONT =
SIZE=3D2> &nb=
sp; =
TLV for Proprietary =
Use &nb=
sp; June 2002 </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> On receipt of an LSP a router MAY =
ignore TLVs of type XXX that </FONT>
<BR><FONT SIZE=3D2> include an OUI from a different =
organization, however the router </FONT>
<BR><FONT SIZE=3D2> MUST flood the LSP onwards as per [1]. =
</FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> After the first three bytes of the =
value field subsequent bytes may </FONT>
<BR><FONT SIZE=3D2> be used freely for any purpose provided =
that the resultant TLV is </FONT>
<BR><FONT SIZE=3D2> conformant with [1]. </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> Many organizations will have access to =
only one or a few OUIs. </FONT>
<BR><FONT SIZE=3D2> Implementers are free to format the =
value field after their OUI into </FONT>
<BR><FONT SIZE=3D2> sub-TLVs so that it may be used for =
multiple purposes, and would be </FONT>
<BR><FONT SIZE=3D2> well advised to do this from the =
outset. Note that if sub-TLVs are </FONT>
<BR><FONT SIZE=3D2> to be used then the very first =
implementation to exist will need to </FONT>
<BR><FONT SIZE=3D2> recognize the sub-TLV structure, and =
ignore sub-TLVs that it does </FONT>
<BR><FONT SIZE=3D2> not understand whilst searching for =
sub-TLVs that it does </FONT>
<BR><FONT SIZE=3D2> understand. </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2>5. Security Considerations </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> The proprietary TLV raises no new =
security issues for IS-IS. </FONT>
<BR><FONT SIZE=3D2> Information placed in an IS-IS TLV =
cannot be considered secure, and </FONT>
<BR><FONT SIZE=3D2> so if security is required then an =
implementation will need to </FONT>
<BR><FONT SIZE=3D2> encrypt the information using a =
suitable method. </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2>6. References </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> [1] ISO, "Intermediate system to =
Intermediate system routeing </FONT>
<BR><FONT SIZE=3D2> information exchange protocol for use =
in conjunction with the </FONT>
<BR><FONT SIZE=3D2> Protocol for providing the =
Connectionless-mode Network Service (ISO </FONT>
<BR><FONT SIZE=3D2> 8473)", ISO/IEC 10589:1992. =
</FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> [2] =
draft-ietf-isis-wg-tlv-codepoints-02.txt, Reserved TLV </FONT>
<BR><FONT SIZE=3D2> Codepoints in ISIS, Tony Przygienda, =
November 2001 </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> [3] <A =
HREF=3D"http://standards.ieee.org/regauth/oui/index.html" =
TARGET=3D"_blank">http://standards.ieee.org/regauth/oui/index.html</A> =
</FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2>7. Acknowledgments </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> The author takes no credit for this =
work as the concept was </FONT>
<BR><FONT SIZE=3D2> discussed in the IS-IS Working Group =
before the author even became </FONT>
<BR><FONT SIZE=3D2> an active participant. =
Suggestions for acknowledgement gladly </FONT>
<BR><FONT SIZE=3D2> received. </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2>8. Author's Addresses </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> Philip Christian </FONT>
<BR><FONT SIZE=3D2> Nortel Networks Harlow Laboratories =
</FONT>
<BR><FONT SIZE=3D2> London Road, Harlow, </FONT>
<BR><FONT SIZE=3D2> Essex, CM17 9NA UK </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> Email: =
christi@nortelnetworks.com</FONT>
</P>
</BODY>
</HTML>
------_=_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: <C7DF4400240AFB4095D98C7C6EC2A34A5EA4AF@bart.cwnt.com>
Alex,
once again, comments inline. I've cut out the parts that were in full agreement. Thanks for the comments.
Amir.
--
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: 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>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: <EB5FFC72F183D411B38200062957342901E5775D@r2d2.axiowave.com>
> >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>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>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>http://spider.juniper.net/mailman/listinfo/isis-wg
>> >
>>
>>
--=====================_10142854==_.ALT
Content-Type: text/html; charset="us-ascii"
<html>
<br>
IP address assignments are not permanent like OUI assignments are.<br>
I realize the chance for collision is very low, though ;-)<br>
<br>
At 10:06 AM 6/10/2002, Philip Christian wrote:<br>
<br>
<blockquote type=cite cite><font size=2>A vendor code of 4 octets could
be an IPv4 address.</font> <br>
<font size=2>Then no-one would have to assign them. The vendor just uses
a global IPv4 address that he has.</font> <br>
<br>
<font size=2>Even the smallest vendor can buy a /32 IP address for this
purpose.</font> <br>
<br>
<font size=2>That would work.</font> <br>
<br>
<font size=2>Philip</font> <br>
<br>
<font size=2>> -----Original Message-----</font> <br>
<font size=2>> From: Mike Truskowski
[<a href="mailto:truskows@cisco.com">mailto:truskows@cisco.com</a>]</font>
<br>
<font size=2>> Sent: Monday, June 10, 2002 2:42 PM</font> <br>
<font size=2>> To: mshand@cisco.com</font> <br>
<font size=2>> Cc: Christian, Philip [HAL02:GI50:EXCH];
isis-wg@spider.juniper.net</font> <br>
<font size=2>> Subject: Re: [Isis-wg] Proprietary / Private TLV
numbers?</font> <br>
<font size=2>> </font><br>
<font size=2>> </font><br>
<font size=2>> Why not just do the following?</font> <br>
<font size=2>> </font><br>
<font size=2>>
+-------------------------------------------------+</font> <br>
<font size=2>> | Type | Length
|
Value
|</font> <br>
<font size=2>>
+-------------------------------------------------+</font> <br>
<font size=2>> | TLV # | Length | vendor
code | "value" |</font> <br>
<font size=2>>
+-------------------------------------------------+</font> <br>
<font size=2>> </font><br>
<font size=2>> Where the vendor code is a fixed 3-4 octets?</font>
<br>
<font size=2>> </font><br>
<font size=2>> I guess one could do this on their own... couldn't they?</font> <br>
<font size=2>> </font><br>
<font size=2>> The major problem I see here is what Philip said he wanted to fix...</font> <br>
<font size=2>> </font><br>
<font size=2>> If vendors are doing this already and this is trying to avoid </font><br>
<font size=2>> interoperability</font> <br>
<font size=2>> problems... then it would seem reasonable that the carrier </font><br>
<font size=2>> would go back and</font> <br>
<font size=2>> install new images or force the vendor to fix the embedded </font><br>
<font size=2>> base.. but they </font><br>
<font size=2>> won't do either.. thus leaving the problem to stumble over some day...</font> <br>
<font size=2>> </font><br>
<font size=2>> Mike</font> <br>
<font size=2>> </font><br>
<font size=2>> > At 13:43 10/06/2002 +0100, Philip Christian wrote:</font> <br>
<font size=2>> > </font><br>
<font size=2>> > >I suppose that we could define different sub-TLVs, a </font><br>
<font size=2>> sub-TLV if the </font><br>
<font size=2>> > >identifier is an IPv4 address, a different sub-TLV if it </font><br>
<font size=2>> is a MAC address, etc</font> <br>
<font size=2>> > ></font> <br>
<font size=2>> > >Then folks could use whichever mechanism they prefer, as </font><br>
<font size=2>> long as it is a </font><br>
<font size=2>> > >globally unique identifier.</font> <br>
<font size=2>> > ></font> <br>
<font size=2>> > >Or is that too complex?</font> <br>
<font size=2>> > </font><br>
<font size=2>> > Yes! That's how NSAP addresses got to be so awful :-)</font> <br>
<font size=2>> > </font><br>
<font size=2>> > Mike</font> <br>
<font size=2>> > </font><br>
<font size=2>> > </font><br>
<font size=2>> > </font><br>
<font size=2>> > >Philip</font> <br>
<font size=2>> > ></font> <br>
<font size=2>> > > > -----Original Message-----</font> <br>
<font size=2>> > > > From: mike shand </font><br>
<font size=2>> [<<a href="mailto:mshand@cisco.com">mailto:mshand@cisco.com</a>><a href="mailto:mshand@cisco.com" eudora="autourl">mailto:mshand@cisco.com</a>]</font> <br>
<font size=2>> > > > Sent: Monday, June 10, 2002 12:24 PM</font> <br>
<font size=2>> > > > To: Christian, Philip [HAL02:GI50:EXCH]</font> <br>
<font size=2>> > > > Cc: isis-wg@spider.juniper.net</font> <br>
<font size=2>> > > > Subject: Re: [Isis-wg] Proprietary / Private TLV numbers?</font> <br>
<font size=2>> > > ></font> <br>
<font size=2>> > > ></font> <br>
<font size=2>> > > > At 11:29 10/06/2002 +0100, Philip Christian wrote:</font> <br>
<font size=2>> > > > >Looking at draft-ietf-isis-wg-tlv-codepoints-02.txt I notice</font> <br>
<font size=2>> > > > that there is</font> <br>
<font size=2>> > > > >not really any mechanism for private or proprietary </font><br>
<font size=2>> use of a TLV.</font> <br>
<font size=2>> > > > ></font> <br>
<font size=2>> > > > >Thus various companies (including my own) have just pcked</font> <br>
<font size=2>> > > > one and used it</font> <br>
<font size=2>> > > > >for their own purpose. Eventually this will create an</font> <br>
<font size=2>> > > > interop problem,</font> <br>
<font size=2>> > > > >but what else is a company to do?</font> <br>
<font size=2>> > > > ></font> <br>
<font size=2>> > > > >Is there a way that we could define that a certain TLV </font><br>
<font size=2>> number is for</font> <br>
<font size=2>> > > > >private / proprietary / experimental purposes?</font> <br>
<font size=2>> > > > ></font> <br>
<font size=2>> > > > >This would then stop people just picking one.</font> <br>
<font size=2>> > > > ></font> <br>
<font size=2>> > > > >I am thinking that there would have to be some sort of</font> <br>
<font size=2>> > > > entity identifier</font> <br>
<font size=2>> > > > >in there so that when you see this TLV you know whether it</font> <br>
<font size=2>> > > > is yours or not.</font> <br>
<font size=2>> > > > ></font> <br>
<font size=2>> > > > >Maybe we could define that the first four bytes are an IP</font> <br>
<font size=2>> > > > address for</font> <br>
<font size=2>> > > > >example. Any entity large enough to want to use a</font> <br>
<font size=2>> > > > proprietary TLV would</font> <br>
<font size=2>> > > > >have a public IP address to put in there, I would have</font> <br>
<font size=2>> > > > thought. After the</font> <br>
<font size=2>> > > > >first for bytes then the rest would be free.</font> <br>
<font size=2>> > > > ></font> <br>
<font size=2>> > > > >Or maybe there is a better way to identify a particular</font> <br>
<font size=2>> > > > company / entity</font> <br>
<font size=2>> > > > >(like a MAC address)? Maybe ISO 8348?</font> <br>
<font size=2>> > > > ></font> <br>
<font size=2>> > > > >What do people think?</font> <br>
<font size=2>> > > > ></font> <br>
<font size=2>> > > > >Philip</font> <br>
<font size=2>> > > > ></font> <br>
<font size=2>> > > ></font> <br>
<font size=2>> > > > This has been suggested before, but never came to anything. I</font> <br>
<font size=2>> > > > think if it</font> <br>
<font size=2>> > > > WERE to be done then using something link the MAC OUI would</font> <br>
<font size=2>> > > > probably work.</font> <br>
<font size=2>> > > > What do you mean by ISO 8348? Do you mean ISO 6523? I </font><br>
<font size=2>> hope not :-)</font> <br>
<font size=2>> > > ></font> <br>
<font size=2>> > > > Mike</font> <br>
<font size=2>> > > ></font> <br>
<font size=2>> > </font><br>
<font size=2>> > _______________________________________________</font> <br>
<font size=2>> > Isis-wg mailing list - Isis-wg@spider.juniper.net</font> <br>
<font size=2>> > <a href="http://spider.juniper.net/mailman/listinfo/isis-wg">http://spider.juniper.net/mailman/listinfo/isis-wg</a></font> <br>
<font size=2>> > </font><br>
<font size=2>> </font><br>
<font size=2>> </font></blockquote></html>
--=====================_10142854==_.ALT--
From appallar"<appallar@indiatimes.com Sun Jun 16 13:11:57 2002
From: appallar"<appallar@indiatimes.com (appallar)
Date: Sun, 16 Jun 2002 17:41:57 +0530
Subject: [Isis-wg] number of routers in an area
Message-ID: <200206161215.RAA32123@WS0005.indiatimes.com>
--=_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
<P>Hi all,</P>
<P> Are there any guidelines, about number of routers that can exist in an area in ISIS?</P>
<P>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.</P>
<P>Any Help regarding this is appretiated,</P>
<P> </P>
<P>Thanks in Advance,</P>
<P>Suryanarayana</P>
<P> </P>
<hr><font face="Arial" size="2"><b>Get Your Private, Free E-mail from Indiatimes at </font><a href="http://email.indiatimes.com"><font face="Arial" size="2">http://email.indiatimes.com</font></a></b><br>Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from <A href="http://www.planetm.co.in">http://www.planetm.co.in</A>
--=_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>http://email.indiatimes.com
>Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from <http://www.planetm.co.in>http://www.planetm.co.in
--=====================_56413508==_.ALT
Content-Type: text/html; charset="us-ascii"
<html>
<br>
The protocol does not impose any standards. This is a
weakest-link<br>
situation; the router with the least memory or insufficient CPU<br>
power will dictate the limitation for that area or level 2
subdomain.<br>
<br>
Regards,<br>
Jeff<br>
<br>
At 08:11 AM 6/16/2002, appallar wrote:<br>
<br>
<blockquote type=cite cite>Hi all,<br>
<br>
Are there any guidelines, about number of routers that can exist in
an area in ISIS?<br>
<br>
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.<br>
<br>
Any Help regarding this is appretiated,<br>
<br>
<br>
<br>
Thanks in Advance,<br>
<br>
Suryanarayana<br>
<br>
<br>
<hr>
<font face="Arial, Helvetica" size=2><b>Get Your Private, Free E-mail
from Indiatimes at
<a href="http://email.indiatimes.com">http://email.indiatimes.com</a></b></font><br>
Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from
<a href="http://www.planetm.co.in">http://www.planetm.co.in</a>
</blockquote></html>
--=====================_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: <F100gSIQ4wjFKxdA7vz0001f726@hotmail.com>
_________________________________________________________________
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 <zinin@psg.com> Mon Jun 17 21:44:04 2002
From: Alex Zinin <zinin@psg.com> (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: <F239hvqgStMVhEUsebm00003040@hotmail.com>
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: <EB5FFC72F183D411B38200062957342901E57881@r2d2.axiowave.com>
> 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: <F128uKQjNAzMVnaV9eu000021b5@hotmail.com>
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: <D2EC481073504E498A8DB9C0687E8CAF029CE0D6@EXCHANGE0-0.na.procket.com> 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: <D2EC481073504E498A8DB9C0687E8CAF029CE0D6@EXCHANGE0-0.na.procket.com>
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: <F247mBySsxVY60mJWEs0000022f@hotmail.com>
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: <F128uKQjNAzMVnaV9eu000021b5@hotmail.com>
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: <F627dZibOd1HzRQd5iT0001f864@hotmail.com>
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 >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 >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"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2655.35">
<TITLE>RE: [Isis-wg] Proprietary / Private TLV numbers?</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=2>I am guessing that OUI means an IEEE assigned MAC address?</FONT>
</P>
<P><FONT SIZE=2>If so then it sounds okay to me.</FONT>
</P>
<P><FONT SIZE=2>I'll write it if you like.</FONT>
</P>
<P><FONT SIZE=2>Philip</FONT>
</P>
<P><FONT SIZE=2>> -----Original Message-----</FONT>
<BR><FONT SIZE=2>> From: Tony Przygienda [<A HREF="mailto:prz@net4u.ch">mailto:prz@net4u.ch</A>]</FONT>
<BR><FONT SIZE=2>> Sent: Monday, June 10, 2002 5:44 PM</FONT>
<BR><FONT SIZE=2>> To: Christian, Philip [HAL02:GI50:EXCH]</FONT>
<BR><FONT SIZE=2>> Cc: 'Mike Truskowski'; mshand@cisco.com; isis-wg@spider.juniper.net</FONT>
<BR><FONT SIZE=2>> Subject: Re: [Isis-wg] Proprietary / Private TLV numbers?</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Yes, the proposals have been made before and nohting has been written </FONT>
<BR><FONT SIZE=2>> down. I am</FONT>
<BR><FONT SIZE=2>> for using the official OUI, this would be aligned with Frame </FONT>
<BR><FONT SIZE=2>> Relay, ATM </FONT>
<BR><FONT SIZE=2>> and so on.</FONT>
<BR><FONT SIZE=2>> The /32 may fly but unfortunately IP address space is a </FONT>
<BR><FONT SIZE=2>> volatile thing </FONT>
<BR><FONT SIZE=2>> compared to</FONT>
<BR><FONT SIZE=2>> OUIs. I assume any vendor building sophisticated networking gear with </FONT>
<BR><FONT SIZE=2>> ISIS on it</FONT>
<BR><FONT SIZE=2>> will at a certain point have an OUI, I see little value in having a</FONT>
<BR><FONT SIZE=2>> /32-address-based-cottage-industry-of-ISIS-extensions ...</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> So, this time any takers to write it down ?</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> thanks</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> -- tony</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Philip Christian wrote:</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> > A vendor code of 4 octets could be an IPv4 address.</FONT>
<BR><FONT SIZE=2>> > Then no-one would have to assign them. The vendor just uses </FONT>
<BR><FONT SIZE=2>> a global </FONT>
<BR><FONT SIZE=2>> > IPv4 address that he has.</FONT>
<BR><FONT SIZE=2>> ></FONT>
<BR><FONT SIZE=2>> > Even the smallest vendor can buy a /32 IP address for this purpose.</FONT>
<BR><FONT SIZE=2>> ></FONT>
<BR><FONT SIZE=2>> > That would work.</FONT>
<BR><FONT SIZE=2>> ></FONT>
<BR><FONT SIZE=2>> > Philip</FONT>
<BR><FONT SIZE=2>> ></FONT>
<BR><FONT SIZE=2>> > > -----Original Message-----</FONT>
<BR><FONT SIZE=2>> > > From: Mike Truskowski [ <A HREF="mailto:truskows@cisco.com">mailto:truskows@cisco.com</A> ]</FONT>
<BR><FONT SIZE=2>> > > Sent: Monday, June 10, 2002 2:42 PM</FONT>
<BR><FONT SIZE=2>> > > To: mshand@cisco.com</FONT>
<BR><FONT SIZE=2>> > > Cc: Christian, Philip [HAL02:GI50:EXCH]; </FONT>
<BR><FONT SIZE=2>> isis-wg@spider.juniper.net</FONT>
<BR><FONT SIZE=2>> > > Subject: Re: [Isis-wg] Proprietary / Private TLV numbers?</FONT>
<BR><FONT SIZE=2>> > ></FONT>
<BR><FONT SIZE=2>> > ></FONT>
<BR><FONT SIZE=2>> > > Why not just do the following?</FONT>
<BR><FONT SIZE=2>> > ></FONT>
<BR><FONT SIZE=2>> > > +-------------------------------------------------+</FONT>
<BR><FONT SIZE=2>> > > | Type | Length | Value |</FONT>
<BR><FONT SIZE=2>> > > +-------------------------------------------------+</FONT>
<BR><FONT SIZE=2>> > > | TLV # | Length | vendor code | "value" |</FONT>
<BR><FONT SIZE=2>> > > +-------------------------------------------------+</FONT>
<BR><FONT SIZE=2>> > ></FONT>
<BR><FONT SIZE=2>> > > Where the vendor code is a fixed 3-4 octets?</FONT>
<BR><FONT SIZE=2>> > ></FONT>
<BR><FONT SIZE=2>> > > I guess one could do this on their own... couldn't they?</FONT>
<BR><FONT SIZE=2>> > ></FONT>
<BR><FONT SIZE=2>> > > The major problem I see here is what Philip said he </FONT>
<BR><FONT SIZE=2>> wanted to fix...</FONT>
<BR><FONT SIZE=2>> > ></FONT>
<BR><FONT SIZE=2>> > > If vendors are doing this already and this is trying to avoid</FONT>
<BR><FONT SIZE=2>> > > interoperability</FONT>
<BR><FONT SIZE=2>> > > problems... then it would seem reasonable that the carrier</FONT>
<BR><FONT SIZE=2>> > > would go back and</FONT>
<BR><FONT SIZE=2>> > > install new images or force the vendor to fix the embedded</FONT>
<BR><FONT SIZE=2>> > > base.. but they</FONT>
<BR><FONT SIZE=2>> > > won't do either.. thus leaving the problem to stumble </FONT>
<BR><FONT SIZE=2>> over some day...</FONT>
<BR><FONT SIZE=2>> > ></FONT>
<BR><FONT SIZE=2>> > > Mike</FONT>
<BR><FONT SIZE=2>> > ></FONT>
<BR><FONT SIZE=2>> > > > At 13:43 10/06/2002 +0100, Philip Christian wrote:</FONT>
<BR><FONT SIZE=2>> > > ></FONT>
<BR><FONT SIZE=2>> > > > >I suppose that we could define different sub-TLVs, a</FONT>
<BR><FONT SIZE=2>> > > sub-TLV if the</FONT>
<BR><FONT SIZE=2>> > > > >identifier is an IPv4 address, a different sub-TLV if it</FONT>
<BR><FONT SIZE=2>> > > is a MAC address, etc</FONT>
<BR><FONT SIZE=2>> > > > ></FONT>
<BR><FONT SIZE=2>> > > > >Then folks could use whichever mechanism they prefer, as</FONT>
<BR><FONT SIZE=2>> > > long as it is a</FONT>
<BR><FONT SIZE=2>> > > > >globally unique identifier.</FONT>
<BR><FONT SIZE=2>> > > > ></FONT>
<BR><FONT SIZE=2>> > > > >Or is that too complex?</FONT>
<BR><FONT SIZE=2>> > > ></FONT>
<BR><FONT SIZE=2>> > > > Yes! That's how NSAP addresses got to be so awful :-)</FONT>
<BR><FONT SIZE=2>> > > ></FONT>
<BR><FONT SIZE=2>> > > > Mike</FONT>
<BR><FONT SIZE=2>> > > ></FONT>
<BR><FONT SIZE=2>> > > ></FONT>
<BR><FONT SIZE=2>> > > ></FONT>
<BR><FONT SIZE=2>> > > > >Philip</FONT>
<BR><FONT SIZE=2>> > > > ></FONT>
<BR><FONT SIZE=2>> > > > > > -----Original Message-----</FONT>
<BR><FONT SIZE=2>> > > > > > From: mike shand</FONT>
<BR><FONT SIZE=2>> > > [<<A HREF="mailto:mshand@cisco.com">mailto:mshand@cisco.com</A> ><A HREF="mailto:mshand@cisco.com">mailto:mshand@cisco.com</A> ]</FONT>
<BR><FONT SIZE=2>> > > > > > Sent: Monday, June 10, 2002 12:24 PM</FONT>
<BR><FONT SIZE=2>> > > > > > To: Christian, Philip [HAL02:GI50:EXCH]</FONT>
<BR><FONT SIZE=2>> > > > > > Cc: isis-wg@spider.juniper.net</FONT>
<BR><FONT SIZE=2>> > > > > > Subject: Re: [Isis-wg] Proprietary / Private TLV numbers?</FONT>
<BR><FONT SIZE=2>> > > > > ></FONT>
<BR><FONT SIZE=2>> > > > > ></FONT>
<BR><FONT SIZE=2>> > > > > > At 11:29 10/06/2002 +0100, Philip Christian wrote:</FONT>
<BR><FONT SIZE=2>> > > > > > >Looking at </FONT>
<BR><FONT SIZE=2>> draft-ietf-isis-wg-tlv-codepoints-02.txt I notice</FONT>
<BR><FONT SIZE=2>> > > > > > that there is</FONT>
<BR><FONT SIZE=2>> > > > > > >not really any mechanism for private or proprietary</FONT>
<BR><FONT SIZE=2>> > > use of a TLV.</FONT>
<BR><FONT SIZE=2>> > > > > > ></FONT>
<BR><FONT SIZE=2>> > > > > > >Thus various companies (including my own) have just pcked</FONT>
<BR><FONT SIZE=2>> > > > > > one and used it</FONT>
<BR><FONT SIZE=2>> > > > > > >for their own purpose. Eventually this will create an</FONT>
<BR><FONT SIZE=2>> > > > > > interop problem,</FONT>
<BR><FONT SIZE=2>> > > > > > >but what else is a company to do?</FONT>
<BR><FONT SIZE=2>> > > > > > ></FONT>
<BR><FONT SIZE=2>> > > > > > >Is there a way that we could define that a certain TLV</FONT>
<BR><FONT SIZE=2>> > > number is for</FONT>
<BR><FONT SIZE=2>> > > > > > >private / proprietary / experimental purposes?</FONT>
<BR><FONT SIZE=2>> > > > > > ></FONT>
<BR><FONT SIZE=2>> > > > > > >This would then stop people just picking one.</FONT>
<BR><FONT SIZE=2>> > > > > > ></FONT>
<BR><FONT SIZE=2>> > > > > > >I am thinking that there would have to be some sort of</FONT>
<BR><FONT SIZE=2>> > > > > > entity identifier</FONT>
<BR><FONT SIZE=2>> > > > > > >in there so that when you see this TLV you know whether it</FONT>
<BR><FONT SIZE=2>> > > > > > is yours or not.</FONT>
<BR><FONT SIZE=2>> > > > > > ></FONT>
<BR><FONT SIZE=2>> > > > > > >Maybe we could define that the first four bytes are an IP</FONT>
<BR><FONT SIZE=2>> > > > > > address for</FONT>
<BR><FONT SIZE=2>> > > > > > >example. Any entity large enough to want to use a</FONT>
<BR><FONT SIZE=2>> > > > > > proprietary TLV would</FONT>
<BR><FONT SIZE=2>> > > > > > >have a public IP address to put in there, I would have</FONT>
<BR><FONT SIZE=2>> > > > > > thought. After the</FONT>
<BR><FONT SIZE=2>> > > > > > >first for bytes then the rest would be free.</FONT>
<BR><FONT SIZE=2>> > > > > > ></FONT>
<BR><FONT SIZE=2>> > > > > > >Or maybe there is a better way to identify a particular</FONT>
<BR><FONT SIZE=2>> > > > > > company / entity</FONT>
<BR><FONT SIZE=2>> > > > > > >(like a MAC address)? Maybe ISO 8348?</FONT>
<BR><FONT SIZE=2>> > > > > > ></FONT>
<BR><FONT SIZE=2>> > > > > > >What do people think?</FONT>
<BR><FONT SIZE=2>> > > > > > ></FONT>
<BR><FONT SIZE=2>> > > > > > >Philip</FONT>
<BR><FONT SIZE=2>> > > > > > ></FONT>
<BR><FONT SIZE=2>> > > > > ></FONT>
<BR><FONT SIZE=2>> > > > > > This has been suggested before, but never came to </FONT>
<BR><FONT SIZE=2>> anything. I</FONT>
<BR><FONT SIZE=2>> > > > > > think if it</FONT>
<BR><FONT SIZE=2>> > > > > > WERE to be done then using something link the MAC OUI would</FONT>
<BR><FONT SIZE=2>> > > > > > probably work.</FONT>
<BR><FONT SIZE=2>> > > > > > What do you mean by ISO 8348? Do you mean ISO 6523? I</FONT>
<BR><FONT SIZE=2>> > > hope not :-)</FONT>
<BR><FONT SIZE=2>> > > > > ></FONT>
<BR><FONT SIZE=2>> > > > > > Mike</FONT>
<BR><FONT SIZE=2>> > > > > ></FONT>
<BR><FONT SIZE=2>> > > ></FONT>
<BR><FONT SIZE=2>> > > > _______________________________________________</FONT>
<BR><FONT SIZE=2>> > > > Isis-wg mailing list - Isis-wg@spider.juniper.net</FONT>
<BR><FONT SIZE=2>> > > > <A HREF="http://spider.juniper.net/mailman/listinfo/isis-wg" TARGET="_blank">http://spider.juniper.net/mailman/listinfo/isis-wg</A></FONT>
<BR><FONT SIZE=2>> > > ></FONT>
<BR><FONT SIZE=2>> > ></FONT>
<BR><FONT SIZE=2>> > ></FONT>
<BR><FONT SIZE=2>> ></FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> </FONT>
</P>
</BODY>
</HTML>
------_=_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 >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
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>RE: [Isis-wg] Proprietary / Private TLV numbers?</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>And to answer my own question...</FONT>
</P>
<P><FONT SIZE=3D2>One can read what OUIs are from</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://standards.ieee.org/regauth/oui/index.shtml" =
TARGET=3D"_blank">http://standards.ieee.org/regauth/oui/index.shtml</A><=
/FONT>
</P>
<P><FONT SIZE=3D2>still sounds okay to me</FONT>
</P>
<P><FONT SIZE=3D2>Philip</FONT>
</P>
<P><FONT SIZE=3D2>> -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>> From: Christian, Philip [HAL02:GI50:EXCH] =
</FONT>
<BR><FONT SIZE=3D2>> Sent: Monday, June 10, 2002 6:00 PM</FONT>
<BR><FONT SIZE=3D2>> To: 'Tony Przygienda'</FONT>
<BR><FONT SIZE=3D2>> Cc: 'Mike Truskowski'; mshand@cisco.com; =
isis-wg@spider.juniper.net</FONT>
<BR><FONT SIZE=3D2>> Subject: RE: [Isis-wg] Proprietary / Private =
TLV numbers?</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> I am guessing that OUI means an IEEE assigned =
MAC address?</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> If so then it sounds okay to me.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> I'll write it if you like.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Philip</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> > -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>> > From: Tony Przygienda [<A =
HREF=3D"mailto:prz@net4u.ch">mailto:prz@net4u.ch</A>]</FONT>
<BR><FONT SIZE=3D2>> > Sent: Monday, June 10, 2002 5:44 PM</FONT>
<BR><FONT SIZE=3D2>> > To: Christian, Philip =
[HAL02:GI50:EXCH]</FONT>
<BR><FONT SIZE=3D2>> > Cc: 'Mike Truskowski'; mshand@cisco.com; =
isis-wg@spider.juniper.net</FONT>
<BR><FONT SIZE=3D2>> > Subject: Re: [Isis-wg] Proprietary / =
Private TLV numbers?</FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > Yes, the proposals have been made before =
and nohting has </FONT>
<BR><FONT SIZE=3D2>> been written </FONT>
<BR><FONT SIZE=3D2>> > down. I am</FONT>
<BR><FONT SIZE=3D2>> > for using the official OUI, this would be =
aligned with Frame </FONT>
<BR><FONT SIZE=3D2>> > Relay, ATM </FONT>
<BR><FONT SIZE=3D2>> > and so on.</FONT>
<BR><FONT SIZE=3D2>> > The /32 may fly but unfortunately IP =
address space is a </FONT>
<BR><FONT SIZE=3D2>> > volatile thing </FONT>
<BR><FONT SIZE=3D2>> > compared to</FONT>
<BR><FONT SIZE=3D2>> > OUIs. I assume any vendor building =
sophisticated networking </FONT>
<BR><FONT SIZE=3D2>> gear with </FONT>
<BR><FONT SIZE=3D2>> > ISIS on it</FONT>
<BR><FONT SIZE=3D2>> > will at a certain point have an OUI, I see =
little value in having a</FONT>
<BR><FONT SIZE=3D2>> > =
/32-address-based-cottage-industry-of-ISIS-extensions ...</FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > So, this time any takers to write it down =
?</FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > thanks</FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > -- tony</FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > Philip Christian wrote:</FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > > A vendor code of 4 octets could be an =
IPv4 address.</FONT>
<BR><FONT SIZE=3D2>> > > Then no-one would have to assign =
them. The vendor just uses </FONT>
<BR><FONT SIZE=3D2>> > a global </FONT>
<BR><FONT SIZE=3D2>> > > IPv4 address that he has.</FONT>
<BR><FONT SIZE=3D2>> > ></FONT>
<BR><FONT SIZE=3D2>> > > Even the smallest vendor can buy a =
/32 IP address for </FONT>
<BR><FONT SIZE=3D2>> this purpose.</FONT>
<BR><FONT SIZE=3D2>> > ></FONT>
<BR><FONT SIZE=3D2>> > > That would work.</FONT>
<BR><FONT SIZE=3D2>> > ></FONT>
<BR><FONT SIZE=3D2>> > > Philip</FONT>
<BR><FONT SIZE=3D2>> > ></FONT>
<BR><FONT SIZE=3D2>> > > > -----Original =
Message-----</FONT>
<BR><FONT SIZE=3D2>> > > > From: Mike Truskowski [ <A =
HREF=3D"mailto:truskows@cisco.com">mailto:truskows@cisco.com</A> =
]</FONT>
<BR><FONT SIZE=3D2>> > > > Sent: Monday, June 10, 2002 2:42 =
PM</FONT>
<BR><FONT SIZE=3D2>> > > > To: mshand@cisco.com</FONT>
<BR><FONT SIZE=3D2>> > > > Cc: Christian, Philip =
[HAL02:GI50:EXCH]; </FONT>
<BR><FONT SIZE=3D2>> > isis-wg@spider.juniper.net</FONT>
<BR><FONT SIZE=3D2>> > > > Subject: Re: [Isis-wg] =
Proprietary / Private TLV numbers?</FONT>
<BR><FONT SIZE=3D2>> > > ></FONT>
<BR><FONT SIZE=3D2>> > > ></FONT>
<BR><FONT SIZE=3D2>> > > > Why not just do the =
following?</FONT>
<BR><FONT SIZE=3D2>> > > ></FONT>
<BR><FONT SIZE=3D2>> > > > =
+-------------------------------------------------+</FONT>
<BR><FONT SIZE=3D2>> > > > | Type | =
Length | =
Value &=
nbsp; |</FONT>
<BR><FONT SIZE=3D2>> > > > =
+-------------------------------------------------+</FONT>
<BR><FONT SIZE=3D2>> > > > | TLV # | =
Length | vendor code | =
"value" |</FONT>
<BR><FONT SIZE=3D2>> > > > =
+-------------------------------------------------+</FONT>
<BR><FONT SIZE=3D2>> > > ></FONT>
<BR><FONT SIZE=3D2>> > > > Where the vendor code is a fixed =
3-4 octets?</FONT>
<BR><FONT SIZE=3D2>> > > ></FONT>
<BR><FONT SIZE=3D2>> > > > I guess one could do this on =
their own... couldn't they?</FONT>
<BR><FONT SIZE=3D2>> > > ></FONT>
<BR><FONT SIZE=3D2>> > > > The major problem I see here is =
what Philip said he </FONT>
<BR><FONT SIZE=3D2>> > wanted to fix...</FONT>
<BR><FONT SIZE=3D2>> > > ></FONT>
<BR><FONT SIZE=3D2>> > > > If vendors are doing this =
already and this is trying to avoid</FONT>
<BR><FONT SIZE=3D2>> > > > interoperability</FONT>
<BR><FONT SIZE=3D2>> > > > problems... then it would seem =
reasonable that the carrier</FONT>
<BR><FONT SIZE=3D2>> > > > would go back and</FONT>
<BR><FONT SIZE=3D2>> > > > install new images or force the =
vendor to fix the embedded</FONT>
<BR><FONT SIZE=3D2>> > > > base.. but they</FONT>
<BR><FONT SIZE=3D2>> > > > won't do either.. thus leaving =
the problem to stumble </FONT>
<BR><FONT SIZE=3D2>> > over some day...</FONT>
<BR><FONT SIZE=3D2>> > > ></FONT>
<BR><FONT SIZE=3D2>> > > > Mike</FONT>
<BR><FONT SIZE=3D2>> > > ></FONT>
<BR><FONT SIZE=3D2>> > > > > At 13:43 10/06/2002 +0100, =
Philip Christian wrote:</FONT>
<BR><FONT SIZE=3D2>> > > > ></FONT>
<BR><FONT SIZE=3D2>> > > > > >I suppose that we could =
define different sub-TLVs, a</FONT>
<BR><FONT SIZE=3D2>> > > > sub-TLV if the</FONT>
<BR><FONT SIZE=3D2>> > > > > >identifier is an IPv4 =
address, a different sub-TLV if it</FONT>
<BR><FONT SIZE=3D2>> > > > is a MAC address, etc</FONT>
<BR><FONT SIZE=3D2>> > > > > ></FONT>
<BR><FONT SIZE=3D2>> > > > > >Then folks could use =
whichever mechanism they prefer, as</FONT>
<BR><FONT SIZE=3D2>> > > > long as it is a</FONT>
<BR><FONT SIZE=3D2>> > > > > >globally unique =
identifier.</FONT>
<BR><FONT SIZE=3D2>> > > > > ></FONT>
<BR><FONT SIZE=3D2>> > > > > >Or is that too =
complex?</FONT>
<BR><FONT SIZE=3D2>> > > > ></FONT>
<BR><FONT SIZE=3D2>> > > > > Yes! That's how NSAP =
addresses got to be so awful :-)</FONT>
<BR><FONT SIZE=3D2>> > > > ></FONT>
<BR><FONT SIZE=3D2>> > > > =
> Mike</FONT>
<BR><FONT SIZE=3D2>> > > > ></FONT>
<BR><FONT SIZE=3D2>> > > > ></FONT>
<BR><FONT SIZE=3D2>> > > > ></FONT>
<BR><FONT SIZE=3D2>> > > > > >Philip</FONT>
<BR><FONT SIZE=3D2>> > > > > ></FONT>
<BR><FONT SIZE=3D2>> > > > > > > -----Original =
Message-----</FONT>
<BR><FONT SIZE=3D2>> > > > > > > From: mike =
shand</FONT>
<BR><FONT SIZE=3D2>> > > > [<<A =
HREF=3D"mailto:mshand@cisco.com">mailto:mshand@cisco.com</A> ><A =
HREF=3D"mailto:mshand@cisco.com">mailto:mshand@cisco.com</A> ]</FONT>
<BR><FONT SIZE=3D2>> > > > > > > Sent: Monday, =
June 10, 2002 12:24 PM</FONT>
<BR><FONT SIZE=3D2>> > > > > > > To: Christian, =
Philip [HAL02:GI50:EXCH]</FONT>
<BR><FONT SIZE=3D2>> > > > > > > Cc: =
isis-wg@spider.juniper.net</FONT>
<BR><FONT SIZE=3D2>> > > > > > > Subject: Re: =
[Isis-wg] Proprietary / Private TLV numbers?</FONT>
<BR><FONT SIZE=3D2>> > > > > > ></FONT>
<BR><FONT SIZE=3D2>> > > > > > ></FONT>
<BR><FONT SIZE=3D2>> > > > > > > At 11:29 =
10/06/2002 +0100, Philip Christian wrote:</FONT>
<BR><FONT SIZE=3D2>> > > > > > > >Looking at =
</FONT>
<BR><FONT SIZE=3D2>> > draft-ietf-isis-wg-tlv-codepoints-02.txt I =
notice</FONT>
<BR><FONT SIZE=3D2>> > > > > > > that there =
is</FONT>
<BR><FONT SIZE=3D2>> > > > > > > >not really =
any mechanism for private or proprietary</FONT>
<BR><FONT SIZE=3D2>> > > > use of a TLV.</FONT>
<BR><FONT SIZE=3D2>> > > > > > > ></FONT>
<BR><FONT SIZE=3D2>> > > > > > > >Thus various =
companies (including my own) have just pcked</FONT>
<BR><FONT SIZE=3D2>> > > > > > > one and used =
it</FONT>
<BR><FONT SIZE=3D2>> > > > > > > >for their own =
purpose. Eventually this will create an</FONT>
<BR><FONT SIZE=3D2>> > > > > > > interop =
problem,</FONT>
<BR><FONT SIZE=3D2>> > > > > > > >but what else =
is a company to do?</FONT>
<BR><FONT SIZE=3D2>> > > > > > > ></FONT>
<BR><FONT SIZE=3D2>> > > > > > > >Is there a =
way that we could define that a certain TLV</FONT>
<BR><FONT SIZE=3D2>> > > > number is for</FONT>
<BR><FONT SIZE=3D2>> > > > > > > >private / =
proprietary / experimental purposes?</FONT>
<BR><FONT SIZE=3D2>> > > > > > > ></FONT>
<BR><FONT SIZE=3D2>> > > > > > > >This would =
then stop people just picking one.</FONT>
<BR><FONT SIZE=3D2>> > > > > > > ></FONT>
<BR><FONT SIZE=3D2>> > > > > > > >I am thinking =
that there would have to be some sort of</FONT>
<BR><FONT SIZE=3D2>> > > > > > > entity =
identifier</FONT>
<BR><FONT SIZE=3D2>> > > > > > > >in there so =
that when you see this TLV you know </FONT>
<BR><FONT SIZE=3D2>> whether it</FONT>
<BR><FONT SIZE=3D2>> > > > > > > is yours or =
not.</FONT>
<BR><FONT SIZE=3D2>> > > > > > > ></FONT>
<BR><FONT SIZE=3D2>> > > > > > > >Maybe we =
could define that the first four bytes are an IP</FONT>
<BR><FONT SIZE=3D2>> > > > > > > address =
for</FONT>
<BR><FONT SIZE=3D2>> > > > > > > =
>example. Any entity large enough to want to use a</FONT>
<BR><FONT SIZE=3D2>> > > > > > > proprietary TLV =
would</FONT>
<BR><FONT SIZE=3D2>> > > > > > > >have a public =
IP address to put in there, I would have</FONT>
<BR><FONT SIZE=3D2>> > > > > > > thought. After =
the</FONT>
<BR><FONT SIZE=3D2>> > > > > > > >first for =
bytes then the rest would be free.</FONT>
<BR><FONT SIZE=3D2>> > > > > > > ></FONT>
<BR><FONT SIZE=3D2>> > > > > > > >Or maybe =
there is a better way to identify a particular</FONT>
<BR><FONT SIZE=3D2>> > > > > > > company / =
entity</FONT>
<BR><FONT SIZE=3D2>> > > > > > > >(like a MAC =
address)? Maybe ISO 8348?</FONT>
<BR><FONT SIZE=3D2>> > > > > > > ></FONT>
<BR><FONT SIZE=3D2>> > > > > > > >What do =
people think?</FONT>
<BR><FONT SIZE=3D2>> > > > > > > ></FONT>
<BR><FONT SIZE=3D2>> > > > > > > >Philip</FONT>
<BR><FONT SIZE=3D2>> > > > > > > ></FONT>
<BR><FONT SIZE=3D2>> > > > > > ></FONT>
<BR><FONT SIZE=3D2>> > > > > > > This has been =
suggested before, but never came to </FONT>
<BR><FONT SIZE=3D2>> > anything. I</FONT>
<BR><FONT SIZE=3D2>> > > > > > > think if =
it</FONT>
<BR><FONT SIZE=3D2>> > > > > > > WERE to be done =
then using something link the MAC </FONT>
<BR><FONT SIZE=3D2>> OUI would</FONT>
<BR><FONT SIZE=3D2>> > > > > > > probably =
work.</FONT>
<BR><FONT SIZE=3D2>> > > > > > > What do you mean =
by ISO 8348? Do you mean ISO 6523? I</FONT>
<BR><FONT SIZE=3D2>> > > > hope not :-)</FONT>
<BR><FONT SIZE=3D2>> > > > > > ></FONT>
<BR><FONT SIZE=3D2>> > > > > > =
> Mike</FONT>
<BR><FONT SIZE=3D2>> > > > > > ></FONT>
<BR><FONT SIZE=3D2>> > > > ></FONT>
<BR><FONT SIZE=3D2>> > > > > =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>> > > > > Isis-wg mailing list =
- Isis-wg@spider.juniper.net</FONT>
<BR><FONT SIZE=3D2>> > > > > <A =
HREF=3D"http://spider.juniper.net/mailman/listinfo/isis-wg" =
TARGET=3D"_blank">http://spider.juniper.net/mailman/listinfo/isis-wg</A>=
</FONT>
<BR><FONT SIZE=3D2>> > > > ></FONT>
<BR><FONT SIZE=3D2>> > > ></FONT>
<BR><FONT SIZE=3D2>> > > ></FONT>
<BR><FONT SIZE=3D2>> > ></FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> </FONT>
</P>
</BODY>
</HTML>
------_=_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 >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
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>RE: [Isis-wg] Proprietary / Private TLV numbers?</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>So I am just writing something at the moment based on =
OUIs.</FONT>
</P>
<P><FONT SIZE=3D2>Two questions.</FONT>
</P>
<P><FONT SIZE=3D2>1. What TLV number shall be assigned as the =
proprietary TLV?</FONT>
</P>
<P><FONT SIZE=3D2>2. Does the "locally assigned" bit have any =
significance in an OUI as it does in a MAC address?</FONT>
</P>
<P><FONT SIZE=3D2>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.</FONT></P>
<P><FONT SIZE=3D2>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.</FONT></P>
<P><FONT SIZE=3D2>The draft could clearly state that this SHOULD NOT be =
used for commercial products intended for deployment in the Internet, =
if that helps.</FONT></P>
<P><FONT SIZE=3D2>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...</FONT></P>
<P><FONT SIZE=3D2>Thoughts?</FONT>
</P>
<P><FONT SIZE=3D2>Philip</FONT>
</P>
<P><FONT SIZE=3D2>> -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>> From: Tony Przygienda [<A =
HREF=3D"mailto:prz@net4u.ch">mailto:prz@net4u.ch</A>]</FONT>
<BR><FONT SIZE=3D2>> Sent: Monday, June 10, 2002 5:44 PM</FONT>
<BR><FONT SIZE=3D2>> To: Christian, Philip [HAL02:GI50:EXCH]</FONT>
<BR><FONT SIZE=3D2>> Cc: 'Mike Truskowski'; mshand@cisco.com; =
isis-wg@spider.juniper.net</FONT>
<BR><FONT SIZE=3D2>> Subject: Re: [Isis-wg] Proprietary / Private =
TLV numbers?</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Yes, the proposals have been made before and =
nohting has been written </FONT>
<BR><FONT SIZE=3D2>> down. I am</FONT>
<BR><FONT SIZE=3D2>> for using the official OUI, this would be =
aligned with Frame </FONT>
<BR><FONT SIZE=3D2>> Relay, ATM </FONT>
<BR><FONT SIZE=3D2>> and so on.</FONT>
<BR><FONT SIZE=3D2>> The /32 may fly but unfortunately IP address =
space is a </FONT>
<BR><FONT SIZE=3D2>> volatile thing </FONT>
<BR><FONT SIZE=3D2>> compared to</FONT>
<BR><FONT SIZE=3D2>> OUIs. I assume any vendor building =
sophisticated networking gear with </FONT>
<BR><FONT SIZE=3D2>> ISIS on it</FONT>
<BR><FONT SIZE=3D2>> will at a certain point have an OUI, I see =
little value in having a</FONT>
<BR><FONT SIZE=3D2>> =
/32-address-based-cottage-industry-of-ISIS-extensions ...</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> So, this time any takers to write it down =
?</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> thanks</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> -- tony</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Philip Christian wrote:</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> > A vendor code of 4 octets could be an IPv4 =
address.</FONT>
<BR><FONT SIZE=3D2>> > Then no-one would have to assign them. The =
vendor just uses </FONT>
<BR><FONT SIZE=3D2>> a global </FONT>
<BR><FONT SIZE=3D2>> > IPv4 address that he has.</FONT>
<BR><FONT SIZE=3D2>> ></FONT>
<BR><FONT SIZE=3D2>> > Even the smallest vendor can buy a /32 IP =
address for this purpose.</FONT>
<BR><FONT SIZE=3D2>> ></FONT>
<BR><FONT SIZE=3D2>> > That would work.</FONT>
<BR><FONT SIZE=3D2>> ></FONT>
<BR><FONT SIZE=3D2>> > Philip</FONT>
<BR><FONT SIZE=3D2>> ></FONT>
<BR><FONT SIZE=3D2>> > > -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>> > > From: Mike Truskowski [ <A =
HREF=3D"mailto:truskows@cisco.com">mailto:truskows@cisco.com</A> =
]</FONT>
<BR><FONT SIZE=3D2>> > > Sent: Monday, June 10, 2002 2:42 =
PM</FONT>
<BR><FONT SIZE=3D2>> > > To: mshand@cisco.com</FONT>
<BR><FONT SIZE=3D2>> > > Cc: Christian, Philip =
[HAL02:GI50:EXCH]; </FONT>
<BR><FONT SIZE=3D2>> isis-wg@spider.juniper.net</FONT>
<BR><FONT SIZE=3D2>> > > Subject: Re: [Isis-wg] Proprietary / =
Private TLV numbers?</FONT>
<BR><FONT SIZE=3D2>> > ></FONT>
<BR><FONT SIZE=3D2>> > ></FONT>
<BR><FONT SIZE=3D2>> > > Why not just do the following?</FONT>
<BR><FONT SIZE=3D2>> > ></FONT>
<BR><FONT SIZE=3D2>> > > =
+-------------------------------------------------+</FONT>
<BR><FONT SIZE=3D2>> > > | Type | =
Length | =
Value &=
nbsp; |</FONT>
<BR><FONT SIZE=3D2>> > > =
+-------------------------------------------------+</FONT>
<BR><FONT SIZE=3D2>> > > | TLV # | Length =
| vendor code | "value" =
|</FONT>
<BR><FONT SIZE=3D2>> > > =
+-------------------------------------------------+</FONT>
<BR><FONT SIZE=3D2>> > ></FONT>
<BR><FONT SIZE=3D2>> > > Where the vendor code is a fixed 3-4 =
octets?</FONT>
<BR><FONT SIZE=3D2>> > ></FONT>
<BR><FONT SIZE=3D2>> > > I guess one could do this on their =
own... couldn't they?</FONT>
<BR><FONT SIZE=3D2>> > ></FONT>
<BR><FONT SIZE=3D2>> > > The major problem I see here is what =
Philip said he </FONT>
<BR><FONT SIZE=3D2>> wanted to fix...</FONT>
<BR><FONT SIZE=3D2>> > ></FONT>
<BR><FONT SIZE=3D2>> > > If vendors are doing this already and =
this is trying to avoid</FONT>
<BR><FONT SIZE=3D2>> > > interoperability</FONT>
<BR><FONT SIZE=3D2>> > > problems... then it would seem =
reasonable that the carrier</FONT>
<BR><FONT SIZE=3D2>> > > would go back and</FONT>
<BR><FONT SIZE=3D2>> > > install new images or force the =
vendor to fix the embedded</FONT>
<BR><FONT SIZE=3D2>> > > base.. but they</FONT>
<BR><FONT SIZE=3D2>> > > won't do either.. thus leaving the =
problem to stumble </FONT>
<BR><FONT SIZE=3D2>> over some day...</FONT>
<BR><FONT SIZE=3D2>> > ></FONT>
<BR><FONT SIZE=3D2>> > > Mike</FONT>
<BR><FONT SIZE=3D2>> > ></FONT>
<BR><FONT SIZE=3D2>> > > > At 13:43 10/06/2002 +0100, =
Philip Christian wrote:</FONT>
<BR><FONT SIZE=3D2>> > > ></FONT>
<BR><FONT SIZE=3D2>> > > > >I suppose that we could =
define different sub-TLVs, a</FONT>
<BR><FONT SIZE=3D2>> > > sub-TLV if the</FONT>
<BR><FONT SIZE=3D2>> > > > >identifier is an IPv4 =
address, a different sub-TLV if it</FONT>
<BR><FONT SIZE=3D2>> > > is a MAC address, etc</FONT>
<BR><FONT SIZE=3D2>> > > > ></FONT>
<BR><FONT SIZE=3D2>> > > > >Then folks could use =
whichever mechanism they prefer, as</FONT>
<BR><FONT SIZE=3D2>> > > long as it is a</FONT>
<BR><FONT SIZE=3D2>> > > > >globally unique =
identifier.</FONT>
<BR><FONT SIZE=3D2>> > > > ></FONT>
<BR><FONT SIZE=3D2>> > > > >Or is that too =
complex?</FONT>
<BR><FONT SIZE=3D2>> > > ></FONT>
<BR><FONT SIZE=3D2>> > > > Yes! That's how NSAP addresses =
got to be so awful :-)</FONT>
<BR><FONT SIZE=3D2>> > > ></FONT>
<BR><FONT SIZE=3D2>> > > =
> Mike</FONT>
<BR><FONT SIZE=3D2>> > > ></FONT>
<BR><FONT SIZE=3D2>> > > ></FONT>
<BR><FONT SIZE=3D2>> > > ></FONT>
<BR><FONT SIZE=3D2>> > > > >Philip</FONT>
<BR><FONT SIZE=3D2>> > > > ></FONT>
<BR><FONT SIZE=3D2>> > > > > > -----Original =
Message-----</FONT>
<BR><FONT SIZE=3D2>> > > > > > From: mike =
shand</FONT>
<BR><FONT SIZE=3D2>> > > [<<A =
HREF=3D"mailto:mshand@cisco.com">mailto:mshand@cisco.com</A> ><A =
HREF=3D"mailto:mshand@cisco.com">mailto:mshand@cisco.com</A> ]</FONT>
<BR><FONT SIZE=3D2>> > > > > > Sent: Monday, June 10, =
2002 12:24 PM</FONT>
<BR><FONT SIZE=3D2>> > > > > > To: Christian, Philip =
[HAL02:GI50:EXCH]</FONT>
<BR><FONT SIZE=3D2>> > > > > > Cc: =
isis-wg@spider.juniper.net</FONT>
<BR><FONT SIZE=3D2>> > > > > > Subject: Re: [Isis-wg] =
Proprietary / Private TLV numbers?</FONT>
<BR><FONT SIZE=3D2>> > > > > ></FONT>
<BR><FONT SIZE=3D2>> > > > > ></FONT>
<BR><FONT SIZE=3D2>> > > > > > At 11:29 10/06/2002 =
+0100, Philip Christian wrote:</FONT>
<BR><FONT SIZE=3D2>> > > > > > >Looking at </FONT>
<BR><FONT SIZE=3D2>> draft-ietf-isis-wg-tlv-codepoints-02.txt I =
notice</FONT>
<BR><FONT SIZE=3D2>> > > > > > that there is</FONT>
<BR><FONT SIZE=3D2>> > > > > > >not really any =
mechanism for private or proprietary</FONT>
<BR><FONT SIZE=3D2>> > > use of a TLV.</FONT>
<BR><FONT SIZE=3D2>> > > > > > ></FONT>
<BR><FONT SIZE=3D2>> > > > > > >Thus various =
companies (including my own) have just pcked</FONT>
<BR><FONT SIZE=3D2>> > > > > > one and used it</FONT>
<BR><FONT SIZE=3D2>> > > > > > >for their own =
purpose. Eventually this will create an</FONT>
<BR><FONT SIZE=3D2>> > > > > > interop =
problem,</FONT>
<BR><FONT SIZE=3D2>> > > > > > >but what else is a =
company to do?</FONT>
<BR><FONT SIZE=3D2>> > > > > > ></FONT>
<BR><FONT SIZE=3D2>> > > > > > >Is there a way =
that we could define that a certain TLV</FONT>
<BR><FONT SIZE=3D2>> > > number is for</FONT>
<BR><FONT SIZE=3D2>> > > > > > >private / =
proprietary / experimental purposes?</FONT>
<BR><FONT SIZE=3D2>> > > > > > ></FONT>
<BR><FONT SIZE=3D2>> > > > > > >This would then =
stop people just picking one.</FONT>
<BR><FONT SIZE=3D2>> > > > > > ></FONT>
<BR><FONT SIZE=3D2>> > > > > > >I am thinking that =
there would have to be some sort of</FONT>
<BR><FONT SIZE=3D2>> > > > > > entity =
identifier</FONT>
<BR><FONT SIZE=3D2>> > > > > > >in there so that =
when you see this TLV you know whether it</FONT>
<BR><FONT SIZE=3D2>> > > > > > is yours or =
not.</FONT>
<BR><FONT SIZE=3D2>> > > > > > ></FONT>
<BR><FONT SIZE=3D2>> > > > > > >Maybe we could =
define that the first four bytes are an IP</FONT>
<BR><FONT SIZE=3D2>> > > > > > address for</FONT>
<BR><FONT SIZE=3D2>> > > > > > >example. Any =
entity large enough to want to use a</FONT>
<BR><FONT SIZE=3D2>> > > > > > proprietary TLV =
would</FONT>
<BR><FONT SIZE=3D2>> > > > > > >have a public IP =
address to put in there, I would have</FONT>
<BR><FONT SIZE=3D2>> > > > > > thought. After =
the</FONT>
<BR><FONT SIZE=3D2>> > > > > > >first for bytes =
then the rest would be free.</FONT>
<BR><FONT SIZE=3D2>> > > > > > ></FONT>
<BR><FONT SIZE=3D2>> > > > > > >Or maybe there is =
a better way to identify a particular</FONT>
<BR><FONT SIZE=3D2>> > > > > > company / =
entity</FONT>
<BR><FONT SIZE=3D2>> > > > > > >(like a MAC =
address)? Maybe ISO 8348?</FONT>
<BR><FONT SIZE=3D2>> > > > > > ></FONT>
<BR><FONT SIZE=3D2>> > > > > > >What do people =
think?</FONT>
<BR><FONT SIZE=3D2>> > > > > > ></FONT>
<BR><FONT SIZE=3D2>> > > > > > >Philip</FONT>
<BR><FONT SIZE=3D2>> > > > > > ></FONT>
<BR><FONT SIZE=3D2>> > > > > ></FONT>
<BR><FONT SIZE=3D2>> > > > > > This has been =
suggested before, but never came to </FONT>
<BR><FONT SIZE=3D2>> anything. I</FONT>
<BR><FONT SIZE=3D2>> > > > > > think if it</FONT>
<BR><FONT SIZE=3D2>> > > > > > WERE to be done then =
using something link the MAC OUI would</FONT>
<BR><FONT SIZE=3D2>> > > > > > probably work.</FONT>
<BR><FONT SIZE=3D2>> > > > > > What do you mean by =
ISO 8348? Do you mean ISO 6523? I</FONT>
<BR><FONT SIZE=3D2>> > > hope not :-)</FONT>
<BR><FONT SIZE=3D2>> > > > > ></FONT>
<BR><FONT SIZE=3D2>> > > > > =
> Mike</FONT>
<BR><FONT SIZE=3D2>> > > > > ></FONT>
<BR><FONT SIZE=3D2>> > > ></FONT>
<BR><FONT SIZE=3D2>> > > > =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>> > > > Isis-wg mailing list =
- Isis-wg@spider.juniper.net</FONT>
<BR><FONT SIZE=3D2>> > > > <A =
HREF=3D"http://spider.juniper.net/mailman/listinfo/isis-wg" =
TARGET=3D"_blank">http://spider.juniper.net/mailman/listinfo/isis-wg</A>=
</FONT>
<BR><FONT SIZE=3D2>> > > ></FONT>
<BR><FONT SIZE=3D2>> > ></FONT>
<BR><FONT SIZE=3D2>> > ></FONT>
<BR><FONT SIZE=3D2>> ></FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_001_01C21137.4C4F2E2A--
From Alex Zinin <zinin@psg.com> Wed Jun 5 18:00:52 2002
From: Alex Zinin <zinin@psg.com> (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
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>RE: [Isis-wg] last call on draft =
draft-ietf-isis-ext-lsp-frags-00 ...</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>To me an "extended" entity is the original =
entity plus an "extension".</FONT>
</P>
<P><FONT SIZE=3D2>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.</FONT></P>
<P><FONT SIZE=3D2>So I think that these are "extension LSPs" =
or "expansion LSPs", or something...</FONT>
<BR><FONT SIZE=3D2>And I suppose that they have an "extension =
System Identifer" too...</FONT>
</P>
<P><FONT SIZE=3D2>Next time I'll read the draft before commenting on it =
:)</FONT>
</P>
<P><FONT SIZE=3D2>Hope that helps, Philip</FONT>
</P>
<P><FONT SIZE=3D2>> -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>> From: Alex Zinin [<A =
HREF=3D"mailto:zinin@psg.com">mailto:zinin@psg.com</A>]</FONT>
<BR><FONT SIZE=3D2>> Sent: Wednesday, June 05, 2002 6:01 PM</FONT>
<BR><FONT SIZE=3D2>> To: Christian, Philip [HAL02:GI50:EXCH]</FONT>
<BR><FONT SIZE=3D2>> Cc: Amir Hermelin; isis-wg@juniper.net</FONT>
<BR><FONT SIZE=3D2>> Subject: Re: [Isis-wg] last call on =
draft</FONT>
<BR><FONT SIZE=3D2>> draft-ietf-isis-ext-lsp-frags-00 ...</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Philip,</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> >> "extended" LSPs, though not =
perfect, make more sense--I </FONT>
<BR><FONT SIZE=3D2>> couldn't come</FONT>
<BR><FONT SIZE=3D2>> >> up with a better name, maybe native =
English speakers can :)</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> > Is this is a similar concept to =
"Extended Local Circuit ID" </FONT>
<BR><FONT SIZE=3D2>> in three way</FONT>
<BR><FONT SIZE=3D2>> > handshaking?</FONT>
<BR><FONT SIZE=3D2>> > it sounds as though it is, in which case =
consistency is a </FONT>
<BR><FONT SIZE=3D2>> good thing.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Not exactly similar--the extended circuit ID is =
really "extended",</FONT>
<BR><FONT SIZE=3D2>> i.e., it's length is increased; in the LSP =
case, those are not</FONT>
<BR><FONT SIZE=3D2>> enlarged LSPs, but additional ones announced as =
originated by</FONT>
<BR><FONT SIZE=3D2>> a fake IS and thus extending the amount of =
information a physical</FONT>
<BR><FONT SIZE=3D2>> IS can announce...</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Alex</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_001_01C20CC1.894C7168--
From Alex Zinin <zinin@psg.com> Wed Jun 5 20:15:41 2002
From: Alex Zinin <zinin@psg.com> (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
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>RE: [Isis-wg] Proprietary / Private TLV numbers?</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>First shot at a draft. Comments?</FONT>
</P>
<P><FONT SIZE=3D2>Philip</FONT>
</P>
<P><FONT SIZE=3D2>Internet Engineering Task =
Force &=
nbsp; &=
nbsp; P. Christian </FONT>
<BR><FONT SIZE=3D2>INTERNET =
DRAFT &=
nbsp; &=
nbsp; &=
nbsp; Nortel Networks </FONT>
<BR><FONT =
SIZE=3D2> &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; June 2002 </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT =
SIZE=3D2> &nb=
sp; &nb=
sp; TLV for Proprietary Use </FONT>
<BR><FONT =
SIZE=3D2> &nb=
sp; =
draft-ietf-isis-private-tlv-forlist.txt </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2>Status of this Memo </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> This document is an Internet =
Draft. Internet Drafts are working </FONT>
<BR><FONT SIZE=3D2> documents of the Internet Engineering =
Task Force (IETF), its Areas, </FONT>
<BR><FONT SIZE=3D2> and its Working Groups. Note that =
other groups may also distribute </FONT>
<BR><FONT SIZE=3D2> working documents as Internet Drafts. =
</FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> Internet Drafts are draft documents =
valid for a maximum of six </FONT>
<BR><FONT SIZE=3D2> months. Internet Drafts may be =
updated, replaced, or obsoleted by </FONT>
<BR><FONT SIZE=3D2> other documents at any time. It =
is not appropriate to use Internet </FONT>
<BR><FONT SIZE=3D2> Drafts as reference material or to cite =
them other than as a </FONT>
<BR><FONT SIZE=3D2> "working draft" or "work =
in progress". </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> To learn the current status of any =
Internet-Draft, please check the </FONT>
<BR><FONT SIZE=3D2> 1id-abstracts.txt listing contained in =
the Internet-Drafts Shadow </FONT>
<BR><FONT SIZE=3D2> Directories on ds.internic.net, =
nic.nordu.net, ftp.isi.edu, or </FONT>
<BR><FONT SIZE=3D2> munnari.oz.au. </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> A revised version of this draft =
document will be submitted to the </FONT>
<BR><FONT SIZE=3D2> RFC editor as a Proposed Standard for =
the Internet Community. </FONT>
<BR><FONT SIZE=3D2> Discussion and suggestions for =
improvement are requested. This </FONT>
<BR><FONT SIZE=3D2> document will expire before December =
2002. Distribution of this </FONT>
<BR><FONT SIZE=3D2> draft is unlimited. </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2>1. Abstract </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> This document defines a TLV that may be =
used by any individual, </FONT>
<BR><FONT SIZE=3D2> company or other organisation for =
vendor specific or experimental </FONT>
<BR><FONT SIZE=3D2> extensions to the IS-IS routing =
protocol, and defines the format of </FONT>
<BR><FONT SIZE=3D2> the TLV. </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2>2. Conventions used in this document </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> The key words "MUST", =
"MUST NOT", "REQUIRED", "SHALL", =
"SHALL NOT", </FONT>
<BR><FONT SIZE=3D2> "SHOULD", "SHOULD =
NOT", "RECOMMENDED", "MAY", and =
"OPTIONAL" in </FONT>
<BR><FONT SIZE=3D2> this document are to be interpreted as =
described in RFC 2119. </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2>3. Introduction </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> IS-IS as defined in [1] has always been =
an extensible routing </FONT>
<BR><FONT SIZE=3D2> protocol. Extensions to IS-IS are =
encoded as a TLV. Critically [1] </FONT>
<BR><FONT SIZE=3D2> has always defined that a router that =
does not understand a TLV that </FONT>
<BR><FONT SIZE=3D2> it receives in an LSP SHALL process the =
parts of the LSP that it </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT =
SIZE=3D2> &nb=
sp; =
TLV for Proprietary =
Use &nb=
sp; June 2002 </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> does understand, and SHALL flood the =
entire LSP, including all TLVs </FONT>
<BR><FONT SIZE=3D2> whether they are understand or not, on =
to other routers in the </FONT>
<BR><FONT SIZE=3D2> network. </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> Thus information that is encoded into a =
TLV and placed in an LSP by </FONT>
<BR><FONT SIZE=3D2> a router will be propagated to every =
other router in an IS-IS level-</FONT>
<BR><FONT SIZE=3D2> 1 area or level-2 subdomain. </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> The basic function of an IS-IS TLV is =
identified by the first byte </FONT>
<BR><FONT SIZE=3D2> of the TLV. Thus there are only =
256 possible basic types of TLV. </FONT>
<BR><FONT SIZE=3D2> Certain types of TLV have been defined =
to include sub-TLVs so that a </FONT>
<BR><FONT SIZE=3D2> single TLV type can be used for =
multiple functions. </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> No single authority assigns TLV type =
numbers, [2] lists all known </FONT>
<BR><FONT SIZE=3D2> TLV type numbers at this time. =
Also no TLV type number was ever </FONT>
<BR><FONT SIZE=3D2> defined for private, proprietary or =
experimental use. </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> The extensible nature of IS-IS has made =
the use of TLVs in LSPs for </FONT>
<BR><FONT SIZE=3D2> proprietary purposes so useful that in =
the absence of a central </FONT>
<BR><FONT SIZE=3D2> authority for assigning TLV type =
numbers vendors have occasionally </FONT>
<BR><FONT SIZE=3D2> simply chosen a number and hoped for =
the best. The risk is that </FONT>
<BR><FONT SIZE=3D2> such a TLV type number may then be =
chosen by another organization at </FONT>
<BR><FONT SIZE=3D2> a later time for a different function, =
thus creating an </FONT>
<BR><FONT SIZE=3D2> interoperability problem. Also this =
accelerates the burning of the </FONT>
<BR><FONT SIZE=3D2> 256 possible TLV type numbers. </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> This document specifies a TLV type =
number that may be used for </FONT>
<BR><FONT SIZE=3D2> proprietary, private or experimental =
purposes, and a mechanism that </FONT>
<BR><FONT SIZE=3D2> insures that implementations using this =
TLV type number can exist in </FONT>
<BR><FONT SIZE=3D2> the same network without creating =
interoperability problems. </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> By using this new TLV, companies, =
individuals or institutions may </FONT>
<BR><FONT SIZE=3D2> use extensions to IS-IS without fear of =
interoperability problems </FONT>
<BR><FONT SIZE=3D2> with other organizations in the future, =
and the available pool of </FONT>
<BR><FONT SIZE=3D2> TLV type numbers will no longer be =
diminished by proprietary use. </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2>4. TLV type number for proprietary use </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> The type field for this TLV SHALL be =
XXX. </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> TLVs that use XXX for the type field =
MUST include a valid IEEE </FONT>
<BR><FONT SIZE=3D2> assigned OUI as the first three bytes =
of the value of the TLV, </FONT>
<BR><FONT SIZE=3D2> except for the concession stated =
below. The rest of the value field </FONT>
<BR><FONT SIZE=3D2> may then be used freely. </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> On receipt of an LSP a router MUST =
ignore TLVs of type XXX that </FONT>
<BR><FONT SIZE=3D2> include an OUI from a different =
organization, but MUST flood the LSP </FONT>
<BR><FONT SIZE=3D2> onwards as per [1]. </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> Organizations or individuals that do =
not have access to an IEEE </FONT>
<BR><FONT SIZE=3D2> assigned OUI MAY use a locally assigned =
three byte value instead, </FONT>
<BR><FONT SIZE=3D2> however in this case the second least =
significant bit of the first </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT =
SIZE=3D2> &nb=
sp; =
TLV for Proprietary =
Use &nb=
sp; June 2002 </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> byte MUST be set to one to indicate =
that it is non-IEEE assigned, </FONT>
<BR><FONT SIZE=3D2> and implementations that use such a =
non-IEEE assigned OUI SHOULD NOT </FONT>
<BR><FONT SIZE=3D2> be installed in the Internet. A =
non-IEEE assigned OUI does not </FONT>
<BR><FONT SIZE=3D2> guarantee uniqueness and may cause =
interoperability problems with </FONT>
<BR><FONT SIZE=3D2> implementations from other =
organizations. </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> After the first three bytes of the =
value field of the TLV subsequent </FONT>
<BR><FONT SIZE=3D2> bytes may be used freely for any =
purpose provided that the resultant </FONT>
<BR><FONT SIZE=3D2> TLV is conformant with [1]. </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> Many organizations will have access to =
only one or a few OUIs. </FONT>
<BR><FONT SIZE=3D2> Implementers are free to format the =
value field after their OUI into </FONT>
<BR><FONT SIZE=3D2> sub-TLVs so that it may be used for =
multiple purposes, and would be </FONT>
<BR><FONT SIZE=3D2> well advised to do this from the =
outset. Note that if subTLVs are </FONT>
<BR><FONT SIZE=3D2> to be used then the very first =
implementation to exist will need to </FONT>
<BR><FONT SIZE=3D2> recognize the subTLV structure, and =
ignore subTLVs that it does not </FONT>
<BR><FONT SIZE=3D2> understand whilst searching for subTLVs =
that it does understand. </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2>5. Security Considerations </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> The proprietary TLV raises no new =
security issues for IS-IS. </FONT>
<BR><FONT SIZE=3D2> Information placed in an IS-IS TLV =
cannot be considered secure, and </FONT>
<BR><FONT SIZE=3D2> so if security is required then an =
implementation will need to </FONT>
<BR><FONT SIZE=3D2> encrypt the information using a =
suitable method. </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2>6. References </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> [1] ISO, "Intermediate system to =
Intermediate system routeing </FONT>
<BR><FONT SIZE=3D2> information exchange protocol for use =
in conjunction with the </FONT>
<BR><FONT SIZE=3D2> Protocol for providing the =
Connectionless-mode Network Service (ISO </FONT>
<BR><FONT SIZE=3D2> 8473)", ISO/IEC 10589:1992. =
</FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> [2] =
draft-ietf-isis-wg-tlv-codepoints-02.txt, Reserved TLV </FONT>
<BR><FONT SIZE=3D2> Codepoints in ISIS, Tony Przygienda, =
November 2001 </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2>7. Acknowledgments </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> The author takes no credit for this =
work as the concept was </FONT>
<BR><FONT SIZE=3D2> discussed in the IS-IS Working Group =
before the author even became </FONT>
<BR><FONT SIZE=3D2> an active participant. =
Suggestions for acknowledgement gladly </FONT>
<BR><FONT SIZE=3D2> received. </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2>8. Author's Addresses </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> Philip Christian </FONT>
<BR><FONT SIZE=3D2> Nortel Networks Harlow Laboratories =
</FONT>
<BR><FONT SIZE=3D2> London Road, Harlow, </FONT>
<BR><FONT SIZE=3D2> Essex, CM17 9NA UK </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2> Email: christi@nortelnetworks.com =
</FONT>
</P>
<P><FONT SIZE=3D2> </FONT>
</P>
</BODY>
</HTML>
------_=_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>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>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>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>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"
<html>
<br>
Minor comments below.<br>
<br>
At 08:33 AM 6/12/2002, Philip Christian wrote:<br>
<br>
<blockquote type=cite cite><font size=2>I have done an update, see
below</font> <br>
<br>
<font size=2>Philip</font> <br>
<br>
<font size=2>> -----Original Message-----</font> <br>
<font size=2>> From: mike shand
[<a href="mailto:mshand@cisco.com">mailto:mshand@cisco.com</a>]</font>
<br>
<font size=2>> Sent: Tuesday, June 11, 2002 3:56 PM</font> <br>
<font size=2>> To: Christian, Philip [HAL02:GI50:EXCH]</font> <br>
<font size=2>> Cc: 'Tony Przygienda'; isis-wg@spider.juniper.net;
'Mike Truskowski'</font> <br>
<font size=2>> Subject: RE: [Isis-wg] Proprietary / Private TLV
numbers?</font> <br>
<font size=2>> </font><br>
<font size=2>> </font><br>
<font size=2>> At 15:38 11/06/2002 +0100, Philip Christian
wrote:</font> <br>
<font size=2>> >On receipt of an LSP a router MUST ignore TLVs of
type XXX that</font> <br>
<font size=2>> > include an OUI from a different
organization,</font> <br>
<font size=2>> </font><br>
<font size=2>> MUST is a bit strong here. SHOULD or MAY, perhaps. If
you </font><br>
<font size=2>> know how to parse </font><br>
<font size=2>> company X's subTLVs you should be allowed to do
so.</font> <br>
<font size=2>> </font><br>
<font size=2>> I'm not sure we want to get into mentioning
non-standard OUIs </font><br>
<font size=2>> with G or L </font><br>
<font size=2>> bits set.</font> <br>
<font size=2>> </font><br>
<font size=2>>
Mike</font> <br>
<font size=2>> </font><br>
<font size=2>> <br>
</font><br>
<font size=2>Internet Engineering Task
Force
P. Christian </font><br>
<font size=2>INTERNET
DRAFT
Nortel Networks </font><br>
<font size=2>
June 2002 </font><br>
<font size=2> </font> <br>
<font size=2> </font> <br>
<font size=2>
TLV for Proprietary Use </font><br>
<font size=2>
draft-ietf-isis-private-tlv-forlist2.txt </font><br>
<font size=2> </font> <br>
<font size=2>Status of this Memo </font><br>
<font size=2> </font> <br>
<font size=2> This document is an Internet-Draft and is in
full conformance with </font><br>
<font size=2> all provisions of Section 10 of RFC 2026.
</font><br>
<font size=2> </font><br>
<font size=2> Internet Drafts are working documents of the
Internet Engineering </font><br>
<font size=2> Task Force (IETF), its Areas, and its Working
Groups. Note that </font><br>
<font size=2> other groups may also distribute working
documents as Internet </font><br>
<font size=2> Drafts. </font><br>
<font size=2> </font><br>
<font size=2> Internet Drafts are draft documents valid for a
maximum of six </font><br>
<font size=2> months. Internet Drafts may be updated,
replaced, or obsoleted by </font><br>
<font size=2> other documents at any time. It is not
appropriate to use Internet </font><br>
<font size=2> Drafts as reference material or to cite them
other than as a </font><br>
<font size=2> "working draft" or "work in
progress". </font><br>
<font size=2> </font><br>
<font size=2> The list of current Internet-Drafts can be
accessed at </font><br>
<font size=2>
<a href="http://www.ietf.org/ietf/1id-abstracts.txt">http://www.ietf.org/ietf/1id-abstracts.txt</a>
</font><br>
<font size=2> </font><br>
<font size=2> The list of Internet-Draft Shadow Directories can be accessed at </font><br>
<font size=2> <a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>. </font><br>
<font size=2> </font><br>
<font size=2> This memo provides information for the Internet community. This memo </font><br>
<font size=2> does not specify an Internet standard of any kind. </font><br>
<font size=2> </font><br>
<font size=2> Distribution of this draft is unlimited. </font><br>
<font size=2> </font><br>
<font size=2> </font><br>
<font size=2>1. Abstract </font><br>
<font size=2> </font><br>
<font size=2> This document defines a TLV that may be used for vendor specific or </font><br>
<font size=2> experimental extensions to the IS-IS routing protocol, and defines </font><br>
<font size=2> the format of the TLV. </font><br>
<font size=2> </font><br>
<font size=2> </font><br>
<font size=2>2. Conventions used in this document </font><br>
<font size=2> </font><br>
<font size=2> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", </font><br>
<font size=2> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in </font><br>
<font size=2> this document are to be interpreted as described in RFC 2119. </font><br>
<font size=2> <br>
</font><br>
<br>
<br>
<br>
<font size=2> </font><br>
<font size=2> TLV for Proprietary Use June 2002 </font><br>
<font size=2> </font> <br>
<font size=2>3. Introduction </font><br>
<font size=2> </font><br>
<font size=2> IS-IS as defined in [1] has always been an extensible routing </font><br>
<font size=2> protocol. Extensions to IS-IS are encoded as a TLV. Critically [1] </font><br>
<font size=2> has always defined that an IS-IS router SHALL flood entire LSPs that </font><br>
<font size=2> it receives on to other IS-IS routers in the network, whether or not </font><br>
<font size=2> it understands the TLVs that are included in the LSP. Also IS-IS </font><br>
<font size=2> LSPs are structured such that a router can find TLVs that it </font><br>
<font size=2> understands, whilst ignoring ones that it does not. </font><br>
<font size=2> </font><br>
<font size=2> Thus information that is encoded into a TLV and placed into an LSP </font><br>
<font size=2> by a router will be propagated to every other router in an IS-IS </font><br>
<font size=2> level-1 area or level-2 subdomain. </font><br>
<font size=2> </font><br>
<font size=2> The basic function of an IS-IS TLV is identified by the first byte </font><br>
<font size=2> of the TLV. Thus there are only 256 possible basic types of TLV. </font><br>
<font size=2> Certain types of TLV have been defined to include sub-TLVs so that a </font><br>
<font size=2> single TLV type can be used for multiple functions. </font><br>
<font size=2> </font><br>
<font size=2> No single authority assigns TLV type numbers, [2] lists all known </font></blockquote><br>
use semicolon instead of comma above<br>
<br>
<blockquote type=cite cite><font size=2> TLV type numbers at this time. Also no TLV type number was ever </font><br>
<font size=2> defined for private, proprietary or experimental use. </font><br>
<font size=2> </font><br>
<font size=2> The extensible nature of IS-IS has made the use of TLVs in LSPs for </font><br>
<font size=2> proprietary purposes so useful that in the absence of a central </font><br>
<font size=2> authority for assigning TLV type numbers vendors have occasionally </font><br>
<font size=2> simply chosen a number and hoped for the best. The risk is that </font><br>
<font size=2> such a TLV type number may then be chosen by another organization at </font><br>
<font size=2> a later time for a different function, thus creating an </font><br>
<font size=2> interoperability problem. Also this accelerates the burning of the </font></blockquote><br>
"depletion" rather than "burning".<br>
<br>
<blockquote type=cite cite><font size=2> 256 possible TLV type numbers. </font><br>
<font size=2> </font><br>
<font size=2> This document specifies a TLV type number that may be used for </font><br>
<font size=2> proprietary, private or experimental purposes, and a mechanism that </font><br>
<font size=2> insures that implementations from different sources can use the TLV </font><br>
<font size=2> for different purposes in the same network without creating </font><br>
<font size=2> interoperability problems. </font><br>
<font size=2> </font><br>
<font size=2> By using this new TLV, companies, individuals or institutions may </font><br>
<font size=2> use extensions to IS-IS without fear of interoperability problems </font><br>
<font size=2> with other organizations in the future, and the available pool of </font><br>
<font size=2> TLV type numbers will no longer be diminished by proprietary use. </font><br>
<font size=2> </font><br>
<font size=2>4. TLV type number for proprietary use </font><br>
<font size=2> </font><br>
<font size=2> The type field for this TLV SHALL be XXX. </font><br>
<font size=2> </font><br>
<font size=2> TLVs that use XXX for the type field MUST include a valid IEEE </font><br>
<font size=2> assigned OUI as the first three bytes of the value field of the TLV. </font><br>
<font size=2> For more information about OUIs see [3]. </font><br>
<font size=2> <br>
</font><br>
<font size=2> </font><br>
<font size=2> TLV for Proprietary Use June 2002 </font><br>
<font size=2> </font> <br>
<font size=2> On receipt of an LSP a router MAY ignore TLVs of type XXX that </font><br>
<font size=2> include an OUI from a different organization, however the router </font></blockquote><br>
"unrecognized OUI" rather than "different organization". And I think<br>
"MAY" should be "MUST", but I won't quibble.<br>
<br>
<blockquote type=cite cite><font size=2> MUST flood the LSP onwards as per [1]. </font><br>
<font size=2> </font> <br>
<font size=2> After the first three bytes of the value field subsequent bytes may </font><br>
<font size=2> be used freely for any purpose provided that the resultant TLV is </font><br>
<font size=2> conformant with [1]. </font></blockquote><br>
I would say "The format of the remainder of the TLV would be defined<br>
by the identified organization, and MUST be conformant with [1]."<br>
<br>
<blockquote type=cite cite><font size=2> </font><br>
<font size=2> Many organizations will have access to only one or a few OUIs. </font><br>
<font size=2> Implementers are free to format the value field after their OUI into </font><br>
<font size=2> sub-TLVs so that it may be used for multiple purposes, and would be </font><br>
<font size=2> well advised to do this from the outset. Note that if sub-TLVs are </font><br>
<font size=2> to be used then the very first implementation to exist will need to </font><br>
<font size=2> recognize the sub-TLV structure, and ignore sub-TLVs that it does </font><br>
<font size=2> not understand whilst searching for sub-TLVs that it does </font><br>
<font size=2> understand. </font></blockquote><br>
This is one way. Another way would be to use EUI48 or EUI64 numbers<br>
as type codes, especially for large organizations to allow hierarchical<br>
assignment of type codes. EUI numbers start with the OUI, and the<br>
remainder is allocated by the organization owning the OUI. Admittedly,<br>
this doesn't allow as optimized use of a switch statement as sub-TLVs<br>
would.<br>
<br>
Regards,<br>
Jeff<br>
<br>
<blockquote type=cite cite><font size=2> 5. Security Considerations </font><br>
<font size=2> </font> <br>
<font size=2> The proprietary TLV raises no new security issues for IS-IS. </font><br>
<font size=2> Information placed in an IS-IS TLV cannot be considered secure, and </font><br>
<font size=2> so if security is required then an implementation will need to </font><br>
<font size=2> encrypt the information using a suitable method. </font><br>
<font size=2> </font><br>
<font size=2>6. References </font><br>
<font size=2> </font><br>
<font size=2> [1] ISO, "Intermediate system to Intermediate system routeing </font><br>
<font size=2> information exchange protocol for use in conjunction with the </font><br>
<font size=2> Protocol for providing the Connectionless-mode Network Service (ISO </font><br>
<font size=2> 8473)", ISO/IEC 10589:1992. </font><br>
<font size=2> </font><br>
<font size=2> [2] draft-ietf-isis-wg-tlv-codepoints-02.txt, Reserved TLV </font><br>
<font size=2> Codepoints in ISIS, Tony Przygienda, November 2001 </font><br>
<font size=2> </font><br>
<font size=2> [3] <a href="http://standards.ieee.org/regauth/oui/index.html">http://standards.ieee.org/regauth/oui/index.html</a> </font><br>
<font size=2> </font><br>
<font size=2>7. Acknowledgments </font><br>
<font size=2> </font><br>
<font size=2> The author takes no credit for this work as the concept was </font><br>
<font size=2> discussed in the IS-IS Working Group before the author even became </font><br>
<font size=2> an active participant. Suggestions for acknowledgement gladly </font><br>
<font size=2> received. </font><br>
<font size=2> </font><br>
<font size=2>8. Author's Addresses </font><br>
<font size=2> </font><br>
<font size=2> Philip Christian </font><br>
<font size=2> Nortel Networks Harlow Laboratories </font><br>
<font size=2> London Road, Harlow, </font><br>
<font size=2> Essex, CM17 9NA UK </font><br>
<font size=2> </font><br>
<font size=2> Email: christi@nortelnetworks.com</font> </blockquote></html>
--=====================_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: <F149dsfgeRtb4W5gz1D0001a1b3@hotmail.com>
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: <F403Xemb2VswIDrcAMi0000212c@hotmail.com>
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: <F210p1jajw8sCMjfR4q0001b78f@hotmail.com>
_________________________________________________________________
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: <EB5FFC72F183D411B38200062957342901E577E6@r2d2.axiowave.com>
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: <F141ZJorwBpP6m6PUqC0001c168@hotmail.com>
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: <F179kraIvF9aNMLHmsB0001e71f@hotmail.com>
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: <F239hvqgStMVhEUsebm00003040@hotmail.com>
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 <riw@cisco.com> Tue Jun 18 11:59:10 2002
From: Russ White <riw@cisco.com> (Russ White)
Date: Tue, 18 Jun 2002 06:59:10 -0400 (EDT)
Subject: [Isis-wg] draft-ietf-isis-restart-01.txt
In-Reply-To: <F239hvqgStMVhEUsebm00003040@hotmail.com>
Message-ID: <Pine.GSO.4.21.0206180645560.4583-100000@ruwhite-u10.cisco.com>
> 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: <F171IjoWaPwPubQbzPU0000f925@hotmail.com>
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 <mshand@cisco.com>
>To: "Kent Wong" <wongkent@hotmail.com>
>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: <EB5FFC72F183D411B38200062957342901E57839@r2d2.axiowave.com>
> 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 <mshand@cisco.com>
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: <F200Nbx7AQu7Fm5PtAa00002d96@hotmail.com>
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: <C7DF4400240AFB4095D98C7C6EC2A34A5DE14E@bart.cwnt.com>
>> 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 <zinin@psg.com> Thu Jun 20 20:44:47 2002
From: Alex Zinin <zinin@psg.com> (Alex Zinin)
Date: Thu, 20 Jun 2002 12:44:47 -0700
Subject: [Isis-wg] ISIS drafts status summary ...
In-Reply-To: <C7DF4400240AFB4095D98C7C6EC2A34A5DE14E@bart.cwnt.com>
References: <C7DF4400240AFB4095D98C7C6EC2A34A5DE14E@bart.cwnt.com>
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: <EB5FFC72F183D411B38200062957342901E57876@r2d2.axiowave.com>
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: <C7DF4400240AFB4095D98C7C6EC2A34A5EA530@bart.cwnt.com>
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: <EB5FFC72F183D411B38200062957342901E5787C@r2d2.axiowave.com>
> > 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: <F171IjoWaPwPubQbzPU0000f925@hotmail.com>
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 <mshand@cisco.com>
>>To: "Kent Wong" <wongkent@hotmail.com>
>>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: <Mail from mike shand <mshand@cisco.com>
<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" <ramsrm@tdd.sj.nec.com Mon Jun 24 19:58:55 2002
From: ramsrm@tdd.sj.nec.com" <ramsrm@tdd.sj.nec.com (ramanathan rams)
Date: Mon, 24 Jun 2002 11:58:55 -0700
Subject: [Isis-wg] doubts
Message-ID: <01C21B76.85268420.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 <mshand@cisco.com>
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" <ramsrm@tdd.sj.nec.com Mon Jun 24 22:12:11 2002
From: ramsrm@tdd.sj.nec.com" <ramsrm@tdd.sj.nec.com (ramanathan rams)
Date: Mon, 24 Jun 2002 14:12:11 -0700
Subject: [Isis-wg] doubts.
Message-ID: <01C21B89.22D662A0.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" <ramsrm@tdd.sj.nec.com Tue Jun 25 18:34:28 2002
From: ramsrm@tdd.sj.nec.com" <ramsrm@tdd.sj.nec.com (ramanathan rams)
Date: Tue, 25 Jun 2002 10:34:28 -0700
Subject: [Isis-wg] doubts
Message-ID: <01C21C33.E33C39C0.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: <F247mBySsxVY60mJWEs0000022f@hotmail.com>
References: <F247mBySsxVY60mJWEs0000022f@hotmail.com>
Message-ID: <20020626164242.24881bdc.dang@nexthop.com>
On Wed, 26 Jun 2002 20:11:31 +0000
"Suresh Boddapati" <sboddapa@hotmail.com> 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" <ramsrm@tdd.sj.nec.com Wed Jun 26 21:57:29 2002
From: ramsrm@tdd.sj.nec.com" <ramsrm@tdd.sj.nec.com (ramanathan rams)
Date: Wed, 26 Jun 2002 13:57:29 -0700
Subject: [Isis-wg] doubts
Message-ID: <01C21D19.6A0203A0.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: <EB5FFC72F183D411B38200062957342901E578F2@r2d2.axiowave.com>
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: <F247mBySsxVY60mJWEs0000022f@hotmail.com>
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: <F693G5aYY61LEdyt3ce000006d4@hotmail.com>
>From: "Rajesh Saluja" <rsaluja@nortelnetworks.com>
>To: Suresh Boddapati <sboddapa@hotmail.com>
>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: <F247mBySsxVY60mJWEs0000022f@hotmail.com> (sboddapa@hotmail.com)
References: <F247mBySsxVY60mJWEs0000022f@hotmail.com>
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" <sboddapa@hotmail.com>
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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
List-Post: <mailto:isis-wg@spider.juniper.net>
List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
<mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
<mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
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: <F84Smz6UuEhjJ8uT6Ss00000763@hotmail.com>
>From: Dave Katz <dkatz@juniper.net>
>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" <sboddapa@hotmail.com>
> 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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
> List-Post: <mailto:isis-wg@spider.juniper.net>
> List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
> <mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
> List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
> List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
> <mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
> List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
> 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: <F84Smz6UuEhjJ8uT6Ss00000763@hotmail.com> (sboddapa@hotmail.com)
References: <F84Smz6UuEhjJ8uT6Ss00000763@hotmail.com>
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" <sboddapa@hotmail.com>
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 <dkatz@juniper.net>
>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" <sboddapa@hotmail.com>
> 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: <mailto:isis-wg-request@spider.juniper.net?subject=help>
> List-Post: <mailto:isis-wg@spider.juniper.net>
> List-Subscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
> <mailto:isis-wg-request@spider.juniper.net?subject=subscribe>
> List-Id: IETF IS-IS working group <isis-wg.spider.juniper.net>
> List-Unsubscribe: <http://spider.juniper.net/mailman/listinfo/isis-wg>,
> <mailto:isis-wg-request@spider.juniper.net?subject=unsubscribe>
> List-Archive: <http://spider.juniper.net/pipermail/isis-wg/>
> 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: <F693G5aYY61LEdyt3ce000006d4@hotmail.com>
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: <F164ii08N8yxdZjfNLn00000f4b@hotmail.com>
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" <rsaluja@nortelnetworks.com>
>To: Suresh Boddapati <sboddapa@hotmail.com>
>CC: "Rajesh Saluja" <rsaluja@nortelnetworks.com>,
>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" <yjim@lge.com Sat Jun 29 01:20:18 2002
From: Yongjun Im" <yjim@lge.com (Yongjun Im)
Date: Sat, 29 Jun 2002 09:20:18 +0900
Subject: [Isis-wg] PPP/HDLC encapsulation for IS-IS packet
Message-ID: <00a101c21f02$c01480c0$3b8c9696@lge.com>
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.