From ramsrm@tdd.sj.nec.com" hi all, could u please explain me the following doubts? In the ISIS extensions for TE draft, * IPV4 Address sub TLV gives the IPv4 Address of the interface described by the main TLV. Main TLV is IS extended reachability TLV. And IS extended reachability describes about the link to the neighbour. So the IPv4 Address of the interface described is the IPv4 Address of the neighbour. is this right? if so, what does the IPv4 neighbour address sub TLV describe? * we have IP reachability TLV also. Could u please explain me the reason why all the TE properties sub TLVs are added to IS reachability TLV rather than IP reachability TLV?. thanks rams. From satish@pluris.com Tue Jul 2 00:30:34 2002 From: satish@pluris.com (Satish Dattatri) Date: Mon, 1 Jul 2002 16:30:34 -0700 Subject: [Isis-wg] doubts. Message-ID: <17C81AD1F1FED411991E006008F6D1CA029E8406@avalon.pluris.com> o Traffic engg needs information about links and the best way is to put that info along with the IS neighbors. There are 2 interface address(es) our own put in the IPV4 Address sub-tlv and the IPV4 Neighbor Address sub-tlv contains the neigh's. o In order to compute route(s) we need the IP reachability information. Remember this draft is talking about new TLVs as replacement for the Old advertisement of IS Neighbor TLV, IP Internal Reachability Option and IP External Reachability Option. Both the Old and the New options may co-exist until the transition is completed. Hope that helps, satish > -----Original Message----- > From: ramanathan rams [mailto:ramsrm@tdd.sj.nec.com] > Sent: Monday, July 01, 2002 4:03 PM > To: 'isis-wg@spider.juniper.net' > Cc: 'ramanathan_rams@hotmail.com' > Subject: [Isis-wg] doubts. > > > 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. > > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg > From jlearman@cisco.com Tue Jul 2 16:17:43 2002 From: jlearman@cisco.com (Jeff Learman) Date: Tue, 02 Jul 2002 11:17:43 -0400 Subject: [Isis-wg] Proprietary / Private TLV numbers? In-Reply-To: <4103264BC8D3D51180B7002048400C454FB706@zhard0jd.europe.nor tel.com> Message-ID: <4.3.2.7.2.20020702111702.01abcd48@dingdong.cisco.com> --=====================_83142652==_.ALT Content-Type: text/plain; charset="us-ascii" At 01:00 PM 6/10/2002, Philip Christian wrote: >I am guessing that OUI means an IEEE assigned MAC address? It's the first three bytes of an IEEE assigned MAC address. An OUI can be used for purposes other than assigning MAC addresses. See http://standards.ieee.org/regauth/oui/index.shtml for more info. Jeff >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 >> > > > >> > > >> > > >> > >> >> >> --=====================_83142652==_.ALT Content-Type: text/html; charset="us-ascii" At 01:00 PM 6/10/2002, Philip Christian wrote:

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

It's the first three bytes of an IEEE assigned MAC address.
An OUI can be used for purposes other than assigning MAC addresses.

See http://standards.ieee.org/regauth/oui/index.shtml for more info.

Jeff


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
> > > >
> > >
> > >
> >
>
>
>
--=====================_83142652==_.ALT-- From cmartin@gnilink.net Wed Jul 3 15:27:27 2002 From: cmartin@gnilink.net (Martin, Christian) Date: Wed, 3 Jul 2002 10:27:27 -0400 Subject: [Isis-wg] last call on draft draft-ietf-isis-ext-lsp-frags-00 ... Message-ID: <94B9091E1149D411A45C00508BACEB35015F3030@entmail.gnilink.com> To use Philip's analogy, houses with extensions are not extension houses they are extended houses. The LSP is extended, not extensioned. Extension is a noun, extended is an adjective. ex*tend*ed Pronunciation Key (k-stndd) adj. Enlarged or broad in meaning, scope, or influence: an extended sense of the word honest. extension \Ex*ten"sion\, n. [L. extensio: cf. F. extension. See Extend, v. t.] 1. The act of extending or the state of being extended; a stretching out; enlargement in breadth or continuation of length; increase; augmentation; expansion. IMO, of course... chris >-----Original Message----- >From: Alex Zinin [mailto:zinin@psg.com] >Sent: Wednesday, June 05, 2002 3:16 PM >To: Philip Christian >Cc: Amir Hermelin; isis-wg@juniper.net >Subject: Re: [Isis-wg] last call on draft >draft-ietf-isis-ext-lsp-frags-00 ... > > > >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 > > >_______________________________________________ >Isis-wg mailing list - Isis-wg@spider.juniper.net >http://spider.juniper.net/mailman/listinfo/isis>-wg > From amir@cwnt.com Wed Jul 3 16:09:12 2002 From: amir@cwnt.com (Amir Hermelin) Date: Wed, 3 Jul 2002 18:09:12 +0300 Subject: [Isis-wg] last call on draft draft-ietf-isis-ext-lsp-frags-00 ... Message-ID: If I'm not mistaken, this thread is a month old and was already resolved - seems to have been mistakenly resent to the group. -- 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: Wednesday, June 05, 2002 10:16 PM >To: Philip Christian >Cc: Amir Hermelin; isis-wg@juniper.net >Subject: Re: [Isis-wg] last call on draft >draft-ietf-isis-ext-lsp-frags-00 ... > > > >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 > > >_______________________________________________ >Isis-wg mailing list - Isis-wg@spider.juniper.net >http://spider.juniper.net/mailman/listinfo/isis-wg > From dkatz@juniper.net Wed Jul 3 17:58:15 2002 From: dkatz@juniper.net (Dave Katz) Date: Wed, 3 Jul 2002 09:58:15 -0700 (PDT) Subject: [Isis-wg] no of routers in an area In-Reply-To: <000401c20868$90a8d580$1305a8c0@future.futsoft.com> (rameshrr@future.futsoft.com) References: <000401c20868$90a8d580$1305a8c0@future.futsoft.com> Message-ID: <200207031658.g63GwFv35635@cirrus.juniper.net> One less than the point at which the weakest implementation collapses. --Dave Is there any limitation on number of "Intermediate systems" can be configured in an ISIS area? From prz@net4u.ch Wed Jul 3 21:18:25 2002 From: prz@net4u.ch (Tony Przygienda) Date: Wed, 03 Jul 2002 13:18:25 -0700 Subject: [Isis-wg] Proprietary / Private TLV numbers? References: <4103264BC8D3D51180B7002048400C454FB709@zhard0jd.europe.nortel.com> Message-ID: <3D235C11.1070803@net4u.ch> Philip Christian wrote: > 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? > you like 250? > 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... > I looked at your draft and looks ok. Actually, MAC addresses have a 'local-valid-only' bit but I forgot whether it was in OUI or not or maybe that's the bit you found. small comment on draft, pls find a reference to OUI description and include it. Many people don't know the concept thanks -- tony From jparker@axiowave.com Wed Jul 3 21:56:14 2002 From: jparker@axiowave.com (Jeff Parker) Date: Wed, 3 Jul 2002 16:56:14 -0400 Subject: [Isis-wg] Proprietary / Private TLV numbers? Message-ID: > I looked at your draft and looks ok. Actually, MAC addresses have a > 'local-valid-only' bit but I forgot whether it > was in OUI or not or maybe that's the bit you found. I think you are both thinking about the "global/local" bit, which is the second bit on the wire, right after the unicast/mcast bit, which is the LSBit of the first byte. - jeff parker From jparker@axiowave.com Wed Jul 3 21:57:08 2002 From: jparker@axiowave.com (Jeff Parker) Date: Wed, 3 Jul 2002 16:57:08 -0400 Subject: [Isis-wg] Proprietary / Private TLV numbers? Message-ID: > > I looked at your draft and looks ok. Actually, MAC addresses have a > > 'local-valid-only' bit but I forgot whether it > > was in OUI or not or maybe that's the bit you found. > > I think you are both thinking about the "global/local" bit, > which is the second bit on the wire, right after the > unicast/mcast bit, which is the LSBit of the first byte. ...and therefore part of the OUI-space. From jlearman@cisco.com Wed Jul 3 22:35:18 2002 From: jlearman@cisco.com (Jeff Learman) Date: Wed, 03 Jul 2002 17:35:18 -0400 Subject: [Isis-wg] Proprietary / Private TLV numbers? In-Reply-To: <3D235C11.1070803@net4u.ch> References: <4103264BC8D3D51180B7002048400C454FB709@zhard0jd.europe.nortel.com> Message-ID: <4.3.2.7.2.20020703171759.03c78db0@dingdong.cisco.com> There are only 4 million OUIs, not 16. Two bits are reserved for "globally vs. locally assigned" and "multicast vs. unicast". Practically speaking, if you own an OUI, you own two values, one with the multicast bit clear and one with it set. HOWEVER, I wouldn't put it past IEEE to sell a special kind of OUIs that are NOT valid for use in making MAC addresses (because the local or mcast bit is set) so it is probably risky to use an OUI with this bit set for any other purpose. Use of an OUI with the locally-administered bit set is probably fine for use in a lab. However, you might want to ask IEEE before committing this to an RFC. When defining OUI you might want to include this URL: "http://standards.ieee.org". It's easy to find OUI from there, and I hope that this URL is stable enough to document. Jeff At 04:18 PM 7/3/2002, Tony Przygienda wrote: >Philip Christian wrote: > >>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? >you like 250? > >>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... >I looked at your draft and looks ok. Actually, MAC addresses have a 'local-valid-only' bit but I forgot whether it >was in OUI or not or maybe that's the bit you found. > >small comment on draft, pls find a reference to OUI description and include it. Many people don't know the >concept > > thanks > > -- tony > > > >_______________________________________________ >Isis-wg mailing list - Isis-wg@spider.juniper.net >http://spider.juniper.net/mailman/listinfo/isis-wg From jlearman@cisco.com Wed Jul 3 22:44:46 2002 From: jlearman@cisco.com (Jeff Learman) Date: Wed, 03 Jul 2002 17:44:46 -0400 Subject: [Isis-wg] Proprietary / Private TLV numbers? In-Reply-To: <3D235C11.1070803@net4u.ch> References: <4103264BC8D3D51180B7002048400C454FB709@zhard0jd.europe.nortel.com> Message-ID: <4.3.2.7.2.20020703174406.03c63988@dingdong.cisco.com> Have you updated the text since the round of comments after your post on 6/12? Jeff At 04:18 PM 7/3/2002, Tony Przygienda wrote: >I looked at your draft and looks ok. Actually, MAC addresses have a 'local-valid-only' bit but I forgot whether it >was in OUI or not or maybe that's the bit you found. > >small comment on draft, pls find a reference to OUI description and include it. Many people don't know the >concept > > thanks > > -- tony From naiming@redback.com Wed Jul 3 23:10:26 2002 From: naiming@redback.com (Naiming Shen) Date: Wed, 03 Jul 2002 15:10:26 -0700 Subject: [Isis-wg] Proprietary / Private TLV numbers? In-Reply-To: Mail from "Philip Christian" dated Tue, 11 Jun 2002 15:38:38 BST <4103264BC8D3D51180B7002048400C454FB70D@zhard0jd.europe.nortel.com> Message-ID: <20020703221026.AC1F01531C3@prattle.redback.com> Philip, is there a reason this TLV meant only for LSP packet, not for any isis pdus? i would think this optional TLV can be useful for other type of isis packets. thanks. ] ] First shot at a draft. Comments? ] ] Philip - Naiming From jparker@axiowave.com Wed Jul 3 23:10:52 2002 From: jparker@axiowave.com (Jeff Parker) Date: Wed, 3 Jul 2002 18:10:52 -0400 Subject: [Isis-wg] Proprietary / Private TLV numbers? Message-ID: Thanks to Jeff L's link, I wandered over an grabbed the file. Most of the entries start with 00. However, there are addresses with the second bit set. Here are a few... - jeff parker 02-07-01 (hex) RACAL-DATACOM 020701 (base 16) RACAL-DATACOM LAN INTERNETWORKING DIVISION 155 SWANSON ROAD BOXBOROUGH MA 01719 02-1C-7C (hex) PERQ SYSTEMS CORPORATION 021C7C (base 16) PERQ SYSTEMS CORPORATION 2600 LIBERTY AVENUE P.O. BOX 2600 PITTSBURGH PA 15230 02-60-86 (hex) LOGIC REPLACEMENT TECH. LTD. 026086 (base 16) LOGIC REPLACEMENT TECH. LTD. 14 ARKWRIGHT ROAD READING BERKS RG2OLS UNITED KINGDOM 02-60-8C (hex) 3COM CORPORATION 02608C (base 16) 3COM CORPORATION 2081 N. SHORLINE BLVD. MOUNTAIN VIEW CA 94043 - jeff parker - axiowave networks - My most important job is to defend the homeland, to protect innocent Americans from the deaths of the killers. - G. W. Bush > -----Original Message----- > From: Jeff Learman [mailto:jlearman@cisco.com] > Sent: Wednesday, July 03, 2002 5:35 PM > To: Tony Przygienda > Cc: Philip Christian; isis-wg@spider.juniper.net > Subject: Re: [Isis-wg] Proprietary / Private TLV numbers? > > > > There are only 4 million OUIs, not 16. Two bits are reserved > for "globally vs. locally assigned" and "multicast vs. unicast". > > Practically speaking, if you own an OUI, you own two values, one > with the multicast bit clear and one with it set. HOWEVER, I wouldn't > put it past IEEE to sell a special kind of OUIs that are NOT valid for > use in making MAC addresses (because the local or mcast bit > is set) so it is probably risky to use an OUI with this bit set for > any other purpose. > > Use of an OUI with the locally-administered bit set is probably > fine for use in a lab. However, you might want to ask IEEE before > committing this to an RFC. > > When defining OUI you might want to include this URL: > "http://standards.ieee.org". It's easy to find OUI from there, and > I hope that this URL is stable enough to document. > > Jeff > > At 04:18 PM 7/3/2002, Tony Przygienda wrote: > > > >Philip Christian wrote: > > > >>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? > >you like 250? > > > >>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... > >I looked at your draft and looks ok. Actually, MAC addresses > have a 'local-valid-only' bit but I forgot whether it > >was in OUI or not or maybe that's the bit you found. > > > >small comment on draft, pls find a reference to OUI > description and include it. Many people don't know the > >concept > > > > thanks > > > > -- tony > > > > > > > >_______________________________________________ > >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 prz@net4u.ch Wed Jul 3 23:16:29 2002 From: prz@net4u.ch (Tony Przygienda) Date: Wed, 03 Jul 2002 15:16:29 -0700 Subject: [Isis-wg] Proprietary / Private TLV numbers? References: Message-ID: <3D2377BD.2070909@net4u.ch> Jeff Parker wrote: >- axiowave networks >- My most important job is to defend the homeland, to protect innocent >Americans from the deaths of the killers. >- G. W. Bush > no politics, no drunks, no dirty jokes, pls, this is too close to the line Jeff Anybody appealing to the first or any other amendement will be unsubscribed! ;-) thanks -- tony From christi@nortelnetworks.com Wed Jul 3 23:32:59 2002 From: christi@nortelnetworks.com (Philip Christian) Date: Wed, 3 Jul 2002 23:32:59 +0100 Subject: [Isis-wg] Proprietary / Private TLV numbers? Message-ID: <4103264BC8D3D51180B7002048400C454FB744@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_01C222E1.94EF89AC Content-Type: text/plain; charset="iso-8859-1" I haven't yet, no. My boss (the wife) suddenly decided that I would be taking a week off work. I'm back now though and will have another go at it. Philip -----Original Message----- From: Jeff Learman [mailto:jlearman@cisco.com] Sent: Wednesday, July 03, 2002 10:45 PM To: Christian, Philip [HAL02:GI50:EXCH] Cc: isis-wg@spider.juniper.net Subject: Re: [Isis-wg] Proprietary / Private TLV numbers? Have you updated the text since the round of comments after your post on 6/12? Jeff At 04:18 PM 7/3/2002, Tony Przygienda wrote: >I looked at your draft and looks ok. Actually, MAC addresses have a 'local-valid-only' bit but I forgot whether it >was in OUI or not or maybe that's the bit you found. > >small comment on draft, pls find a reference to OUI description and include it. Many people don't know the >concept > > thanks > > -- tony ------_=_NextPart_001_01C222E1.94EF89AC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Isis-wg] Proprietary / Private TLV numbers?

I haven't yet, no.  My boss (the wife) suddenly = decided that I would be taking a week off work.
I'm back now though and will have another go at = it.

Philip

-----Original Message-----
From: Jeff Learman [mailto:jlearman@cisco.com]=
Sent: Wednesday, July 03, 2002 10:45 PM
To: Christian, Philip [HAL02:GI50:EXCH]
Cc: isis-wg@spider.juniper.net
Subject: Re: [Isis-wg] Proprietary / Private TLV = numbers?



Have you updated the text since the round of comments = after your
post on 6/12?

Jeff

At 04:18 PM 7/3/2002, Tony Przygienda wrote:
>I looked at your draft and looks ok. Actually, = MAC addresses have a 'local-valid-only' bit but I forgot whether = it
>was in OUI or not or maybe that's the bit you = found.
>
>small comment on draft, pls find a reference to = OUI description and include it. Many people don't know the
>concept
>
>   thanks
>
>   -- tony

------_=_NextPart_001_01C222E1.94EF89AC-- From christi@nortelnetworks.com Wed Jul 3 23:34:33 2002 From: christi@nortelnetworks.com (Philip Christian) Date: Wed, 3 Jul 2002 23:34:33 +0100 Subject: [Isis-wg] Proprietary / Private TLV numbers? Message-ID: <4103264BC8D3D51180B7002048400C454FB745@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_01C222E1.BBFED020 Content-Type: text/plain; charset="iso-8859-1" No reason in my mind. I can add it if no one objects. Philip -----Original Message----- From: Naiming Shen [mailto:naiming@redback.com] Sent: Wednesday, July 03, 2002 11:10 PM To: Christian, Philip [HAL02:GI50:EXCH] Cc: 'Tony Przygienda'; isis-wg@spider.juniper.net; 'Mike Truskowski'; mshand@cisco.com Subject: Re: [Isis-wg] Proprietary / Private TLV numbers? Philip, is there a reason this TLV meant only for LSP packet, not for any isis pdus? i would think this optional TLV can be useful for other type of isis packets. thanks. ] ] First shot at a draft. Comments? ] ] Philip - Naiming ------_=_NextPart_001_01C222E1.BBFED020 Content-Type: text/html; charset="iso-8859-1" RE: [Isis-wg] Proprietary / Private TLV numbers?

No reason in my mind.
I can add it if no one objects.

Philip

-----Original Message-----
From: Naiming Shen [mailto:naiming@redback.com]
Sent: Wednesday, July 03, 2002 11:10 PM
To: Christian, Philip [HAL02:GI50:EXCH]
Cc: 'Tony Przygienda'; isis-wg@spider.juniper.net; 'Mike Truskowski';
mshand@cisco.com
Subject: Re: [Isis-wg] Proprietary / Private TLV numbers?



Philip,
        is there a reason this TLV meant only for LSP packet, not
for any isis pdus? i would think this optional TLV can be useful
for other type of isis packets.

thanks.

 ]
 ] First shot at a draft.  Comments?
 ]
 ] Philip

- Naiming

------_=_NextPart_001_01C222E1.BBFED020-- From jlearman@cisco.com Wed Jul 3 23:53:22 2002 From: jlearman@cisco.com (Jeff Learman) Date: Wed, 03 Jul 2002 18:53:22 -0400 Subject: [Isis-wg] Proprietary / Private TLV numbers? In-Reply-To: <20020703221026.AC1F01531C3@prattle.redback.com> References: <4103264BC8D3D51180B7002048400C454FB70D@zhard0jd.europe.nortel.com> Message-ID: <4.3.2.7.2.20020703185251.03cace98@dingdong.cisco.com> Good point. It should be for all IS-IS PDUs. At 06:10 PM 7/3/2002, Naiming Shen wrote: >Philip, > is there a reason this TLV meant only for LSP packet, not >for any isis pdus? i would think this optional TLV can be useful >for other type of isis packets. > >thanks. > > ] > ] First shot at a draft. Comments? > ] > ] Philip > >- Naiming >_______________________________________________ >Isis-wg mailing list - Isis-wg@spider.juniper.net >http://spider.juniper.net/mailman/listinfo/isis-wg From jlearman@cisco.com Wed Jul 3 23:52:10 2002 From: jlearman@cisco.com (Jeff Learman) Date: Wed, 03 Jul 2002 18:52:10 -0400 Subject: [Isis-wg] Proprietary / Private TLV numbers? In-Reply-To: Message-ID: <4.3.2.7.2.20020703183112.01a719a8@dingdong.cisco.com> At 06:10 PM 7/3/2002, Jeff Parker wrote: >Thanks to Jeff L's link, I wandered over an grabbed the file. >Most of the entries start with 00. However, there are addresses >with the second bit set. Here are a few... Well I'll be ... Not to mention that some listed companies sure look like ones that might need to assign MAC addresses. IEEE's OUI request form doesn't ask you whether you'll use it for MAC addresses or for the other umpteen things OUIs are used for. I wonder if these are special assignments. Based on this info, I would suggest adding the following to the text. The OUI MUST NOT have the 7th bit of the first byte set in vendor implementations. This bit is ordinarily reserved in the OUI portion of MAC addresses to mean "locally administered", and is reserved for locally administered (experimental) values in this TLV, e.g., for academic purposes. Or something like that. Alternatively, if some saintly company is willing to donate an OUI, we could use that. For example, a company could donate that form of their OUI with the "multicast" bit set. (Note that none of the assignments has an odd first byte? I think this means that IEEE is willing to ignore the "local/global" meaning, but isn't silly enough to play the same game with "unicast/multicast"!) Jeff >- jeff parker > >02-07-01 (hex) RACAL-DATACOM >020701 (base 16) RACAL-DATACOM > LAN INTERNETWORKING DIVISION > 155 SWANSON ROAD > BOXBOROUGH MA 01719 > >02-1C-7C (hex) PERQ SYSTEMS CORPORATION >021C7C (base 16) PERQ SYSTEMS CORPORATION > 2600 LIBERTY AVENUE > P.O. BOX 2600 > PITTSBURGH PA 15230 > >02-60-86 (hex) LOGIC REPLACEMENT TECH. LTD. >026086 (base 16) LOGIC REPLACEMENT TECH. LTD. > 14 ARKWRIGHT ROAD > READING BERKS RG2OLS > UNITED KINGDOM > >02-60-8C (hex) 3COM CORPORATION >02608C (base 16) 3COM CORPORATION > 2081 N. SHORLINE BLVD. > MOUNTAIN VIEW CA 94043 > > >- jeff parker >- axiowave networks >- My most important job is to defend the homeland, to protect innocent >Americans from the deaths of the killers. >- G. W. Bush > > > >> -----Original Message----- >> From: Jeff Learman [mailto:jlearman@cisco.com] >> Sent: Wednesday, July 03, 2002 5:35 PM >> To: Tony Przygienda >> Cc: Philip Christian; isis-wg@spider.juniper.net >> Subject: Re: [Isis-wg] Proprietary / Private TLV numbers? >> >> >> >> There are only 4 million OUIs, not 16. Two bits are reserved >> for "globally vs. locally assigned" and "multicast vs. unicast". >> >> Practically speaking, if you own an OUI, you own two values, one >> with the multicast bit clear and one with it set. HOWEVER, I wouldn't >> put it past IEEE to sell a special kind of OUIs that are NOT valid for >> use in making MAC addresses (because the local or mcast bit >> is set) so it is probably risky to use an OUI with this bit set for >> any other purpose. >> >> Use of an OUI with the locally-administered bit set is probably >> fine for use in a lab. However, you might want to ask IEEE before >> committing this to an RFC. >> >> When defining OUI you might want to include this URL: >> "http://standards.ieee.org". It's easy to find OUI from there, and >> I hope that this URL is stable enough to document. >> >> Jeff >> >> At 04:18 PM 7/3/2002, Tony Przygienda wrote: >> >> >> >Philip Christian wrote: >> > >> >>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? >> >you like 250? >> > >> >>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... >> >I looked at your draft and looks ok. Actually, MAC addresses >> have a 'local-valid-only' bit but I forgot whether it >> >was in OUI or not or maybe that's the bit you found. >> > >> >small comment on draft, pls find a reference to OUI >> description and include it. Many people don't know the >> >concept >> > >> > thanks >> > >> > -- tony >> > >> > >> > >> >_______________________________________________ >> >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 jparker@axiowave.com Wed Jul 3 23:55:49 2002 From: jparker@axiowave.com (Jeff Parker) Date: Wed, 3 Jul 2002 18:55:49 -0400 Subject: [Isis-wg] Proprietary / Private TLV numbers? Message-ID: I must have too much time on my hands. I noticed a few dozen with bit 1 set, but there is even one with bit 0 set! 11-00-AA (hex) PRIVATE 1100AA (base 16) And the old DEC hands will remember these addresses - all with Philip's bit set. - jeff parker AA-00-00 (hex) DIGITAL EQUIPMENT CORPORATION AA0000 (base 16) DIGITAL EQUIPMENT CORPORATION LKG 1-2/A19 550 KING STREET LITTLETON MA 01460-1289 AA-00-01 (hex) DIGITAL EQUIPMENT CORPORATION AA0001 (base 16) DIGITAL EQUIPMENT CORPORATION LKG 1-2/A19 550 KING STREET LITTLETON MA 01460-1289 AA-00-02 (hex) DIGITAL EQUIPMENT CORPORATION AA0002 (base 16) DIGITAL EQUIPMENT CORPORATION LKG 1-2/A19 550 KING STREET LITTLETON MA 01460-1289 AA-00-03 (hex) DIGITAL EQUIPMENT CORPORATION AA0003 (base 16) DIGITAL EQUIPMENT CORPORATION LKG 1-2/A19 550 KING STREET LITTLETON MA 01460-1289 AA-00-04 (hex) DIGITAL EQUIPMENT CORPORATION AA0004 (base 16) DIGITAL EQUIPMENT CORPORATION LKG 1-2/A19 550 KING STREET LITTLETON MA 01460-1289 From Sivakumar A" --=_MAILER_ATTACH_BOUNDARY1_200274417385894429689 Content-Type: text/plain; charset=us-ascii Hello all, I require a small clarification regarding the other protocol learnt routes (RIP, OSPF etc) to be given to ISIS 1. Should ISIS summarise the external routes aquired from other protocols? 2. How should ISIS advertise the routes learn from other protocol? Is it External Route and External Metric or External Route and Internal Metric. Thanks and Regards Siva 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_200274417385894429689 Content-Type: text/html; charset=us-ascii

Hello all,

I require a small clarification regarding the other protocol learnt routes (RIP, OSPF etc) to be given to ISIS

1. Should ISIS summarise the external routes aquired from other protocols?

2. How should ISIS advertise the routes learn from other protocol? Is it External Route and External Metric or External Route and Internal Metric.

Thanks and Regards

Siva

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_200274417385894429689-- From Yongjun Im" This is a multi-part message in MIME format. ------=_NextPart_000_008C_01C223BE.64A1D100 Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="ks_c_5601-1987" RGVhciBJUy1JUyBFeHBlcnRzLA0KDQpBcyB5b3Uga25vdywgSVMtSVMgcGFja2V0cyBhcmUgZW5j YXBzdWxhdGVkIGRpcmVjdGx5IG92ZXIgTGF5ZXItMiBmcmFtZXMsDQppbmNsdWRpbmcgRXRoZXJu ZXQgZnJhbWUsIEFBTDUgUERVLCBQUFAgZnJhbWUuIEZpcnN0IG9mIGFsbCwgbGV0IG1lIGJyaWVm bHkgDQpkZXNjcmliZSB0aGUgTDIgaGVhZGVyIG9mIGVhY2ggZW5jYXBzdWxhdGlvbiBiZWxvdy4N Cg0KMS4gSVMtSVMgcGFja2V0IG92ZXIgRXRoZXJuZXQgZnJhbWUuDQogICAgICBEQSA9IDB4MDEt ODAtQzItMDAtMDAtMTQgKHJlc2VydmVkIE1BQyBhZGRyZXNzIG9mIElTSVMpDQogICAgICBTQSA9 IDB4WFgtWFgtWFgtWFgtWFgtWFgNCiAgICAgIExlbmd0aCA9IDB4WFgtWFgNCiAgICAgIERTQVAg PSAweEZFDQogICAgICBTU0FQID0gMHhGRQ0KICAgICAgQ29udHJvbCA9IDB4MDMNCiAgICAgIE5M UElEID0gMHg4Mw0KICAgICAgSVNJUyBQRFUgKHZhcmlhYmxlKQ0KICAgICAgRkNTDQoNCjIuIElT LUlTIHBhY2tldCBvdmVyIEFBTDUgUERVDQogICAgICBEU0FQID0gMHhGRQ0KICAgICAgU1NBUCA9 IDB4RkUNCiAgICAgIENvbnRyb2wgPSAweDAzDQogICAgICBOTFBJRCA9IDB4ODMNCiAgICAgIElT SVMgUERVICh2YXJpYWJsZSkNCiAgICAgIEFBTDUgVHJhaWxlciAoOCBieXRlcykNCg0KMy4gSVMt SVMgcGFja2V0IG92ZXIgUFBQL0hETEMNCiAgICAgIEZsYWcgPSAweDdFIChIRExDKQ0KICAgICAg QWRkcmVzcyA9IDB4RkYNCiAgICAgIENvbnRyb2wgPSAweDAzDQogICAgICBQcm90b2NvbCA9IDB4 MjMNCiAgICAgIE5MUElEID0gMHg4Mw0KICAgICAgSVNJUyBQRFUgKHZhcmlhYmxlKQ0KICAgICAg RkNTICg0Ynl0ZXMpDQogICAgICBGbGFnID0gMHg3RSAoSERMQykNCg0KSSB0aGluayBJJ20gcHJl dHR5IG11Y2ggc3VyZSByZWdhcmRpbmcgdGhlIEV0aGVybmV0IGFuZCBBQUw1IFBEVSBlbmNhcHN1 bGF0aW9uLCANCndoaWxlIEknbSB3b25kZXJpbmcgdGhlIFBQUC9IRExDIGVuY2Fwc3VsYXRpb24g c2luY2UgSSBjb3VsZG4ndCBmaW5kIA0KYW55IHN0YW5kYXJkIG9yIGltcGxlbWVudGF0aW9uIGRv Y3VtZW50YXRpb24gYWJvdXQgdGhhdC4gSSB3b3VsZCBncmVhdGx5IGFwcHJlY2lhdGUgDQppZiB5 b3UgY291bGQgdmVyaWZ5IHdoZXRoZXIgdGhlIFBQUC9IRExDIGVuY2Fwc3VsYXRpb24gYWJvdmUg aXMgY29ycmVjdC4NCg0KSW4gYWRkaXRpb24sIEkgd2FzIHRvbGQgdGhhdCBDaXNjbyB1c2VzIHRo ZSBwcm9wcmlldGFyeSBQUFAvSERMQyBpbXBsZW1lbnRhaW9uDQpmb3IgSVNJUyBwYWNrZXQgdGhh dCBpcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LjMuMSBvZiBSRkMgMTU0Ny4NCg0KW0V4Y2VwdCBm cm9tIFJGQyAxNTQ3XQ0KIlRoZSBDaXNjbyBTeXN0ZW1zIGdhdGV3YXkgc3VwcG9ydHMgYm90aCBh c3luY2hyb25vdXMgbGlua3MgdXNpbmcgU0xJUA0KICAgYW5kIHN5bmNocm9ub3VzIGxpbmtzIHVz aW5nIGVpdGhlciBzaW1wbGUgSERMQyBmcmFtaW5nLCBYLjI1IExBUEIgb3INCiAgIGZ1bGwgWC4y NS4gIFRoZSBIRExDIGZyYW1pbmcgcHJvY2VkdXJlIGluY2x1ZGVzIGEgZm91ciBieXRlIGhlYWRl ci4NCiAgIFRoZSBmaXJzdCBvY3RldCAoYWRkcmVzcykgaXMgZWl0aGVyIDB4MEYgKHVuaWNhc3Qg aW50ZW50KSBvciAweDhGDQogICAobXVsdGljYXN0IGludGVudCkuICBUaGUgc2Vjb25kIG9jdGV0 IChjb250cm9sIGJ5dGUpIGlzIGxlZnQgemVybyBhbmQNCiAgIGlzIG5vdCBjaGVja2VkIG9uIHJl Y2VwdGlvbi4gIFRoZSB0aGlyZCBhbmQgZm91cnRoIG9jdGV0cyBjb250YWluIGENCiAgIHN0YW5k YXJkIDE2IGJpdCBFdGhlcm5ldCBwcm90b2NvbCB0eXBlIGNvZGUuIg0KDQpJbiBhY2NvcmRhbmNl IHdpdGggdGhlIGRlc2NyaXB0aW9uIGFib3ZlLCBJIHRoaW5rIHRoZSBMMiBoZWFkZXIgZm9ybWF0 IG1pZ2h0IGJlIGFzIGZvbGxvd3M7DQoNCiAgICAgICBGbGFnID0gMHg3RSAoSERMQykNCiAgICAg ICBBZGRyZXNzID0gMHg4Rg0KICAgICAgIENvbnRyb2wgPSAweDAwDQogICAgICAgRFNBUCA9IDB4 RkUgDQogICAgICAgU1NBUCA9IDB4RkUNCiAgICAgICBDb250cm9sID0gMHgwMw0KICAgICAgIE5M UElEID0gMHg4Mw0KICAgICAgIElTSVMgUERVICh2YXJpYWJsZSkNCiAgICAgICBGQ1MgKDRieXRl cykNCiAgICAgICBGbGFnID0gMHg3RSAoSERMQykNCg0KSWYgdGhlIGVuY2Fwc3VsYXRpb24gSSBh c3N1bWVkIGFib3ZlIGlzIGNvcnJlY3QsIGlzIHRoYXQgcG9wdWxhciBvciBqdXN0DQpDaXNjbydz IHByb3ByaWV0YXJ5PyBXaGljaCBvbmUgaXMgdGhlIG1vc3QgdHlwaWNhbCBQUFAvSERMQyBlbmNh cHN1bGF0aW9uIA0KZm9yIElTSVMgcGFja2V0PyBXaGVuIHdlIG9wZXJhdGUgdGhlIElTLUlTIHBy b3RvY29sIG92ZXIgUG9TIGludGVyZmFjZSwgDQp3aGljaCBIRExDL1BQUCBlbmNhcHN1bGF0aW9u IGlzIHByZWZlcnJlZCBhbmQgd2hhdCBraW5kIG9mIGVuY2Fwc3VsYXRpb24NCm9wdGlvbnMgYXJl IGF2YWlsYWJsZT8gQW55IGludGVyb3BlcmFiaWx0eSBpc3N1ZXM/DQoNCkFueSByZXNwb25zZSBv ciBwb2ludGVyIHRvIHRoZSByZWxhdGVkIGRvY3VtZW50YXRpb24gd2lsbCBiZSBncmVhdGx5IGFw cHJlY2lhdGVkLiANCkVzcGVjaWFsbHkgSSB3b3VsZCBsaWtlIHRvIGdldCByZXBvbnNlIGZyb20g Q2lzY28gYW5kIEp1bmlwZXIgZW5naW5lZXJzLg0KDQpUYWtlIGNhcmUsDQoNCllvbmdqdW4uDQoN Cg0K ------=_NextPart_000_008C_01C223BE.64A1D100 Content-Transfer-Encoding: base64 Content-Type: text/html; charset="ks_c_5601-1987" PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI3MTYuMjIwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZPg0KPERJVj5EZWFyIElTLUlTIEV4cGVydHMsPEJSPjxCUj5BcyB5b3Uga25v dywgSVMtSVMgcGFja2V0cyBhcmUgZW5jYXBzdWxhdGVkIA0KZGlyZWN0bHkgb3ZlciBMYXllci0y IGZyYW1lcyw8QlI+aW5jbHVkaW5nIEV0aGVybmV0IGZyYW1lLCBBQUw1IFBEVSwgUFBQIGZyYW1l LiANCkZpcnN0IG9mIGFsbCwgbGV0IG1lIGJyaWVmbHkgPEJSPmRlc2NyaWJlIHRoZSBMMiBoZWFk ZXIgb2YgZWFjaCBlbmNhcHN1bGF0aW9uIA0KYmVsb3cuPEJSPjxCUj4xLiBJUy1JUyBwYWNrZXQg b3ZlciBFdGhlcm5ldCANCmZyYW1lLjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg REEgPSAweDAxLTgwLUMyLTAwLTAwLTE0IChyZXNlcnZlZCBNQUMgDQphZGRyZXNzIG9mIElTSVMp PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTQSA9IA0KMHhYWC1YWC1YWC1YWC1Y WC1YWDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTGVuZ3RoID0gDQoweFhYLVhY PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBEU0FQID0gDQoweEZFPEJSPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTU0FQID0gDQoweEZFPEJSPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBDb250cm9sID0gDQoweDAzPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBOTFBJRCA9IA0KMHg4MzxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgSVNJUyBQRFUgDQoodmFyaWFibGUpPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBGQ1M8QlI+PEJSPjIuIElTLUlTIHBhY2tldCBvdmVyIA0KQUFMNSBQRFU8QlI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IERTQVAgPSANCjB4RkU8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IFNTQVAgPSANCjB4RkU8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IENvbnRyb2wgPSANCjB4MDM8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5M UElEID0gDQoweDgzPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJU0lTIFBEVSAN Cih2YXJpYWJsZSk8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFBTDUgVHJhaWxl ciAoOCBieXRlcyk8QlI+PEJSPjMuIA0KSVMtSVMgcGFja2V0IG92ZXIgUFBQL0hETEM8QlI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZsYWcgPSAweDdFIA0KKEhETEMpPEJSPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBZGRyZXNzID0gDQoweEZGPEJSPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBDb250cm9sID0gDQoweDAzPEJSPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBQcm90b2NvbCA9IA0KMHgyMzxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgTkxQSUQgPSANCjB4ODM8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IElTSVMgUERVIA0KKHZhcmlhYmxlKTxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg RkNTIA0KKDRieXRlcyk8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZsYWcgPSAw eDdFIChIRExDKTxCUj48QlI+SSB0aGluayBJJ20gDQpwcmV0dHkgbXVjaCBzdXJlIHJlZ2FyZGlu ZyB0aGUgRXRoZXJuZXQgYW5kIEFBTDUgUERVIGVuY2Fwc3VsYXRpb24sIDxCUj53aGlsZSANCkkn bSB3b25kZXJpbmcgdGhlIFBQUC9IRExDIGVuY2Fwc3VsYXRpb24gc2luY2UgSSBjb3VsZG4ndCBm aW5kIDxCUj5hbnkgc3RhbmRhcmQgDQpvciBpbXBsZW1lbnRhdGlvbiBkb2N1bWVudGF0aW9uIGFi b3V0IHRoYXQuIEkgd291bGQgZ3JlYXRseSBhcHByZWNpYXRlIDxCUj5pZiANCnlvdSBjb3VsZCB2 ZXJpZnkgd2hldGhlciB0aGUgUFBQL0hETEMgZW5jYXBzdWxhdGlvbiBhYm92ZSBpcyBjb3JyZWN0 LjxCUj48QlI+SW4gDQphZGRpdGlvbiwgSSB3YXMgdG9sZCB0aGF0IENpc2NvIHVzZXMgdGhlIHBy b3ByaWV0YXJ5IFBQUC9IRExDIA0KaW1wbGVtZW50YWlvbjxCUj5mb3IgSVNJUyBwYWNrZXQgdGhh dCBpcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LjMuMSBvZiBSRkMgDQoxNTQ3LjxCUj48QlI+W0V4 Y2VwdCBmcm9tIFJGQyAxNTQ3XTxCUj4iVGhlIENpc2NvIFN5c3RlbXMgZ2F0ZXdheSBzdXBwb3J0 cyBib3RoIA0KYXN5bmNocm9ub3VzIGxpbmtzIHVzaW5nIFNMSVA8QlI+Jm5ic3A7Jm5ic3A7IGFu ZCBzeW5jaHJvbm91cyBsaW5rcyB1c2luZyBlaXRoZXIgDQpzaW1wbGUgSERMQyBmcmFtaW5nLCBY LjI1IExBUEIgb3I8QlI+Jm5ic3A7Jm5ic3A7IGZ1bGwgWC4yNS4mbmJzcDsgVGhlIEhETEMgDQpm cmFtaW5nIHByb2NlZHVyZSBpbmNsdWRlcyBhIGZvdXIgYnl0ZSBoZWFkZXIuPEJSPiZuYnNwOyZu YnNwOyBUaGUgZmlyc3Qgb2N0ZXQgDQooYWRkcmVzcykgaXMgZWl0aGVyIDB4MEYgKHVuaWNhc3Qg aW50ZW50KSBvciAweDhGPEJSPiZuYnNwOyZuYnNwOyAobXVsdGljYXN0IA0KaW50ZW50KS4mbmJz cDsgVGhlIHNlY29uZCBvY3RldCAoY29udHJvbCBieXRlKSBpcyBsZWZ0IHplcm8gYW5kPEJSPiZu YnNwOyZuYnNwOyANCmlzIG5vdCBjaGVja2VkIG9uIHJlY2VwdGlvbi4mbmJzcDsgVGhlIHRoaXJk IGFuZCBmb3VydGggb2N0ZXRzIGNvbnRhaW4gDQphPEJSPiZuYnNwOyZuYnNwOyBzdGFuZGFyZCAx NiBiaXQgRXRoZXJuZXQgcHJvdG9jb2wgdHlwZSBjb2RlLiI8QlI+PEJSPkluIA0KYWNjb3JkYW5j ZSB3aXRoIHRoZSBkZXNjcmlwdGlvbiBhYm92ZSwgSSB0aGluayB0aGUgTDIgaGVhZGVyIGZvcm1h dCBtaWdodCBiZSBhcyANCmZvbGxvd3M7PEJSPjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgRmxhZyA9IDB4N0UgDQooSERMQyk8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IEFkZHJlc3MgPSANCjB4OEY8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IENvbnRyb2wgPSANCjB4MDA8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IERTQVAgPSAweEZFIA0KPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBTU0FQID0gDQoweEZFPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBDb250cm9sID0gDQoweDAzPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBOTFBJRCA9IA0KMHg4MzxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgSVNJUyBQRFUgDQoodmFyaWFibGUpPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBGQ1MgDQooNGJ5dGVzKTxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgRmxhZyA9IDB4N0UgKEhETEMpPEJSPjxCUj5JZiANCnRoZSBlbmNhcHN1bGF0 aW9uIEkgYXNzdW1lZCBhYm92ZSBpcyBjb3JyZWN0LCBpcyB0aGF0IHBvcHVsYXIgb3IganVzdDxC Uj5DaXNjbydzIA0KcHJvcHJpZXRhcnk/IFdoaWNoIG9uZSBpcyB0aGUgbW9zdCB0eXBpY2FsIFBQ UC9IRExDIGVuY2Fwc3VsYXRpb24gPEJSPmZvciBJU0lTIA0KcGFja2V0PyBXaGVuIHdlIG9wZXJh dGUgdGhlIElTLUlTIHByb3RvY29sIG92ZXIgUG9TIGludGVyZmFjZSwgPEJSPndoaWNoIA0KSERM Qy9QUFAgZW5jYXBzdWxhdGlvbiBpcyBwcmVmZXJyZWQgYW5kIHdoYXQga2luZCBvZiBlbmNhcHN1 bGF0aW9uPEJSPm9wdGlvbnMgDQphcmUgYXZhaWxhYmxlPyBBbnkgaW50ZXJvcGVyYWJpbHR5IGlz c3Vlcz88QlI+PEJSPkFueSByZXNwb25zZSBvciBwb2ludGVyIHRvIHRoZSANCnJlbGF0ZWQgZG9j dW1lbnRhdGlvbiB3aWxsIGJlIGdyZWF0bHkgYXBwcmVjaWF0ZWQuIDxCUj5Fc3BlY2lhbGx5IEkg d291bGQgbGlrZSANCnRvIGdldCByZXBvbnNlIGZyb20gQ2lzY28gYW5kIEp1bmlwZXIgZW5naW5l ZXJzLjxCUj48QlI+VGFrZSANCmNhcmUsPEJSPjxCUj5Zb25nanVuLjxCUj48QlI+PC9ESVY+PC9C T0RZPjwvSFRNTD4NCg== ------=_NextPart_000_008C_01C223BE.64A1D100-- From james.d.carlson@east.sun.com Thu Jul 4 20:37:09 2002 From: james.d.carlson@east.sun.com (James Carlson) Date: Thu, 4 Jul 2002 15:37:09 -0400 Subject: [Isis-wg] PPP/HDLC encapsulation for IS-IS packet In-Reply-To: Yongjun Im's message of 5 July 2002 00:53:35 References: <008f01c22372$f50059c0$3b8c9696@lge.com> Message-ID: <15652.41957.190988.397909@gargle.gargle.HOWL> Yongjun Im writes: > 3. IS-IS packet over PPP/HDLC > Flag = 0x7E (HDLC) The flag isn't actually part of the frame, any more than the escape characters ("byte stuffing") or bit-stuffing. On most hardware implementations, you will not see this byte at all. > Address = 0xFF > Control = 0x03 The HDLC Address and Control fields can be negotiated away by LCP. See RFC 1661. > Protocol = 0x23 The protocol field is two octets by default, but can be negotiated down to one octet by LCP for protocols (such as OSI) that are in the range 0000-00FF. > NLPID = 0x83 Note that RFC 1377 allows padding before the NLPID. > ISIS PDU (variable) > FCS (4bytes) The default PPP FCS on most media is 2 octets, not 4. It's 4 on a few high-speed links. See RFC 2615. > Flag = 0x7E (HDLC) Same as above. Note that HDLC frames don't really require a starting and ending flag -- merely one flag between adjacent frames. > 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. RFCs 1377, 1661, and 1662 should cover it. > I would greatly appreciate > if you could verify whether the PPP/HDLC encapsulation above is correct. Pretty close, minus the LCP negotiation bits. > 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." That's not PPP -- that's Cisco HDLC. The two are not the same at all. > In accordance with the description above, I think the L2 header format might be as follows; That looks roughly correct, but if you don't have a Cisco router handy to verify this and do the obvious interoperability testing, does it matter? > 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? There's only one PPP. That protocol you're referring to isn't PPP. > 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? I'd prefer PPP, because it's widely available and interoperable. > Please do what you can to disable HTML in your outbound email ... -- James Carlson, Solaris Networking SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From christi@nortelnetworks.com Thu Jul 4 22:27:59 2002 From: christi@nortelnetworks.com (Philip Christian) Date: Thu, 4 Jul 2002 22:27:59 +0100 Subject: [Isis-wg] draft-ietf-isis-private-tlv Message-ID: <4103264BC8D3D51180B7002048400C454FB74E@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_01C223A1.AB292F28 Content-Type: text/plain; charset="iso-8859-1" Here is my latest attempt at proprietary TLV. Sorry if I have missed anyones ideas/comments, my inbox is a mess. I cannot submit it as an Internet Draft until the 15th. Philip Internet Engineering Task Force P. Christian, INTERNET DRAFT Nortel Networks July 2002 TLV for Proprietary Use draft-ietf-isis-private-tlv-forlist3.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. Christian Expires January 2003 1 TLV for Proprietary Use July 2002 3. Introduction TLVs are extensions to IS-IS packets (PDUs). When added to IS-IS LSPs they are flooded throughout an IS-IS level-1 area or level-2 subdomain, and when added to IS-IS Hello PDUs they are are present only on a specific interface of an IS-IS router. The structure of IS-IS TLVs is defined in ISO 10589 [1]. 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. No TLV type number has ever been 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. Such use also accelerates the consumption 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 250. TLVs that use 250 for the type field MUST include a valid IEEE assigned OUI as the first three bytes of the value field of the TLV. OUIs are three byte unique numbers that may be purchased from the IEEE and which are used for several purposes. Typically the first three bytes of a MAC address are an OUI for example. By buying an an OUI a vendor has effectively bought a block of sixteen million MAC addresses, and so most vendors already have an OUI that may also be used for proprietary TLVs as per this document. For more information about OUIs see [3]. Christian Expires January 2003 2 TLV for Proprietary Use July 2002 The OUI MUST NOT have the 7th bit of the first byte set in vendor implementations. This bit is ordinarily reserved in the OUI portion of MAC addresses to mean "locally administered", and is reserved for locally administered (experimental) values in this TLV, e.g., for academic purposes. The TLV of type 250 may be used in IS-IS LSP, IIH, ISH or SNP PDUs. On receipt of an IS-IS PDU a router MUST ignore TLVs of type 250 that include an OUI that is not recognised, however the router MUST flood LSPs onwards as per [1] even if they include unrecognised proprietary TLVs. 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]. Organisations will have access only to a finite number of OUIs. The IEEE reserves the right to not assign more OUIs to organisations that already have them. For more information see [3]. Therefore implementors would be well advised to think about defining a format whereby one OUI can be used for multiple types of proprietary TLV. 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 and all subsequent implementations that use that OUI 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. IS-IS DPUs will normally be limited to an operators routing domain, and so information placed in a proprietary TLV will not normally be visible outside of an operator's network. However IS-IS PDUs are not encrypted, and so if a link over which an adjacency is maintained is not secure, then any information contained in an IS-IS PDU, including a proprietary TLV is not secure either. 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 Christian Expires January 2003 3 TLV for Proprietary Use July 2002 [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 Christian Expires January 2003 4 ------_=_NextPart_001_01C223A1.AB292F28 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft-ietf-isis-private-tlv

Here is my latest attempt at proprietary TLV.
Sorry if I have missed anyones ideas/comments, my = inbox is a mess.
I cannot submit it as an Internet Draft until the = 15th.

Philip


Internet Engineering Task = Force           &= nbsp;           &= nbsp;   P. Christian,
INTERNET = DRAFT           &= nbsp;           &= nbsp;           &= nbsp;      Nortel Networks
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;   July 2002
 
 
          &nb= sp;           &nb= sp;   TLV for Proprietary Use
          &nb= sp;          = draft-ietf-isis-private-tlv-forlist3.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.
   







Christian         =        Expires January = 2003           &n= bsp;           &n= bsp; 1
          &nb= sp;            = TLV for Proprietary = Use           &nb= sp;    July 2002
 
3. Introduction
   
   TLVs are extensions to IS-IS packets = (PDUs).  When added to IS-IS
   LSPs they are flooded throughout an = IS-IS level-1 area or level-2
   subdomain, and when added to IS-IS = Hello PDUs they are are present
   only on a specific interface of an = IS-IS router.

   The structure of IS-IS TLVs is defined = in ISO 10589 [1].
   
   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.  No = TLV type number has ever been
   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.  Such = use also accelerates the consumption
   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 = 250.
   
   TLVs that use 250 for the type field = MUST include a valid IEEE
   assigned OUI as the first three bytes = of the value field of the TLV.

   OUIs are three byte unique numbers that = may be purchased from the
   IEEE and which are used for several = purposes.  Typically the first
   three bytes of a MAC address are an OUI = for example.  By buying an
   an OUI a vendor has effectively bought = a block of sixteen million
   MAC addresses, and so most vendors = already have an OUI that may
   also be used for proprietary TLVs as = per this document.

   For more information about OUIs see [3]. =
  

Christian         =        Expires January = 2003           &n= bsp;           &n= bsp; 2
          &nb= sp;            = TLV for Proprietary = Use           &nb= sp;    July 2002

   The OUI MUST NOT have the 7th bit of the = first byte set in vendor
   implementations.  This bit is = ordinarily reserved in the OUI portion
   of MAC addresses to mean "locally = administered", and is reserved for
   locally administered (experimental) = values in this TLV, e.g., for
   academic purposes.
 
   The TLV of type 250 may be used in = IS-IS LSP, IIH, ISH or SNP PDUs.

   On receipt of an IS-IS PDU a router MUST = ignore TLVs of type 250
   that include an OUI that is not = recognised, however the router MUST
   flood LSPs onwards as per [1] even if = they include unrecognised
   proprietary TLVs.
 
   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].
   
   Organisations will have access only to = a finite number of OUIs. The
   IEEE reserves the right to not assign = more OUIs to organisations
   that already have them.  For more = information see [3].  Therefore
   implementors would be well advised to = think about defining a
   format whereby one OUI can be used for = multiple types of
   proprietary TLV.

   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 and all = subsequent implementations
   that use that OUI 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. 

   IS-IS DPUs will normally be limited to = an operators routing domain,
   and so information placed in a = proprietary TLV will not normally be
   visible outside of an operator's = network.

   However IS-IS PDUs are not encrypted, = and so if a link over which
   an adjacency is maintained is not = secure, then any information
   contained in an IS-IS PDU, including a = proprietary TLV is not
   secure either.
   
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
    
Christian         =        Expires January = 2003           &n= bsp;           &n= bsp; 3
          &nb= sp;            = TLV for Proprietary = Use           &nb= sp;    July 2002

   [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 =






































Christian         =        Expires January = 2003           &n= bsp;           &n= bsp; 4

------_=_NextPart_001_01C223A1.AB292F28-- From Internet-Drafts@ietf.org Fri Jul 5 11:33:45 2002 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Fri, 05 Jul 2002 06:33:45 -0400 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-multi-topology-04.txt Message-ID: <200207051033.GAA17001@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 : M-ISIS: Multi Topology (MT)Routing in IS-IS Author(s) : T. Przygienda, N. Shen, N. Sheth Filename : draft-ietf-isis-wg-multi-topology-04.txt Pages : 10 Date : 03-Jul-02 This draft describes an optional mechanism within ISIS used today by many ISPs for IGP routing within their clouds. This draft describes how to run within a single ISIS domain a set of independent IP topologies that we call Multi-Topologies (MTs). This MT extension can be used for variety of purposes such as an in-band management network ``on top'' of the original IGP topology, maintain separate IGP routing domains for isolated multicast or IPv6 islands within the backbone, or force a subset of an address space to follow a different topology. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-multi-topology-04.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-wg-multi-topology-04.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-wg-multi-topology-04.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: <20020703131758.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-wg-multi-topology-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-wg-multi-topology-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020703131758.I-D@ietf.org> --OtherAccess-- --NextPart-- From christi@nortelnetworks.com Tue Jul 9 00:00:31 2002 From: christi@nortelnetworks.com (Philip Christian) Date: Tue, 9 Jul 2002 00:00:31 +0100 Subject: [Isis-wg] draft-ietf-isis-auto-encap-00.txt Message-ID: <4103264BC8D3D51180B7002048400C454FB759@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_01C226D3.3C1D7A78 Content-Type: text/plain; charset="iso-8859-1" I have been trying to find a way to get this doc to everyone. The IETF are not accepting drafts until the 15th, and the list server won't accept the draft inline or as an attachment because it is too big. Anyway. I will be submitting this on the 15th as a working group item. In the meantime if anyone wants to read it then they can go get it from ftp://ftp-uk.nortelnetworks.com/drop/isiswg/draft-ietf-isis-auto-encap-00.tx t Please see the comments below and enjoy. Philip -----Original Message----- From: Christian, Philip [HAL02:GI50:EXCH] Sent: Monday, July 08, 2002 5:49 PM To: 'isis-wg@spider.juniper.net' Subject: draft-ietf-isis-auto-encap-00.txt You will all no doubt remember the ITU-T DCN document that the ITU-T liaised to this working group some months ago, and the automatic encapsulation feature that appeared in Annex B of that doc. The ITU-T also asked me to write an Internet Draft on the subject, which I have now done. This text belongs to this working group and is copyright Internet Society. It is not an ITU-T document. I attempted to submit this as a draft last week, but forgot that drafts cannot be submitted at this time. I will be submitting it on the 15th instead. I'm sure that there will be plenty of useful comments, but I am thinking that it would be better still to submit this as is, and then incorporate comments into an 01 version later. I wouldn't want to cause confusion by having two docs with the same number floating around. I see no reason to keep you guys waiting, and so I am sending it to the list now (again, it bounced the last time). It needs to be viewed in courier font to see the diagrams. Enjoy Philip ------_=_NextPart_001_01C226D3.3C1D7A78 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft-ietf-isis-auto-encap-00.txt

I have been trying to find a way to get this doc to = everyone.
The IETF are not accepting drafts until the 15th, = and the list
server won't accept the draft inline or as an = attachment because
it is too big.

Anyway.  I will be submitting this on the 15th = as a working group
item.  In the meantime if anyone wants to read = it then they can
go get it from
ftp://ftp-uk.nortelnetworks.com/drop/isiswg/draft-ietf= -isis-auto-encap-00.txt

Please see the comments below and enjoy.

Philip

-----Original Message-----
From: Christian, Philip [HAL02:GI50:EXCH]
Sent: Monday, July 08, 2002 5:49 PM
To: 'isis-wg@spider.juniper.net'
Subject: draft-ietf-isis-auto-encap-00.txt


You will all no doubt remember the ITU-T DCN document = that the
ITU-T liaised to this working group some months ago, = and the
automatic encapsulation feature that appeared in = Annex B of that doc.

The ITU-T also asked me to write an Internet Draft on = the subject,
which I have now done.

This text belongs to this working group and is = copyright Internet
Society.  It is not an ITU-T document.

I attempted to submit this as a draft last week, but = forgot that
drafts cannot be submitted at this time.  I = will be submitting
it on the 15th instead.

I'm sure that there will be plenty of useful = comments, but I am
thinking that it would be better still to submit = this as is, and
then incorporate comments into an 01 version later. = I wouldn't want
to cause confusion by having two docs with the same = number floating
around.

I see no reason to keep you guys waiting, and so I am = sending it to
the list now (again, it bounced the last = time).

It needs to be viewed in courier font to see the = diagrams.

Enjoy

Philip

------_=_NextPart_001_01C226D3.3C1D7A78-- From christi@nortelnetworks.com Tue Jul 9 00:25:12 2002 From: christi@nortelnetworks.com (Philip Christian) Date: Tue, 9 Jul 2002 00:25:12 +0100 Subject: [Isis-wg] what no RFCs ? Message-ID: <4103264BC8D3D51180B7002048400C454FB75B@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_01C226D6.63710204 Content-Type: text/plain; charset="iso-8859-1" I just went to http://www.ietf.org/html.charters/isis-wg-charter.html and it says "No Request For Comments" I think that it has been that way for a few days now. wierd Philip ------_=_NextPart_001_01C226D6.63710204 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable what no RFCs ?

I just went to
http://www.ietf.org/html.charters/isis-wg-charter.html=
and it says "No Request For = Comments"
I think that it has been that way for a few days = now.

wierd

Philip

------_=_NextPart_001_01C226D6.63710204-- From naiming@redback.com Tue Jul 9 01:20:41 2002 From: naiming@redback.com (Naiming Shen) Date: Mon, 08 Jul 2002 17:20:41 -0700 Subject: [Isis-wg] Internet-Drafts@ietf.org: I-D ACTION:draft-shen-isis-iih-sequence-00.txt Message-ID: <20020709002041.56C0FCAB7C@prattle.redback.com> resend to this list, it didn't come out last time I tried. pls comment. thanks. - Naiming ------- Forwarded Message 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 - --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 naiming@redback.com Tue Jul 9 01:25:40 2002 From: naiming@redback.com (Naiming Shen) Date: Mon, 08 Jul 2002 17:25:40 -0700 Subject: Internet-Drafts@ietf.org: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-multi-topology-04.txt Message-ID: <20020709002540.A83401DCC76@prattle.redback.com> this is the latest version of m-isis draft. the main change is introducing the Generic MT SPF concept for network management purposes. pls comment. thanks. - Naiming ------- Forwarded Message From: Internet-Drafts@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-multi-topology-04.txt Date: Fri, 05 Jul 2002 06:33:45 -0400 - --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 : M-ISIS: Multi Topology (MT)Routing in IS-IS Author(s) : T. Przygienda, N. Shen, N. Sheth Filename : draft-ietf-isis-wg-multi-topology-04.txt Pages : 10 Date : 03-Jul-02 This draft describes an optional mechanism within ISIS used today by many ISPs for IGP routing within their clouds. This draft describes how to run within a single ISIS domain a set of independent IP topologies that we call Multi-Topologies (MTs). This MT extension can be used for variety of purposes such as an in-band management network ``on top'' of the original IGP topology, maintain separate IGP routing domains for isolated multicast or IPv6 islands within the backbone, or force a subset of an address space to follow a different topology. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-multi-topology-04.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-wg-multi-topology-04.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-wg-multi-topology-04.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: <20020703131758.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-wg-multi-topology-04.txt - --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-wg-multi-topology-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020703131758.I-D@ietf.org> - --OtherAccess-- - --NextPart-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg ------- End of Forwarded Message From swaminathanr@netplane.com Tue Jul 9 05:43:42 2002 From: swaminathanr@netplane.com (Ramalingam, Swaminathan) Date: Tue, 9 Jul 2002 00:43:42 -0400 Subject: [Isis-wg] ISIS MIB: Circuit & Level Table Message-ID: Hi Jeff, Following are the doubts i encounter when i gone through ISIS MIB Ver 8 1. isisCircLocalID, as specified in Overview, is not moved to ISIS circuit Level table which is still in the Circuit table. I understand it has to be moved. 2. If Local Ckt ID is level specific (isisCircLocalID), PTP ckt ID (isisCircPtToPtCircID) will be level specific, which is still in Circuit Table. 3. Hello Timer in Circuit Level Table Description reads like: "Maximum period, in milliseconds, between IIH PDUs on multiaccess networks at this level for LANs. The value at level 1 is used as the period between Hellos on point to point circuits. Setting this value at level 2 on a point to point circuit will result in an error of InconsistentValue" But if the system is L2 Only, it is more appropriate to get from L2. I suggest description can be changed as , when the level is L1L2, then setting at L2 may result in Inconsistent Value. Thanks, Swami From iesg-secretary@ietf.org Tue Jul 9 13:27:28 2002 From: iesg-secretary@ietf.org (The IESG) Date: Tue, 09 Jul 2002 08:27:28 -0400 Subject: [Isis-wg] Document Action: Three-Way Handshake for IS-IS Point-to-Point Adjacencies to Informational Message-ID: <200207091227.IAA21811@ietf.org> The IESG has approved the Internet-Draft 'Three-Way Handshake for IS-IS Point-to-Point Adjacencies' as an Informational RFC. This document is the product of the IS-IS for IP Internets Working Group. The IESG contact persons are Alex Zinin and Bill Fenner. Technical Summary The document introduces a backward-compatible extension to the IS-IS routing protocol that ensures two-way connectivity on point-to-point links through a three-way handshaking mechanism. The document also extends the protocol to support more than 256 point-to-point links per router. Working Group Summary There was support for this document in the WG. All comments brought up during the WG Last Call have been addressed. Protocol Quality Alex Zinin has reviewed the specification for the IESG. The mechanisms described in the document have been implemented by multiple router vendors and have been widely deployed in the Internet. From jparker@axiowave.com Tue Jul 9 16:03:13 2002 From: jparker@axiowave.com (Jeff Parker) Date: Tue, 9 Jul 2002 11:03:13 -0400 Subject: [Isis-wg] RE: ISIS MIB: Circuit & Level Table Message-ID: > Hi Jeff, > > Following are the doubts i encounter when i gone through ISIS > MIB Ver 8 I am sending you the current version 9 by private mail. > 1. isisCircLocalID, as specified in Overview, is not moved to > ISIS circuit > Level table which is still in the Circuit table. I understand > it has to be > moved. > > 2. If Local Ckt ID is level specific (isisCircLocalID), PTP ckt ID > (isisCircPtToPtCircID) will be level specific, which is still > in Circuit > Table. I have deleted isisCircPtToPtCircID and resurected isisCircLevelLocalID > 3. Hello Timer in Circuit Level Table Description reads like: > "Maximum period, in milliseconds, between IIH PDUs on > multiaccess > networks at this level for LANs. > The value at level 1 is used as the period between Hellos on > point to point > circuits. Setting this value > at level 2 on a point to point circuit will result in an error of > InconsistentValue" > But if the system is L2 Only, it is more appropriate to get > from L2. I > suggest description can be changed as , when the level is > L1L2, then setting > at L2 may result in Inconsistent Value. > Thanks, > Swami Handling levels in P2P is a torment. I have considered adding a circuit specific timer to avoid this. I suspect you are right, as this would force the creation of a circ level at the wrong level. New text reads "Maximum period, in milliseconds, between IIH PDUs on multiaccess networks at this level for LANs. The value at level 1 is used as the period between Hellos on L1L2 point to point circuits. Setting this value at level 2 on an L1L2 point to point circuit will result in an error of InconsistentValue. This object follows the resettingTimer behavior." - jeff parker From prz@net4u.ch Tue Jul 9 19:23:07 2002 From: prz@net4u.ch (Tony Przygienda) Date: Tue, 09 Jul 2002 11:23:07 -0700 Subject: [Isis-wg] last call on draft-ietf-isis-wg-multi-topology-04 ... Message-ID: <3D2B2A0B.2080101@net4u.ch> Since multi-topology draft underwent non-trivial revisions during the last call, we are reinitiating last call on draft-ietf-isis-wg-multi-topology-04. The last call will end 7/25/02 thanks -- tony From prz@net4u.ch Tue Jul 9 21:27:04 2002 From: prz@net4u.ch (Tony Przygienda) Date: Tue, 09 Jul 2002 13:27:04 -0700 Subject: [Isis-wg] Important: moving the list ... Message-ID: <3D2B4718.7010702@net4u.ch> L&G, we will be moving the mailing list from isis-wg@juniper.net to isis-wg@ietf.org. Please mail to the new list, the old one should be operational for a couple of days from now but no guarantees are being made. All of the isis-wg people should have been mass-subscribed by now to the new list. Archives will be moved over in a short while. Thanks to couple of people forcing the issue and the friendly IETF stuff for making it happen. Thanks to Juniper of course for bearing the list for so long thanks --- tony From jparker@axiowave.com Thu Jul 11 15:25:27 2002 From: jparker@axiowave.com (Jeff Parker) Date: Thu, 11 Jul 2002 10:25:27 -0400 Subject: [Isis-wg] Proprietary / Private TLV numbers? Message-ID: Philip - Private mail. I think Ran's final point is actually quite helpful. I'd be happy to review a new version of this, or to suggest one, if you drop me a line the next three hours. (I'm headed on vacation) - jeff parker > 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. > > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg > From jlearman@cisco.com Thu Jul 11 16:22:13 2002 From: jlearman@cisco.com (Jeff Learman) Date: Thu, 11 Jul 2002 11:22:13 -0400 Subject: [Isis-wg] Proprietary / Private TLV numbers? In-Reply-To: <213ACF92-7F10-11D6-B00E-00039357A82A@extremenetworks.com> References: <4103264BC8D3D51180B7002048400C454FB710@zhard0jd.europe.nortel.com> Message-ID: <4.3.2.7.2.20020711111635.01ec1e50@dingdong.cisco.com> At 04:57 PM 6/13/2002, RJ Atkinson wrote: >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. That would be using it incorrectly. Only one authority can define the syntax and semantics for a given OID. If an implementation misinterprets this information, that implementation is broken. I agree with Philip that no NEW security issues arise from this RFC. However, security issues may arise from a particular USE of this feature. It is up to the designers of USES of this feature to address any security issues that are raised by that application. Regards, Jeff > 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. > >_______________________________________________ >Isis-wg mailing list - Isis-wg@spider.juniper.net >http://spider.juniper.net/mailman/listinfo/isis-wg From jlearman@cisco.com Thu Jul 11 16:24:55 2002 From: jlearman@cisco.com (Jeff Learman) Date: Thu, 11 Jul 2002 11:24:55 -0400 Subject: [Isis-wg] Proprietary / Private TLV numbers? In-Reply-To: <4.3.2.7.2.20020611154537.025ce140@jaws.cisco.com> References: <4103264BC8D3D51180B7002048400C454FB70D@zhard0jd.europe.nor tel.com> Message-ID: <4.3.2.7.2.20020711112227.01ee3ee8@dingdong.cisco.com> --=====================_10685274==_.ALT Content-Type: text/plain; charset="us-ascii" At 10:55 AM 6/11/2002, mike shand wrote: >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, I pointed this out before, and Philip agreed, but seems to have forgotten it. Philip, please look for my email and any other items on it you omitted. This should say "a router MUST ignore TLVs with unrecognized OUIs." It has nothing to do with proprietorship of the OUI, only the interpretation. Or is this another old email storm? ;-) Jeff >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 > >_______________________________________________ >Isis-wg mailing list - Isis-wg@spider.juniper.net >http://spider.juniper.net/mailman/listinfo/isis-wg --=====================_10685274==_.ALT Content-Type: text/html; charset="us-ascii" At 10:55 AM 6/11/2002, mike shand wrote:
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,


I pointed this out before, and Philip agreed, but seems to have forgotten
it.  Philip, please look for my email and any other items on it you
omitted.

This should say "a router MUST ignore TLVs with unrecognized OUIs."
It has nothing to do with proprietorship of the OUI, only the
interpretation.

Or is this another old email storm? ;-)

Jeff


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

_______________________________________________
Isis-wg mailing list  -  Isis-wg@spider.juniper.net
http://spider.juniper.net/mailman/listinfo/isis-wg
--=====================_10685274==_.ALT-- From Ming.Chan@SpirentCom.COM Fri Jul 12 20:55:47 2002 From: Ming.Chan@SpirentCom.COM (Chan, Chung Ming) Date: Fri, 12 Jul 2002 09:55:47 -1000 Subject: [Isis-wg] Unknown Version/ Protocol ID Extension Message-ID: <8AC36D3167EED41184C800508BD9540502DD6B9F@apollo.adtech-inc.com> Hi, I'm running a test on how an ISIS implementation handles different kinds of encoding errors. One of such errors is unknown version number. Since the current Version/Protocol ID Extension and Version fields in the ISIS PDU fixed headers are set to one (1), so if an ISIS implementation receive a PDU with different values, how should the receiving ISIS router handle the PDU? Should it just ignores/discards the PDU or act on the PDU if somehow it can decode *some*/*most* of the information out? I've two implementations in the lab ignore/discard the PDU and one response to the received PDU. Please, advise! Thanks, C. Ming Chan From iesg-secretary@ietf.org Tue Jul 9 13:27:28 2002 From: iesg-secretary@ietf.org (The IESG) Date: Tue, 09 Jul 2002 08:27:28 -0400 Subject: [Isis-wg] Document Action: Three-Way Handshake for IS-IS Point-to-Point Adjacencies to Informational Message-ID: <200207091227.IAA21811@ietf.org> The IESG has approved the Internet-Draft 'Three-Way Handshake for IS-IS Point-to-Point Adjacencies' as an Informational RFC. This document is the product of the IS-IS for IP Internets Working Group. The IESG contact persons are Alex Zinin and Bill Fenner. Technical Summary The document introduces a backward-compatible extension to the IS-IS routing protocol that ensures two-way connectivity on point-to-point links through a three-way handshaking mechanism. The document also extends the protocol to support more than 256 point-to-point links per router. Working Group Summary There was support for this document in the WG. All comments brought up during the WG Last Call have been addressed. Protocol Quality Alex Zinin has reviewed the specification for the IESG. The mechanisms described in the document have been implemented by multiple router vendors and have been widely deployed in the Internet. From ehietbrink@lucent.com Tue Jul 2 17:03:21 2002 From: ehietbrink@lucent.com (E Hietbrink) Date: Tue, 02 Jul 2002 18:03:21 +0200 Subject: [Isis-wg] Proprietary / Private TLV numbers? References: <4.3.2.7.2.20020702111702.01abcd48@dingdong.cisco.com> Message-ID: <3D21CEC9.44AF55A9@lucent.com> Hi, draft-ietf-isis-wg-tlv-codepoints mentions: _______________________________________________________________________ Name Value IIH LSP SNP Status ________________________________________________________________________ Lucent Proprietary 66 n y n The format Lucent Technologies has been using for our proprietary TLV's is identical to what is proposed by Mike Truskowski: TLV number, Length, OUI, "value". Within that TLV "value" we make use of subcodes for different features. The Lucent OUI used is 00601D. If other companies are looking for a TLV number for their proprietary options, feel free to reuse number 66 (0x42 hex) as long as the first three bytes of the "value" adhere to the OUI proposal. We would support a proposal to make it `official'. Regards, Erik Hietbrink Jeff Learman wrote: > > > I am guessing that OUI means an IEEE assigned MAC address? > > It's the first three bytes of an IEEE assigned MAC address. > An OUI can be used for purposes other than assigning MAC addresses. Mike Truskowski wrote: > > > > > > > > > > Why not just do the following? > > > > > > > > > > +-------------------------------------------------+ > > > > > | Type | Length | Value | > > > > > +-------------------------------------------------+ > > > > > | TLV # | Length | vendor code | "value" | > > > > > +-------------------------------------------------+ > > > > > > > > > > Where the vendor code is a fixed 3-4 octets? -- Erik Hietbrink L U C E N T T E C H N O L O G I E S Room: HV-BF414 Bell Labs Innovations Tel: +31 35 687 5414 -------------------------------------- Fax: +31 35 687 5976 Optical Networking, DCN Domain Team mailto:ehietbrink@lucent.com Hilversum, the Netherlands From ehietbrink@lucent.com Tue Jul 2 17:09:47 2002 From: ehietbrink@lucent.com (E Hietbrink) Date: Tue, 02 Jul 2002 18:09:47 +0200 Subject: [Isis-wg] Proprietary / Private TLV numbers? References: <4103264BC8D3D51180B7002048400C454FB710@zhard0jd.europe.nortel.com> Message-ID: <3D21D04B.905399ED@lucent.com> Oops, I didn't read the entire thread yet when I sent my previous mail. There already is a proposal. Good. See my previous email as informational. Regards, Erik Hietbrink > Philip Christian wrote: > > I have done an update, see below > > Philip > > > -----Original Message----- > > From: mike shand [mailto:mshand@cisco.com] > > Sent: Tuesday, June 11, 2002 3:56 PM > > To: Christian, Philip [HAL02:GI50:EXCH] > > Cc: 'Tony Przygienda'; isis-wg@spider.juniper.net; 'Mike Truskowski' > > Subject: RE: [Isis-wg] Proprietary / Private TLV numbers? > > > > > > At 15:38 11/06/2002 +0100, Philip Christian wrote: > > >On receipt of an LSP a router MUST ignore TLVs of type XXX that > > > include an OUI from a different organization, > > > > MUST is a bit strong here. SHOULD or MAY, perhaps. If you > > know how to parse > > company X's subTLVs you should be allowed to do so. > > > > I'm not sure we want to get into mentioning non-standard OUIs > > with G or L > > bits set. > > > > Mike > > > > > > Internet Engineering Task Force P. Christian > INTERNET DRAFT Nortel Networks > June 2002 > > > TLV for Proprietary Use > draft-ietf-isis-private-tlv-forlist2.txt > > Status of this Memo > > This document is an Internet-Draft and is in full conformance with > all provisions of Section 10 of RFC 2026. > > Internet Drafts are working documents of the Internet Engineering > Task Force (IETF), its Areas, and its Working Groups. Note that > other groups may also distribute working documents as Internet > Drafts. > > Internet Drafts are draft documents valid for a maximum of six > months. Internet Drafts may be updated, replaced, or obsoleted by > other documents at any time. It is not appropriate to use Internet > Drafts as reference material or to cite them other than as a > "working draft" or "work in progress". > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This memo provides information for the Internet community. This memo > does not specify an Internet standard of any kind. > > Distribution of this draft is unlimited. > > > 1. Abstract > > This document defines a TLV that may be used for vendor specific or > experimental extensions to the IS-IS routing protocol, and defines > the format of the TLV. > > > 2. Conventions used in this document > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in > this document are to be interpreted as described in RFC 2119. > > > > TLV for Proprietary Use June 2002 > > 3. Introduction > > IS-IS as defined in [1] has always been an extensible routing > protocol. Extensions to IS-IS are encoded as a TLV. Critically [1] > has always defined that an IS-IS router SHALL flood entire LSPs that > it receives on to other IS-IS routers in the network, whether or not > it understands the TLVs that are included in the LSP. Also IS-IS > LSPs are structured such that a router can find TLVs that it > understands, whilst ignoring ones that it does not. > > Thus information that is encoded into a TLV and placed into an LSP > by a router will be propagated to every other router in an IS-IS > level-1 area or level-2 subdomain. > > The basic function of an IS-IS TLV is identified by the first byte > of the TLV. Thus there are only 256 possible basic types of TLV. > Certain types of TLV have been defined to include sub-TLVs so that a > single TLV type can be used for multiple functions. > > No single authority assigns TLV type numbers, [2] lists all known > 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 -- Erik Hietbrink L U C E N T T E C H N O L O G I E S Room: HV-BF414 Bell Labs Innovations Tel: +31 35 687 5414 -------------------------------------- Fax: +31 35 687 5976 Optical Networking, DCN Domain Team mailto:ehietbrink@lucent.com Hilversum, the Netherlands From christi@nortelnetworks.com Tue Jul 2 17:16:16 2002 From: christi@nortelnetworks.com (Philip Christian) Date: Tue, 2 Jul 2002 17:16:16 +0100 Subject: [Isis-wg] Proprietary / Private TLV numbers? Message-ID: <4103264BC8D3D51180B7002048400C454FB739@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_01C221E3.AAE61676 Content-Type: text/plain; charset="iso-8859-1" I would like to submit this as a proper draft. The only thing stopping me is that I don't know which TLV number to choose. Is it up to Tony to allocate one? or do I just pick a free one at random? Philip -----Original Message----- From: E Hietbrink [mailto:ehietbrink@lucent.com] Sent: Tuesday, July 02, 2002 5:10 PM To: Christian, Philip [HAL02:GI50:EXCH] Cc: isis-wg@spider.juniper.net; 'Tony Przygienda'; 'Mike Truskowski'; 'mike shand' Subject: Re: [Isis-wg] Proprietary / Private TLV numbers? Oops, I didn't read the entire thread yet when I sent my previous mail. There already is a proposal. Good. See my previous email as informational. Regards, Erik Hietbrink > Philip Christian wrote: > > I have done an update, see below > > Philip > > > -----Original Message----- > > From: mike shand [mailto:mshand@cisco.com] > > Sent: Tuesday, June 11, 2002 3:56 PM > > To: Christian, Philip [HAL02:GI50:EXCH] > > Cc: 'Tony Przygienda'; isis-wg@spider.juniper.net; 'Mike Truskowski' > > Subject: RE: [Isis-wg] Proprietary / Private TLV numbers? > > > > > > At 15:38 11/06/2002 +0100, Philip Christian wrote: > > >On receipt of an LSP a router MUST ignore TLVs of type XXX that > > > include an OUI from a different organization, > > > > MUST is a bit strong here. SHOULD or MAY, perhaps. If you > > know how to parse > > company X's subTLVs you should be allowed to do so. > > > > I'm not sure we want to get into mentioning non-standard OUIs > > with G or L > > bits set. > > > > Mike > > > > > > Internet Engineering Task Force P. Christian > INTERNET DRAFT Nortel Networks > June 2002 > > > TLV for Proprietary Use > draft-ietf-isis-private-tlv-forlist2.txt > > Status of this Memo > > This document is an Internet-Draft and is in full conformance with > all provisions of Section 10 of RFC 2026. > > Internet Drafts are working documents of the Internet Engineering > Task Force (IETF), its Areas, and its Working Groups. Note that > other groups may also distribute working documents as Internet > Drafts. > > Internet Drafts are draft documents valid for a maximum of six > months. Internet Drafts may be updated, replaced, or obsoleted by > other documents at any time. It is not appropriate to use Internet > Drafts as reference material or to cite them other than as a > "working draft" or "work in progress". > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This memo provides information for the Internet community. This memo > does not specify an Internet standard of any kind. > > Distribution of this draft is unlimited. > > > 1. Abstract > > This document defines a TLV that may be used for vendor specific or > experimental extensions to the IS-IS routing protocol, and defines > the format of the TLV. > > > 2. Conventions used in this document > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in > this document are to be interpreted as described in RFC 2119. > > > > TLV for Proprietary Use June 2002 > > 3. Introduction > > IS-IS as defined in [1] has always been an extensible routing > protocol. Extensions to IS-IS are encoded as a TLV. Critically [1] > has always defined that an IS-IS router SHALL flood entire LSPs that > it receives on to other IS-IS routers in the network, whether or not > it understands the TLVs that are included in the LSP. Also IS-IS > LSPs are structured such that a router can find TLVs that it > understands, whilst ignoring ones that it does not. > > Thus information that is encoded into a TLV and placed into an LSP > by a router will be propagated to every other router in an IS-IS > level-1 area or level-2 subdomain. > > The basic function of an IS-IS TLV is identified by the first byte > of the TLV. Thus there are only 256 possible basic types of TLV. > Certain types of TLV have been defined to include sub-TLVs so that a > single TLV type can be used for multiple functions. > > No single authority assigns TLV type numbers, [2] lists all known > 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 -- Erik Hietbrink L U C E N T T E C H N O L O G I E S Room: HV-BF414 Bell Labs Innovations Tel: +31 35 687 5414 -------------------------------------- Fax: +31 35 687 5976 Optical Networking, DCN Domain Team mailto:ehietbrink@lucent.com Hilversum, the Netherlands ------_=_NextPart_001_01C221E3.AAE61676 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Isis-wg] Proprietary / Private TLV numbers?

I would like to submit this as a proper draft.  = The only thing stopping me is that I don't know which TLV number to = choose.  Is it up to Tony to allocate one? or do I just pick a = free one at random?

Philip

-----Original Message-----
From: E Hietbrink [mailto:ehietbrink@lucent.com]<= /FONT>
Sent: Tuesday, July 02, 2002 5:10 PM
To: Christian, Philip [HAL02:GI50:EXCH]
Cc: isis-wg@spider.juniper.net; 'Tony Przygienda'; = 'Mike Truskowski';
'mike shand'
Subject: Re: [Isis-wg] Proprietary / Private TLV = numbers?


Oops, I didn't read the entire thread yet when I sent = my previous mail.
There already is a proposal. Good. See my previous = email as informational.

Regards,
Erik Hietbrink


> Philip Christian wrote:
>
> I have done an update, see below
>
> Philip
>
> > -----Original Message-----
> > From: mike shand [mailto:mshand@cisco.com]
> > Sent: Tuesday, June 11, 2002 3:56 = PM
> > To: Christian, Philip = [HAL02:GI50:EXCH]
> > Cc: 'Tony Przygienda'; = isis-wg@spider.juniper.net; 'Mike Truskowski'
> > Subject: RE: [Isis-wg] Proprietary / = Private TLV numbers?
> >
> >
> > At 15:38 11/06/2002 +0100, Philip = Christian wrote:
> > >On receipt of an LSP a router MUST = ignore TLVs of type XXX that
> > >    include an OUI from = a different organization,
> >
> > MUST is a bit strong here. SHOULD or MAY, = perhaps. If you
> > know how to parse
> > company X's subTLVs you should be allowed = to do so.
> >
> > I'm not sure we want to get into = mentioning non-standard OUIs
> > with G or L
> > bits set.
> >
> = >          Mike
> >
> >
>
> Internet Engineering Task = Force           &= nbsp;           &= nbsp;    P. Christian
> INTERNET = DRAFT           &= nbsp;           &= nbsp;           &= nbsp;      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.
>
>
>
>        &= nbsp;           &= nbsp;   TLV for Proprietary = Use           &nb= sp;   June 2002
>
> 3. Introduction
>
>    IS-IS as defined in [1] has = always been an extensible routing
>    protocol.  Extensions to = IS-IS are encoded as a TLV.  Critically [1]
>    has always defined that an = IS-IS router SHALL flood entire LSPs that
>    it receives on to other IS-IS = routers in the network, whether or not
>    it understands the TLVs that = are included in the LSP.  Also IS-IS
>    LSPs are structured such that = a router can find TLVs that it
>    understands, whilst ignoring = ones that it does not.
>
>    Thus information that is = encoded into a TLV and placed into an LSP
>    by a router will be = propagated to every other router in an IS-IS
>    level-1 area or level-2 = subdomain.
>
>    The basic function of an = IS-IS TLV is identified by the first byte
>    of the TLV.  Thus there = are only 256 possible basic types of TLV.
>    Certain types of TLV have = been defined to include sub-TLVs so that a
>    single TLV type can be used = for multiple functions.
>
>    No single authority assigns = TLV type numbers, [2] lists all known
>    TLV type numbers at this = time.  Also no TLV type number was ever
>    defined for private, = proprietary or experimental use.
>
>    The extensible nature of = IS-IS has made the use of TLVs in LSPs for
>    proprietary purposes so = useful that in the absence of a central
>    authority for assigning TLV = type numbers vendors have occasionally
>    simply chosen a number and = hoped for the best.  The risk is that
>    such a TLV type number may = then be chosen by another organization at
>    a later time for a different = function, thus creating an
>    interoperability problem. = Also this accelerates the burning of the
>    256 possible TLV type = numbers.
>
>    This document specifies a TLV = type number that may be used for
>    proprietary, private or = experimental purposes, and a mechanism that
>    insures that implementations = from different sources can use the TLV
>    for different purposes in the = same network without creating
>    interoperability = problems.
>
>    By using this new TLV, = companies, individuals or institutions may
>    use extensions to IS-IS = without fear of interoperability problems
>    with other organizations in = the future, and the available pool of
>    TLV type numbers will no = longer be diminished by proprietary use.
>
> 4. TLV type number for proprietary use
>
>    The type field for this TLV = SHALL be XXX.
>
>    TLVs that use XXX for the = type field MUST include a valid IEEE
>    assigned OUI as the first = three bytes of the value field of the TLV.
>    For more information about = OUIs see [3].
>
>
>
>          = ;            = ;  TLV for Proprietary = Use           &nb= sp;   June 2002
>
>    On receipt of an LSP a router = MAY ignore TLVs of type XXX that
>    include an OUI from a = different organization, however the router
>    MUST flood the LSP onwards as = per [1].
>
>    After the first three bytes = of the value field subsequent bytes may
>    be used freely for any = purpose provided that the resultant TLV is
>    conformant with [1].
>
>    Many organizations will have = access to only one or a few OUIs.
>    Implementers are free to = format the value field after their OUI into
>    sub-TLVs so that it may be = used for multiple purposes, and would be
>    well advised to do this from = the outset.  Note that if sub-TLVs are
>    to be used then the very = first implementation to exist will need to
>    recognize the sub-TLV = structure, and ignore sub-TLVs that it does
>    not understand whilst = searching for sub-TLVs that it does
>    understand.
>
> 5. Security Considerations
>
>    The proprietary TLV raises no = new security issues for IS-IS.
>    Information placed in an = IS-IS TLV cannot be considered secure, and
>    so if security is required = then an implementation will need to
>    encrypt the information using = a suitable method.
>
> 6. References
>
>    [1] ISO, "Intermediate = system to Intermediate system routeing
>    information exchange protocol = for use in conjunction with the
>    Protocol for providing the = Connectionless-mode Network Service (ISO
>    8473)", ISO/IEC = 10589:1992.
>
>    [2] = draft-ietf-isis-wg-tlv-codepoints-02.txt, Reserved TLV
>    Codepoints in ISIS, Tony = Przygienda, November 2001
>
>    [3] http://standards.ieee.org/regauth/oui/index.html
>
> 7. Acknowledgments
>
>    The author takes no credit = for this work as the concept was
>    discussed in the IS-IS = Working Group before the author even became
>    an active participant.  = Suggestions for acknowledgement gladly
>    received.
>
> 8. Author's Addresses
>
>    Philip Christian
>    Nortel Networks Harlow = Laboratories
>    London Road, Harlow,
>    Essex, CM17 9NA UK
>
>    Email: = christi@nortelnetworks.com

--
Erik = Hietbrink          &nb= sp;         L U C E N = T    T E C H N O L O G I E S
Room: = HV-BF414          &nbs= p;           &nbs= p;           &nbs= p;  Bell Labs Innovations
Tel: +31 35 687 = 5414           &n= bsp;  --------------------------------------
Fax: +31 35 687 = 5976           &n= bsp;     Optical Networking, DCN Domain Team
mailto:ehietbrink@lucent.com&n= bsp;           &n= bsp;     Hilversum, the Netherlands

------_=_NextPart_001_01C221E3.AAE61676-- From Internet-Drafts@ietf.org Wed Jul 3 11:28:13 2002 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Wed, 03 Jul 2002 06:28:13 -0400 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-ext-lsp-frags-01.txt Message-ID: <200207031028.GAA03378@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 : Extending the Number of IS-IS LSP Fragments Beyond the 256 Limit Author(s) : A. Hermelin, S. Previdi, M. Shand Filename : draft-ietf-isis-ext-lsp-frags-01.txt Pages : 12 Date : 02-Jul-02 This document describes a mechanism that allows a system to originate more than 256 LSP fragments, a limit set by the original Intermediate System to Intermediate System (IS-IS) Routing protocol, as described in ISO 10589. This mechanism can be used in IP-only, OSI-only, and dual routers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-ext-lsp-frags-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-ext-lsp-frags-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-ext-lsp-frags-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: <20020702151041.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-ext-lsp-frags-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-ext-lsp-frags-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020702151041.I-D@ietf.org> --OtherAccess-- --NextPart--