From isis-wg-bounces@ietf.org Wed Dec 8 09:27:13 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28762 for ; Wed, 8 Dec 2004 09:27:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc2fZ-0002tk-SB; Wed, 08 Dec 2004 09:19:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc2Zi-0000Ud-Ik for isis-wg@megatron.ietf.org; Wed, 08 Dec 2004 09:13:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26916 for ; Wed, 8 Dec 2004 09:13:48 -0500 (EST) Received: from adsl-66-120-207-101.dsl.sntc01.pacbell.net ([66.120.207.101] helo=coffee.rawdofmt.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cc2gK-0006J2-BB for isis-wg@ietf.org; Wed, 08 Dec 2004 09:20:51 -0500 Received: from [IPv6:::1] (localhost [127.0.0.1]) by coffee.rawdofmt.org (Postfix) with ESMTP id 41BC03DCC8C; Wed, 8 Dec 2004 06:13:01 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <44504D3B-4923-11D9-B4BB-000D93C60674@rawdofmt.org> Content-Transfer-Encoding: 7bit From: Christian Hopps Subject: Re: [Isis-wg] Re: isisCircLevelIDOctet in the WG MIB Date: Wed, 8 Dec 2004 06:13:00 -0800 To: "Parker, Jeff" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: 7bit Cc: isis-wg@ietf.org, Jeff Parker , Jonathan Harrison X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: 7bit I would suggest that this value be read-only and there only be one object. Chris. On Nov 9, 2004, at 9:28 AM, Parker, Jeff wrote: > Jonathan - > I see your point, but wonder if the importance of a default value > outweighs the confusion of having two names for this byte. > > - jeff parker > > > On 11/9/04 11:51 AM, "Jonathan Harrison" > > wrote: > >> Jeff, >> >> I've got a concern over the usability of the isisCircLevelIDOctet >> object >> defined in the isisCircLevelTable. >> >> isisCircLevelIDOctet OBJECT-TYPE >> SYNTAX Integer32(0..255) >> MAX-ACCESS read-create >> STATUS current >> DESCRIPTION >> "A one byte identifier that can be used in protocol >> packets >> to identify a circuit. Values of isisCircLevelIDOctet >> do not need to be unique. They are only required to >> differ on LANs where the Intermediate System is the >> Designated Intermediate System." >> ::= { isisCircLevelEntry 5 } >> >> There are the following issues with this. >> >> - The properties of the object are different for point-to-point >> circuits >> and for LAN circuits. For a point-to-point circuit, the value 0 is >> acceptable, and could be used as a sensible default. On the other >> hand, for >> a broadcast circuit, the value 0 cannot be used if the IS-IS instance >> could >> become DIS on the LAN, and there is no sensible default value (due to >> the >> uniqueness requirement). >> >> - As a general point, it would be good for all read-create objects >> in the >> isisCircLevel table to have MIB defined default values. Currently, >> the >> IDOctet is the only non-defaultable value, and since the IDOctet is >> used in >> IIH PDUs, a value must be chosen for this object before a circuit can >> be >> activated via the MIB. Circuit configuration would be much simpler >> if it >> only required the creation of a row in the isisCircuitTable, without >> the >> modification of any objects in the isisCircLevel table. >> >> - The reason for making the value level specific, was to allow >> support for >> the "Maintaining more than 255 circuits in IS-IS" draft >> (draft-ietf-isis-wg-255adj). However, if this draft is supported, >> then a >> unique value for the IDOctet object is chosen by the IS-IS instance >> when it >> becomes DIS on a LAN, and so it makes more sense for the MIB object >> to be >> read-only. >> >> These points suggest that the usability of the MIB would be improved >> by >> splitting this object into two separate objects. >> >> - The object for point-to-point circuits is read-create, with the >> default >> value of zero. Although this object could move to the isisCircTable, >> it >> probably makes more sense to leave it in the isisCircLevel table >> (since it >> should be kept with isisCircLevelID). >> >> - The object for broadcast circuits is read-only, and reflects the >> value >> chosen by the IS-IS instance. Since it is level specific, it must >> remain in >> the isisCircLevelTable. >> >> What do you think? If you agree, I'm happy to suggest some text. >> >> Thanks, >> Jon > > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Dec 8 10:40:59 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06595 for ; Wed, 8 Dec 2004 10:40:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc3qM-0007pe-SV; Wed, 08 Dec 2004 10:35:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc3lI-0006XK-4I for isis-wg@megatron.ietf.org; Wed, 08 Dec 2004 10:29:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05594 for ; Wed, 8 Dec 2004 10:29:50 -0500 (EST) Received: from smtp2.dataconnection.com ([192.91.191.8] helo=smtp2.datcon.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cc3s1-0008IT-Er for isis-wg@ietf.org; Wed, 08 Dec 2004 10:36:53 -0500 Received: by beiderbecke.datcon.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Dec 2004 15:29:17 -0000 Message-ID: <37701240971DD31193970000F6CCB9F7050428B2@duke.datcon.co.uk> From: Jonathan Harrison To: "'Christian Hopps'" , "Parker, Jeff" Subject: RE: [Isis-wg] Re: isisCircLevelIDOctet in the WG MIB Date: Wed, 8 Dec 2004 15:29:12 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: isis-wg@ietf.org, Jeff Parker X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Chris, How about this? isisCircLevelIDOctet OBJECT-TYPE SYNTAX Integer32(0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "A one byte identifier for the circuit selected by the Intermediate System. On point-to-point circuits, the value is used as the Local Circuit ID in point-to-point IIH PDUs transmitted on this circuit. In this case, values of isisCircLevelIDOctet do not need to be unique. For broadcast circuits, the value is used to generate the LAN ID that will be used if this Intermediate System is elected as the Designated IS on this circuit. The value is required to differ on LANs where the Intermediate System is the Designated Intermediate System." ::= { isisCircLevelEntry 5 } Jon -----Original Message----- From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org]On Behalf Of Christian Hopps Sent: 08 December 2004 14:13 To: Parker, Jeff Cc: isis-wg@ietf.org; Jeff Parker; Jonathan Harrison Subject: Re: [Isis-wg] Re: isisCircLevelIDOctet in the WG MIB I would suggest that this value be read-only and there only be one object. Chris. On Nov 9, 2004, at 9:28 AM, Parker, Jeff wrote: > Jonathan - > I see your point, but wonder if the importance of a default value > outweighs the confusion of having two names for this byte. > > - jeff parker > > > On 11/9/04 11:51 AM, "Jonathan Harrison" > > wrote: > >> Jeff, >> >> I've got a concern over the usability of the isisCircLevelIDOctet >> object >> defined in the isisCircLevelTable. >> >> isisCircLevelIDOctet OBJECT-TYPE >> SYNTAX Integer32(0..255) >> MAX-ACCESS read-create >> STATUS current >> DESCRIPTION >> "A one byte identifier that can be used in protocol >> packets >> to identify a circuit. Values of isisCircLevelIDOctet >> do not need to be unique. They are only required to >> differ on LANs where the Intermediate System is the >> Designated Intermediate System." >> ::= { isisCircLevelEntry 5 } >> >> There are the following issues with this. >> >> - The properties of the object are different for point-to-point >> circuits >> and for LAN circuits. For a point-to-point circuit, the value 0 is >> acceptable, and could be used as a sensible default. On the other >> hand, for >> a broadcast circuit, the value 0 cannot be used if the IS-IS instance >> could >> become DIS on the LAN, and there is no sensible default value (due to >> the >> uniqueness requirement). >> >> - As a general point, it would be good for all read-create objects >> in the >> isisCircLevel table to have MIB defined default values. Currently, >> the >> IDOctet is the only non-defaultable value, and since the IDOctet is >> used in >> IIH PDUs, a value must be chosen for this object before a circuit can >> be >> activated via the MIB. Circuit configuration would be much simpler >> if it >> only required the creation of a row in the isisCircuitTable, without >> the >> modification of any objects in the isisCircLevel table. >> >> - The reason for making the value level specific, was to allow >> support for >> the "Maintaining more than 255 circuits in IS-IS" draft >> (draft-ietf-isis-wg-255adj). However, if this draft is supported, >> then a >> unique value for the IDOctet object is chosen by the IS-IS instance >> when it >> becomes DIS on a LAN, and so it makes more sense for the MIB object >> to be >> read-only. >> >> These points suggest that the usability of the MIB would be improved >> by >> splitting this object into two separate objects. >> >> - The object for point-to-point circuits is read-create, with the >> default >> value of zero. Although this object could move to the isisCircTable, >> it >> probably makes more sense to leave it in the isisCircLevel table >> (since it >> should be kept with isisCircLevelID). >> >> - The object for broadcast circuits is read-only, and reflects the >> value >> chosen by the IS-IS instance. Since it is level specific, it must >> remain in >> the isisCircLevelTable. >> >> What do you think? If you agree, I'm happy to suggest some text. >> >> Thanks, >> Jon > > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Dec 9 05:09:45 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07874 for ; Thu, 9 Dec 2004 05:09:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcLA6-0008Rq-Qc; Thu, 09 Dec 2004 05:04:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcL8k-0007uj-Ny for isis-wg@megatron.ietf.org; Thu, 09 Dec 2004 05:03:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07274 for ; Thu, 9 Dec 2004 05:03:12 -0500 (EST) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcLFe-0000wg-Tp for isis-wg@ietf.org; Thu, 09 Dec 2004 05:10:26 -0500 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Dec 2004 11:03:09 +0100 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isis-wg] Another doc for WG acceptance Date: Thu, 9 Dec 2004 11:03:07 +0100 Message-ID: Thread-Topic: [Isis-wg] Another doc for WG acceptance Thread-Index: AcTIwuXvI7lZmV/6ROS0Gm80M/d2ngVEbl5A From: "DUBOIS Nicolas RD-CORE-ISS" To: "David Ward" , , "Christian E Hopps" X-OriginalArrivalTime: 09 Dec 2004 10:03:09.0383 (UTC) FILETIME=[492FDD70:01C4DDD6] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi, I read quickly through this draft and I feel it is interesting for future use. http://www.ietf.org/internet-drafts/draft-vasseur-isis-link-attr-01.txt I have one suggestion regarding this draft : One more bit could be defined with the following meaning: "Graceful restart support has been successfully negociated on that link i.e. GR TLV is included by both routers in the IIHs". One issue I think we have with graceful restart as it is currently defined is: "a neighbouring router do not know if graceful restart will be working on all links of the restarting router, for instance because someone forgot to configure it on one of the other neighbouring routers. And to me GR is really efficient in a network only if it is supported on all ISIS links of one restarting router. What do you think ? Best regards, Nicolas -----Original Message----- From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org] On Behalf Of David Ward Sent: jeudi 11 novembre 2004 16:23 To: isis-wg@ietf.org; Christian E Hopps; dward@cisco.com Subject: [Isis-wg] Another doc for WG acceptance All - We left a doc off our list yesterday for consideration for becoming a WG doc.=20 http://www.ietf.org/internet-drafts/draft-vasseur-isis-link-attr-01.txt Unless there is objection, it will be accepted as a WG document in 30 days. DWard and CHopps _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Dec 9 06:12:13 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12724 for ; Thu, 9 Dec 2004 06:12:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcM75-0001eh-IN; Thu, 09 Dec 2004 06:05:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcM4D-0000ns-Lt for isis-wg@megatron.ietf.org; Thu, 09 Dec 2004 06:02:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12174 for ; Thu, 9 Dec 2004 06:02:35 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcMBB-0002L9-HP for isis-wg@ietf.org; Thu, 09 Dec 2004 06:09:49 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 09 Dec 2004 12:09:51 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iB9B23Gb012074; Thu, 9 Dec 2004 12:02:03 +0100 (MET) Received: from mshand-w2k02.cisco.com (ams-clip-vpn-dhcp4445.cisco.com [10.61.81.92]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA14991; Thu, 9 Dec 2004 11:02:02 GMT Message-Id: <4.3.2.7.2.20041209105039.02d75008@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 09 Dec 2004 11:02:01 +0000 To: "DUBOIS Nicolas RD-CORE-ISS" From: mike shand Subject: RE: [Isis-wg] Another doc for WG acceptance In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: Christian E Hopps , David Ward , isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org At 11:03 09/12/2004 +0100, DUBOIS Nicolas RD-CORE-ISS wrote: >Hi, > >I read quickly through this draft and I feel it is interesting for >future use. >http://www.ietf.org/internet-drafts/draft-vasseur-isis-link-attr-01.txt > >I have one suggestion regarding this draft : > >One more bit could be defined with the following meaning: >"Graceful restart support has been successfully negociated on that link >i.e. GR TLV is included by both routers in the IIHs". > >One issue I think we have with graceful restart as it is currently >defined is: "a neighbouring router do not know if graceful restart will >be working on all links of the restarting router, for instance because >someone forgot to configure it on one of the other neighbouring routers. >And to me GR is really efficient in a network only if it is supported on >all ISIS links of one restarting router. Nicolas, I'm not sure what you are proposing doing with this information. How would a router alter its behavior depending on whether its neighbor had one or more other links to routers which did not support restart? Are you suggesting that there is some benefit in this information being flooded to all nodes? If not, why use this mechanism to disseminate it? I agree that restart capability needs to exist on all links for it to be truly useful. Mike >What do you think ? > >Best regards, > >Nicolas > >-----Original Message----- >From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org] On >Behalf Of David Ward >Sent: jeudi 11 novembre 2004 16:23 >To: isis-wg@ietf.org; Christian E Hopps; dward@cisco.com >Subject: [Isis-wg] Another doc for WG acceptance > >All - > We left a doc off our list yesterday for consideration for >becoming a WG doc. > >http://www.ietf.org/internet-drafts/draft-vasseur-isis-link-attr-01.txt > >Unless there is objection, it will be accepted as a WG document in 30 >days. > >DWard and CHopps > >_______________________________________________ >Isis-wg mailing list >Isis-wg@ietf.org >https://www1.ietf.org/mailman/listinfo/isis-wg > >_______________________________________________ >Isis-wg mailing list >Isis-wg@ietf.org >https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Dec 9 12:42:18 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13713 for ; Thu, 9 Dec 2004 12:42:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcS2T-0004OU-Gl; Thu, 09 Dec 2004 12:25:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcRq4-0006Cy-QT for isis-wg@megatron.ietf.org; Thu, 09 Dec 2004 12:12:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11228 for ; Thu, 9 Dec 2004 12:12:22 -0500 (EST) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcRx5-0001cI-TG for isis-wg@ietf.org; Thu, 09 Dec 2004 12:19:40 -0500 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Dec 2004 18:12:22 +0100 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: FW: [Isis-wg] Another doc for WG acceptance Date: Thu, 9 Dec 2004 18:12:20 +0100 Message-ID: Thread-Topic: [Isis-wg] Another doc for WG acceptance Thread-Index: AcTd3oaYyv+3RqqRSI213J/PcBD7kQAM2cZwAAAL8tA= From: "DUBOIS Nicolas RD-CORE-ISS" To: "mike shand" X-OriginalArrivalTime: 09 Dec 2004 17:12:22.0032 (UTC) FILETIME=[3EF64100:01C4DE12] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: quoted-printable Cc: Christian E Hopps , David Ward , isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable =20 =20 Mike, Thanks for your interest, some answers and comments inline, Nicolas -----Original Message----- From: mike shand [mailto:mshand@cisco.com] Sent: jeudi 9 d=E9cembre 2004 12:02 To: DUBOIS Nicolas RD-CORE-ISS Cc: David Ward; isis-wg@ietf.org; Christian E Hopps Subject: RE: [Isis-wg] Another doc for WG acceptance At 11:03 09/12/2004 +0100, DUBOIS Nicolas RD-CORE-ISS wrote: >Hi, > >I read quickly through this draft and I feel it is interesting for=20 >future use. >http://www.ietf.org/internet-drafts/draft-vasseur-isis-link-attr-01.txt > >I have one suggestion regarding this draft : > >One more bit could be defined with the following meaning: >"Graceful restart support has been successfully negociated on that link = >i.e. GR TLV is included by both routers in the IIHs". > >One issue I think we have with graceful restart as it is currently=20 >defined is: "a neighbouring router do not know if graceful restart will = >be working on all links of the restarting router, for instance because=20 >someone forgot to configure it on one of the other neighbouring = routers. >And to me GR is really efficient in a network only if it is supported=20 >on all ISIS links of one restarting router. Nicolas, I'm not sure what you are proposing doing with this information. How = would a router alter its behavior depending on whether its neighbor had = one or more other links to routers which did not support restart? >>I think it could decide to bring down the adjacency, trigger SPF, = flood LSP and to some extent ignore the GR process. Are you suggesting that there is some benefit in this information being = flooded to all nodes? >>Yes, I have the feeling it is useful that all nodes have a clear view = of where graceful restart >is applicable and where it is not. Two = possible reasons: < - You can expect a better and faster ISIS decision in the network in = case GR is imperfectly deployed - Overlaying protocols like LDP,BGP or RSVP or other may be interested = into that (I do not really know how at this point).=20 <=09 If not, why use this mechanism to disseminate it ? >>If there is no benefit, there is no need. I agree that restart capability needs to exist on all links for it to be = truly useful. >>And for all protocols ! >>in our case : RIP, HSRP, ISIS, LDP, BGP, MP-BGP.=20 >>Thanks for your interest, >>Nicolas Mike >What do you think ? > >Best regards, > >Nicolas > >-----Original Message----- >From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org] On=20 >Behalf Of David Ward >Sent: jeudi 11 novembre 2004 16:23 >To: isis-wg@ietf.org; Christian E Hopps; dward@cisco.com >Subject: [Isis-wg] Another doc for WG acceptance > >All - > We left a doc off our list yesterday for consideration for=20 >becoming a WG doc. > >http://www.ietf.org/internet-drafts/draft-vasseur-isis-link-attr-01.txt > >Unless there is objection, it will be accepted as a WG document in 30=20 >days. > >DWard and CHopps > >_______________________________________________ >Isis-wg mailing list >Isis-wg@ietf.org >https://www1.ietf.org/mailman/listinfo/isis-wg > >_______________________________________________ >Isis-wg mailing list >Isis-wg@ietf.org >https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Mon Dec 13 10:22:09 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18366 for ; Mon, 13 Dec 2004 10:22:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdrzB-0008Ba-Iz; Mon, 13 Dec 2004 10:19:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdrqA-0004ix-Ur for isis-wg@megatron.ietf.org; Mon, 13 Dec 2004 10:10:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17164 for ; Mon, 13 Dec 2004 10:10:20 -0500 (EST) Received: from adsl-66-120-207-101.dsl.sntc01.pacbell.net ([66.120.207.101] helo=coffee.rawdofmt.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cdrxp-0000Hc-RS for isis-wg@ietf.org; Mon, 13 Dec 2004 10:18:28 -0500 Received: from [IPv6:::1] (localhost [127.0.0.1]) by coffee.rawdofmt.org (Postfix) with ESMTP id 256213DCC8C; Mon, 13 Dec 2004 07:09:35 -0800 (PST) In-Reply-To: <37701240971DD31193970000F6CCB9F7050428B2@duke.datcon.co.uk> References: <37701240971DD31193970000F6CCB9F7050428B2@duke.datcon.co.uk> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Christian Hopps Subject: Re: [Isis-wg] Re: isisCircLevelIDOctet in the WG MIB Date: Mon, 13 Dec 2004 07:09:34 -0800 To: Jonathan Harrison X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: Jeff Parker , isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: 7bit Looks fine to me. Chris. On Dec 8, 2004, at 7:29 AM, Jonathan Harrison wrote: > Chris, > > How about this? > > isisCircLevelIDOctet OBJECT-TYPE > SYNTAX Integer32(0..255) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "A one byte identifier for the circuit selected by the > Intermediate System. > > On point-to-point circuits, the value is used as the Local > Circuit ID in point-to-point IIH PDUs transmitted on this > circuit. In this case, values of isisCircLevelIDOctet do > not need to be unique. > > For broadcast circuits, the value is used to generate the > LAN ID that will be used if this Intermediate System is > elected as the Designated IS on this circuit. The value > is required to differ on LANs where the Intermediate > System > is the Designated Intermediate System." > ::= { isisCircLevelEntry 5 } > > Jon _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From S10baloy@netscape.net Sat Dec 18 04:08:40 2004 Received: from mydomain.com ([196.25.238.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02658 for ; Sat, 18 Dec 2004 04:08:34 -0500 (EST) From: S10baloy@netscape.net Message-Id: <200412180908.EAA02658@ietf.org> Received: from nk3.google.com ([128.152.125.216]) by nk4.excite.com with Internet Mail Service id 016ECA44; Sat, 18 Dec 2004 09:09:03 -0000 Received: from mailin-01.linksynergy.com ([88.155.232.202]) by mailin-02.genuity.com with Microsoft SMTPSVC id 13EDC18E; Sat, 18 Dec 2004 09:08:53 -0000 Received: from mailin-03.inreach.com ([240.99.78.218]) by mailin-04.banelco.com.ar with SMTP id 0027AE50; Sat, 18 Dec 2004 09:08:43 -0000 Date: Sat, 18 Dec 2004 11:08:43 +0200 To: S10baloy@netscape.net Subject: ASKING FOR ASSISTANCE MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT FROM: BALOY SITHOLE. TELL: 27-735-660-276 ATTN:PRESIDENT/CEO I know you will be surprised to read from me, but please consider this as a request from a family i dire need of assistance.First, I must introduc myself. I a MR. BALOY SITHOLE. from Angola. I am the first and only son of BRIGADIER SITHOLE JONES. I am presently resident in South Africa. I got your contact address from a business directory in Johannesburg Chamber of commerce and Industry. On behalf of my widowed mother MRS. ELIZABETH SITHOLE, I desided to solicit for your assistance to transfer the sum of US$21.5 MILLION( TWENTY ONE MILLION FIVE HUNDRED THOUSAND UNITED STATES DOLLARS)inherited from my late father, into your personal/ company's account. Before my fathers' death, he was a Brigadier in charge of Arms and Ammunation procurement for the Angola Army. In his WILL, he specifically drew my attention to the said sum of money which he deposited in a safe box of a private Security Company in Johannesburg- South Africa in a treasure box, fully documented in my name. IN FACT MY FATHER SAID AND I QUOTE 'MY BELOVED SON, I WISH TO DRAW YOUR ATTENTION TO US$21.5 MILLION . I DEPOSITED THE BOX CONTAINING THIS MONEY IN A SECURITY COMPANY IN JOHANNESBURG, SOUTH AFRICA. DURING THE WAR, I WAS VERY DEDICATED AND OFFICERS AND GOVERNMENT FUNCTIONARIES WERE BUSSY HELPING THEMSELVES WITH GOVERNMENT FUNDS AND PROPERTIES AND SENDING THEM TO FOREIGN COUNTRIES. DUE TO THIS, WHEN I AND MY FORMER SPECIAL ADVISOR TO THE PRESIDENT WERE ASSIGNED BY THE PRESIDENT (EDUARDO SANTOS) TO PURCHASE ARMS IN SOUTH AFRICA, WE SAW THIS AS A GOLDEN OPPORTUNITY AND DIVERTED THE MONEY AND DIVIDED IT. i GOT A TOTAL SUM OF US$21.5 MILLION. IN CASE OF MY ABSENCE ON EARTH, AS A RESULT OF DEATH ONLY, YOU SHOULD SOLICIT FOR THE FUND FOR INVESTMENT PURPOSES.' From the above, you will understand that the lives and future of my family depens on this money, as such I will be grateful if you can assist us. We are now living in South Africa as political Asylum seekers and financial laws and regulation of the Republic of South Africa do not permit us financial rights to such huge sum of money. In view of this, I cannot invest this fund in South africa, hence i am prepared to offer you 20% of the total fund, while 10% will be set aside for local and international expenses and 70% will be for my family and me. Finally, modalities on howthe transfer will be bone will be conveyed to you once we have established trust and confidence between ourselves. Please treat this matter as very urgent. Best regards, BALOY SITHOLE. From isis-wg-bounces@ietf.org Mon Dec 20 02:00:32 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20197 for ; Mon, 20 Dec 2004 02:00:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgHUO-0002RN-8l; Mon, 20 Dec 2004 01:57:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgHRk-0001xb-SX for isis-wg@megatron.ietf.org; Mon, 20 Dec 2004 01:55:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19581 for ; Mon, 20 Dec 2004 01:55:07 -0500 (EST) Received: from rproxy.gmail.com ([64.233.170.197]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgHaw-00087q-Ma for isis-wg@ietf.org; Mon, 20 Dec 2004 02:04:39 -0500 Received: by rproxy.gmail.com with SMTP id r35so377582rna for ; Sun, 19 Dec 2004 22:55:06 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=j5K1NvNYO9j48hySySzvGP9IJ4UJABeXOJVc0WNGt57ZHKehI/UnnqMCD+4vMzFNG4MFqQHWLr72/UeQZorGrIMHOafsQILyw8MQOTTtGpTmnpAMmyZrolFnxqpLKckKTRCi13gnnIKo4a65Wt73KJH1sLhDjpNy17SR21Id8Pw= Received: by 10.38.73.69 with SMTP id v69mr360618rna; Sun, 19 Dec 2004 22:55:05 -0800 (PST) Received: by 10.38.102.24 with HTTP; Sun, 19 Dec 2004 22:55:05 -0800 (PST) Message-ID: Date: Mon, 20 Dec 2004 12:25:05 +0530 From: Abhishek Verma To: isis-wg@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Dest MAC address X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Abhishek Verma List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi, ISIS uses well known MAC address ((0x0180c2000014 and 15) for all its L1 and L2 messages on a broadcast medium. Does the same hold true for all p2p communication too? I belive it should use those same well known MAC addresses even though an ISIS router is only communicating with one ISIS router on a p2p link. Reason being that if it wants to know the MAC address of the neighboring router then it will need to issue an ARP message (which mandates an IP stack). And since ISIS can run without an IP stack it must be using those well known L2 MAC address in case of ISIS over p2p links also. Is my assumption and reasoning correct? Thanks, Abhishek -- Class of 2004 Institute of Technology, BHU Varanasi, India _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Mon Dec 20 04:18:05 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13554 for ; Mon, 20 Dec 2004 04:18:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgJcM-00027R-Vi; Mon, 20 Dec 2004 04:14:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgJbp-0001z1-GC for isis-wg@megatron.ietf.org; Mon, 20 Dec 2004 04:13:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13133 for ; Mon, 20 Dec 2004 04:13:39 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgJl2-0002up-5F for isis-wg@ietf.org; Mon, 20 Dec 2004 04:23:13 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 20 Dec 2004 10:22:43 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iBK9D5TF017060; Mon, 20 Dec 2004 10:13:05 +0100 (MET) Received: from mshand-w2k02.cisco.com (ams-clip-vpn-dhcp253.cisco.com [10.61.64.253]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id JAA16666; Mon, 20 Dec 2004 09:13:04 GMT Message-Id: <4.3.2.7.2.20041220090706.02c22458@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 20 Dec 2004 09:13:04 +0000 To: Abhishek Verma From: mike shand Subject: Re: [Isis-wg] Dest MAC address In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org At 12:25 20/12/2004 +0530, Abhishek Verma wrote: >Hi, > >ISIS uses well known MAC address ((0x0180c2000014 and 15) for all its >L1 and L2 messages on a broadcast medium. Does the same hold true for >all p2p communication too? I belive it should use those same well >known MAC addresses even though an ISIS router is only communicating >with one ISIS router on a p2p link. Reason being that if it wants to >know the MAC address of the neighboring router then it will need to >issue an ARP message (which mandates an IP stack). And since ISIS can >run without an IP stack it must be using those well known L2 MAC >address in case of ISIS over p2p links also. See draft-ietf-isis-igp-p2p-over-lan-05.txt When you say ALL p2p communication, you presumably mean all p2p over broadcast medium. Of course, conventional p2p uses the mechanism specified in ISO/IEC 10589. Mike >Is my assumption and reasoning correct? > >Thanks, >Abhishek > >-- >Class of 2004 >Institute of Technology, BHU >Varanasi, India > >_______________________________________________ >Isis-wg mailing list >Isis-wg@ietf.org >https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Mon Dec 20 04:30:31 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14501 for ; Mon, 20 Dec 2004 04:30:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgJqR-0004Es-S5; Mon, 20 Dec 2004 04:28:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgJk8-0003QG-7a for isis-wg@megatron.ietf.org; Mon, 20 Dec 2004 04:22:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13885 for ; Mon, 20 Dec 2004 04:22:14 -0500 (EST) Received: from rproxy.gmail.com ([64.233.170.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgJtL-0003DD-IE for isis-wg@ietf.org; Mon, 20 Dec 2004 04:31:48 -0500 Received: by rproxy.gmail.com with SMTP id r35so392896rna for ; Mon, 20 Dec 2004 01:22:14 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=sdp1kB6zmzR4XxZ/0p3kEIuLCQDZSN8oZte1y7/XAF8UXUXbXP0i1iRF42PI5qr4yEeKpASpE8W1NnxgGYL37dCy0Lm1DpYXlvqxAE0bB8uP3OtefDR8a2LQJNre2yBsAcXKOeedRXH5VdNgZ/agh60ViR6VNAVx4u2gW3C7+IU= Received: by 10.38.74.60 with SMTP id w60mr90405rna; Mon, 20 Dec 2004 01:22:14 -0800 (PST) Received: by 10.38.102.24 with HTTP; Mon, 20 Dec 2004 01:22:14 -0800 (PST) Message-ID: Date: Mon, 20 Dec 2004 14:52:14 +0530 From: Abhishek Verma To: mike shand Subject: Re: [Isis-wg] Dest MAC address In-Reply-To: <4.3.2.7.2.20041220090706.02c22458@jaws.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4.3.2.7.2.20041220090706.02c22458@jaws.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Abhishek Verma List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: 7bit > > When you say ALL p2p communication, you presumably mean all p2p over > broadcast medium. Of course, conventional p2p uses the mechanism specified > in ISO/IEC 10589. I'm sorry i meant ISIS over p2p links (ATM/FR/OC/etc). Abhishek. > > Mike > > > >Is my assumption and reasoning correct? > > > >Thanks, > >Abhishek > > > >-- > >Class of 2004 > >Institute of Technology, BHU > >Varanasi, India > > > >_______________________________________________ > >Isis-wg mailing list > >Isis-wg@ietf.org > >https://www1.ietf.org/mailman/listinfo/isis-wg > -- -- Class of 2004 Institute of Technology, BHU Varanasi, India _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Mon Dec 20 09:13:08 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00283 for ; Mon, 20 Dec 2004 09:13:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgODh-0000cx-C4; Mon, 20 Dec 2004 09:09:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgOCM-0000K2-4W for isis-wg@megatron.ietf.org; Mon, 20 Dec 2004 09:07:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29461 for ; Mon, 20 Dec 2004 09:07:40 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgOL4-00012R-1F for isis-wg@ietf.org; Mon, 20 Dec 2004 09:17:17 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 20 Dec 2004 09:06:36 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iBKE6X9E028298; Mon, 20 Dec 2004 09:06:34 -0500 (EST) Received: from jlearman-w2k05.cisco.com (rtp-vpn1-94.cisco.com [10.82.224.94]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BEC90698; Mon, 20 Dec 2004 06:06:32 -0800 (PST) Message-Id: <4.3.2.7.2.20041220090448.02576860@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 20 Dec 2004 09:06:26 -0500 To: Abhishek Verma , mike shand From: Jeff Learman Subject: Re: [Isis-wg] Dest MAC address In-Reply-To: References: <4.3.2.7.2.20041220090706.02c22458@jaws.cisco.com> <4.3.2.7.2.20041220090706.02c22458@jaws.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org In that case, no MAC address is used because there's no Ethernet header. At 04:22 AM 12/20/2004, Abhishek Verma wrote: >> >> When you say ALL p2p communication, you presumably mean all p2p over >> broadcast medium. Of course, conventional p2p uses the mechanism specified >> in ISO/IEC 10589. > >I'm sorry i meant ISIS over p2p links (ATM/FR/OC/etc). > >Abhishek. > >> >> Mike >> >> >> >Is my assumption and reasoning correct? >> > >> >Thanks, >> >Abhishek >> > >> >-- >> >Class of 2004 >> >Institute of Technology, BHU >> >Varanasi, India >> > >> >_______________________________________________ >> >Isis-wg mailing list >> >Isis-wg@ietf.org >> >https://www1.ietf.org/mailman/listinfo/isis-wg >> > > >-- > >-- >Class of 2004 >Institute of Technology, BHU >Varanasi, India > >_______________________________________________ >Isis-wg mailing list >Isis-wg@ietf.org >https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Fri Dec 24 07:03:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09835 for ; Fri, 24 Dec 2004 07:03:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cho9G-0001GO-As; Fri, 24 Dec 2004 07:02:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cho7U-0000yp-Tk for isis-wg@megatron.ietf.org; Fri, 24 Dec 2004 07:00:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09607 for ; Fri, 24 Dec 2004 07:00:29 -0500 (EST) Received: from rproxy.gmail.com ([64.233.170.206]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ChoHY-0000up-VY for isis-wg@ietf.org; Fri, 24 Dec 2004 07:10:58 -0500 Received: by rproxy.gmail.com with SMTP id g11so21926rne for ; Fri, 24 Dec 2004 04:00:28 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=aePQbc/nixzNFrfIhjtAg2TQFPVYk+Mg61qRuYVW0zGTQrwCAtTe2laI2xkexeI3uQ6AB0wo1L2PUmgJbLtejzFL3pN/xltfcLd85w7qSb29aDQvkvmOqTGtXaMA4rB5RQvmOKYcrtT2KhOcpc1Lmh2gaU9IT096n6+jiBC5BF4= Received: by 10.38.12.35 with SMTP id 35mr92968rnl; Fri, 24 Dec 2004 04:00:28 -0800 (PST) Received: by 10.38.102.34 with HTTP; Fri, 24 Dec 2004 04:00:28 -0800 (PST) Message-ID: Date: Fri, 24 Dec 2004 17:30:28 +0530 From: Abhishek Verma To: "ISIS-WG (E-mail)" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Subject: [Isis-wg] L1/L2 X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Abhishek Verma List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi, By default we create two separate L1 and L2 adjacencies on Broadcast media. Is there a reason why we dont do that on p2p links such as T1, T3 etc. I see that we create only one L1/L2 adjacency in case of p2p links. Is this the expected behavior? Abhishek. -- Class of 2004 Institute of Technology, BHU Varanasi, India _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Fri Dec 24 09:52:52 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19992 for ; Fri, 24 Dec 2004 09:52:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Chqmj-0007qn-Mz; Fri, 24 Dec 2004 09:51:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Chql0-0007Xg-GI for isis-wg@megatron.ietf.org; Fri, 24 Dec 2004 09:49:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19897 for ; Fri, 24 Dec 2004 09:49:28 -0500 (EST) Received: from anthrax.middlebury.edu ([140.233.2.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Chqv5-0004Ie-Sj for isis-wg@ietf.org; Fri, 24 Dec 2004 09:59:57 -0500 Received: from arcticcat.middlebury.edu [140.233.2.8] by anthrax.middlebury.edu with XWall v3.31 ; Fri, 24 Dec 2004 09:48:53 -0500 Received: from GRASSHOPPER.middlebury.edu ([140.233.2.6]) by arcticcat.middlebury.edu with Microsoft SMTPSVC(5.0.2195.6713); Fri, 24 Dec 2004 09:48:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Subject: [Isis-wg] isisAreaAddr and isisManAreaAddr tables Date: Fri, 24 Dec 2004 09:48:53 -0500 Message-ID: <664FBBD972927F499753DB2E44E2430C3AD23A@grasshopper.middlebury.edu> Thread-Topic: [Isis-wg] L1/L2 Thread-Index: AcTpsvnI06HiELzuRZCiNTcPQ3y3lAAEwGvl From: "Parker, Jeff" To: "ISIS-WG \(E-mail\)" X-OriginalArrivalTime: 24 Dec 2004 14:48:53.0437 (UTC) FILETIME=[B00926D0:01C4E9C7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable In the apocryphal version 17 of the IS-IS Mib, which was written, = reviewed, submitted, but never published, I had combined the = isisAreaAddr and isisManAreaAddr tables. I've been asked to review = this. =20 Here was my original motivation "I get a warning/error in my compiler so will ask on the mibs list about this, it could be the compiler. In any case, I prefer one table with an additional object to denote manual/learned, but can = see that we don't agree on this point ;) so 2 tables are acceptable." Jon H. points out that: > With regards to the isisAreaAddr and isisManAreaAddr table, I still > believe that they are correct as they are at present. The tables=20 > should be separate, because the two tables perform different = functions. =20 > There should be no compiler problems with the isisAreaAddr table - a > read-only index is allowed by SMIv2 if the object is the only one in=20 > the table (see for example, RFC2578, 7.7: > > "(2) a conceptual row must contain at least one columnar object which = is > not an auxiliary object. In the event that all of a conceptual > row's columnar objects are also specified in its INDEX clause, = then > one of them must be accessible, i.e., have a MAX-ACCESS clause = of > "read-only". (Note that this situation does not arise for a > conceptual row allowing create access, since such a row will = have a > status column which will not be an auxiliary object.)" =20 I will rewind to the version of the tables in 16, and respin version 18 = for review, probably in the new year. - jeff parker _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Dec 28 06:22:54 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16298 for ; Tue, 28 Dec 2004 06:22:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjFJs-0003Uj-0c; Tue, 28 Dec 2004 06:15:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjFBK-0000VU-U8 for isis-wg@megatron.ietf.org; Tue, 28 Dec 2004 06:06:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15071 for ; Tue, 28 Dec 2004 06:06:23 -0500 (EST) Received: from rproxy.gmail.com ([64.233.170.205]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjFMD-0006kH-Rt for isis-wg@ietf.org; Tue, 28 Dec 2004 06:17:43 -0500 Received: by rproxy.gmail.com with SMTP id c16so294070rne for ; Tue, 28 Dec 2004 03:06:20 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=m62+zVuFdPyfPT5dTBE2gBNzgE0oIZXQ9a5UHghGXSgcJ6Sf3YczDuqZRU6j9wuUoI7FifqgMtvfCoGHmLu+qNgc6sB5B7Ubyx1rmoFNgWgxLEsvlcatF1/0IayFO38Sjh1qdyIBPRSG/mlXfjjtdohLRP2ECpQpuh4tllTouMc= Received: by 10.38.67.76 with SMTP id p76mr81620rna; Tue, 28 Dec 2004 03:06:20 -0800 (PST) Received: by 10.38.102.34 with HTTP; Tue, 28 Dec 2004 03:06:20 -0800 (PST) Message-ID: Date: Tue, 28 Dec 2004 16:36:20 +0530 From: Abhishek Verma To: "ISIS-WG (E-mail)" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Strange p2p adjacencies X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Abhishek Verma List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi, In broadcast media by default we form both L1 and L2 adjacencies and never one L1/L2 adjacency. So we can have 2 kinds of adjacencies in broadcast media - L1 only and L2 only. Two routers can either have any one of these or both of these. But why in point-to-point do we have either (i) L1 only (ii) L2 only and (iii) L1/L2. Why dont we have two adjacencies L1 and L2 between two p2p links? Why do we have just one L1/L2 adjacency? Would love to get some idea! Thanks, Abhishek V. -- Class of 2004 Institute of Technology, BHU Varanasi, India _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Dec 28 07:24:06 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20420 for ; Tue, 28 Dec 2004 07:24:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjGGk-0008FI-5b; Tue, 28 Dec 2004 07:16:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjGGM-00085h-V9 for isis-wg@megatron.ietf.org; Tue, 28 Dec 2004 07:15:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19842 for ; Tue, 28 Dec 2004 07:15:39 -0500 (EST) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjGRC-0008QA-JC for isis-wg@ietf.org; Tue, 28 Dec 2004 07:26:59 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0I9F00J11M1N43@szxga02-in.huawei.com> for isis-wg@ietf.org; Tue, 28 Dec 2004 20:15:23 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0I9F00ELAM1NM9@szxga02-in.huawei.com> for isis-wg@ietf.org; Tue, 28 Dec 2004 20:15:23 +0800 (CST) Received: from hemanthbs ([10.18.4.114]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0I9F002XVM1K57@szxml02-in.huawei.com> for isis-wg@ietf.org; Tue, 28 Dec 2004 20:15:21 +0800 (CST) Date: Tue, 28 Dec 2004 17:51:29 +0530 From: hemanthbs Subject: RE: [Isis-wg] Strange p2p adjacencies In-reply-to: To: "'ISIS-WG (E-mail)'" Message-id: <000001c4ecd7$c2da32a0$7204120a@in.huawei.com> Organization: htipl MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.4024 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7BIT X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hemanthbs@huawei.com List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: 7BIT Hi, To answer your question in the simplest way, the ISIS protocol (10589) defines only one Hello PDU for P2P, ie we have L1 LAN IIH(TYPE 15), L2 LAN IIH(TYPE 16) but only one P2P IIH (TYPE 17). i.e we send only one type of hello on a P2P network I hope this answers your question. S.Hemanth Balaji. Software Engineer. Huawei Technologies India Pvt LTd, Bangalore. -----Original Message----- From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org] On Behalf Of Abhishek Verma Sent: Tuesday, December 28, 2004 4:36 PM To: ISIS-WG (E-mail) Subject: [Isis-wg] Strange p2p adjacencies Hi, In broadcast media by default we form both L1 and L2 adjacencies and never one L1/L2 adjacency. So we can have 2 kinds of adjacencies in broadcast media - L1 only and L2 only. Two routers can either have any one of these or both of these. But why in point-to-point do we have either (i) L1 only (ii) L2 only and (iii) L1/L2. Why dont we have two adjacencies L1 and L2 between two p2p links? Why do we have just one L1/L2 adjacency? Would love to get some idea! Thanks, Abhishek V. -- Class of 2004 Institute of Technology, BHU Varanasi, India _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Dec 28 08:00:42 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22912 for ; Tue, 28 Dec 2004 08:00:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjGvi-00026P-0y; Tue, 28 Dec 2004 07:58:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjGuE-0001Rb-Ni for isis-wg@megatron.ietf.org; Tue, 28 Dec 2004 07:56:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22617 for ; Tue, 28 Dec 2004 07:56:53 -0500 (EST) Received: from rproxy.gmail.com ([64.233.170.206]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjH58-0001AS-L4 for isis-wg@ietf.org; Tue, 28 Dec 2004 08:08:11 -0500 Received: by rproxy.gmail.com with SMTP id c16so301185rne for ; Tue, 28 Dec 2004 04:56:52 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=i1u5BuJI8CnNeqL43JpaisCr1wC0cSC+AoQb1o2IdxCMU7jdgf2ZZfmKD8+6xo7dwmp1PFAdeUf+3+GOaDb3G2kpY+T/k8dpjh9kzrI1nIhpzV9YU7Nkbp0st1lqfEbACXxsZyaRvHcM6VsRbKg4EldopBUl5WR+dPQMabjU+ec= Received: by 10.38.22.69 with SMTP id 69mr115604rnv; Tue, 28 Dec 2004 04:56:52 -0800 (PST) Received: by 10.38.102.34 with HTTP; Tue, 28 Dec 2004 04:56:52 -0800 (PST) Message-ID: Date: Tue, 28 Dec 2004 18:26:52 +0530 From: Abhishek Verma To: hemanthbs@huawei.com Subject: Re: [Isis-wg] Strange p2p adjacencies In-Reply-To: <000001c4ecd7$c2da32a0$7204120a@in.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <000001c4ecd7$c2da32a0$7204120a@in.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Cc: "ISIS-WG \(E-mail\)" X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Abhishek Verma List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: 7bit Hemanth, This tells me why we can have only one kind of adjacency in P2P links. And thanks for that! But why is this so? Why has ISIS been so designed? Why do we then have 2 kinds of adjacencies in Broadcast media? Any clues? Thanks, Abhishek. > To answer your question in the simplest way, > the ISIS protocol (10589) defines only one Hello PDU for P2P, > ie we have L1 LAN IIH(TYPE 15), L2 LAN IIH(TYPE 16) but only one P2P > IIH (TYPE 17). > > i.e we send only one type of hello on a P2P network > > I hope this answers your question. > > S.Hemanth Balaji. > Software Engineer. > Huawei Technologies India Pvt LTd, Bangalore. > > > -----Original Message----- > From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org] On > Behalf Of Abhishek Verma > Sent: Tuesday, December 28, 2004 4:36 PM > To: ISIS-WG (E-mail) > Subject: [Isis-wg] Strange p2p adjacencies > > Hi, > > In broadcast media by default we form both L1 and L2 adjacencies and > never one L1/L2 adjacency. So we can have 2 kinds of adjacencies in > broadcast media - L1 only and L2 only. Two routers can either have any > one of these or both of these. > > But why in point-to-point do we have either (i) L1 only (ii) L2 only > and (iii) L1/L2. > > Why dont we have two adjacencies L1 and L2 between two p2p links? Why > do we have just one L1/L2 adjacency? > > Would love to get some idea! > > Thanks, > Abhishek V. > -- > Class of 2004 > Institute of Technology, BHU > Varanasi, India > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg > -- -- Class of 2004 Institute of Technology, BHU Varanasi, India _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Dec 28 08:26:48 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25784 for ; Tue, 28 Dec 2004 08:26:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjHIC-000780-4f; Tue, 28 Dec 2004 08:21:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjHEb-0005q3-Pq for isis-wg@megatron.ietf.org; Tue, 28 Dec 2004 08:17:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25068 for ; Tue, 28 Dec 2004 08:17:56 -0500 (EST) Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjHPQ-0001u7-SA for isis-wg@ietf.org; Tue, 28 Dec 2004 08:29:15 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0I9F00M6NOVSRU@szxga03-in.huawei.com> for isis-wg@ietf.org; Tue, 28 Dec 2004 21:16:40 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0I9F00AVDOVRD0@szxga03-in.huawei.com> for isis-wg@ietf.org; Tue, 28 Dec 2004 21:16:39 +0800 (CST) Received: from hemanthbs ([10.18.4.114]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0I9F00MMUP1T5L@szxml01-in.huawei.com>; Tue, 28 Dec 2004 21:20:18 +0800 (CST) Date: Tue, 28 Dec 2004 18:53:50 +0530 From: hemanthbs Subject: RE: [Isis-wg] Strange p2p adjacencies In-reply-to: To: "'Abhishek Verma'" Message-id: <000101c4ece0$78b0f930$7204120a@in.huawei.com> Organization: htipl MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.4024 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: 7BIT Cc: "'ISIS-WG \(E-mail\)'" X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hemanthbs@huawei.com List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: 7BIT Hi, On a Broad cast network(LAN), some routers can be only L1 or only L2. Or you might want to form only L1 adj with some routers, only L2 with some others and both L1L2 with some others, in which case the need for 2 separate IIH's (L1 & L2) is justified, instead of sending one single L1L2 packet (which will be redundant). On a P2P interface, since there is only one router(peer) connected to you on that link, one can be sure that , the peer can be one of the 3 types only (either L1 , or L2 or L1L2), Hence only one type of packet would do the job for P2P link. Hope this answers your questions,,, Bye. S.Hemanth Balaji. Software Engineer. Huawei Technologies India Pvt Ltd. Bangalore, India. -----Original Message----- From: Abhishek Verma [mailto:abhishekv.verma@gmail.com] Sent: Tuesday, December 28, 2004 6:27 PM To: hemanthbs@huawei.com Cc: ISIS-WG (E-mail) Subject: Re: [Isis-wg] Strange p2p adjacencies Hemanth, This tells me why we can have only one kind of adjacency in P2P links. And thanks for that! But why is this so? Why has ISIS been so designed? Why do we then have 2 kinds of adjacencies in Broadcast media? Any clues? Thanks, Abhishek. > To answer your question in the simplest way, > the ISIS protocol (10589) defines only one Hello PDU for P2P, > ie we have L1 LAN IIH(TYPE 15), L2 LAN IIH(TYPE 16) but only one P2P > IIH (TYPE 17). > > i.e we send only one type of hello on a P2P network > > I hope this answers your question. > > S.Hemanth Balaji. > Software Engineer. > Huawei Technologies India Pvt LTd, Bangalore. > > > -----Original Message----- > From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org] On > Behalf Of Abhishek Verma > Sent: Tuesday, December 28, 2004 4:36 PM > To: ISIS-WG (E-mail) > Subject: [Isis-wg] Strange p2p adjacencies > > Hi, > > In broadcast media by default we form both L1 and L2 adjacencies and > never one L1/L2 adjacency. So we can have 2 kinds of adjacencies in > broadcast media - L1 only and L2 only. Two routers can either have any > one of these or both of these. > > But why in point-to-point do we have either (i) L1 only (ii) L2 only > and (iii) L1/L2. > > Why dont we have two adjacencies L1 and L2 between two p2p links? Why > do we have just one L1/L2 adjacency? > > Would love to get some idea! > > Thanks, > Abhishek V. > -- > Class of 2004 > Institute of Technology, BHU > Varanasi, India > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg > -- -- Class of 2004 Institute of Technology, BHU Varanasi, India _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Dec 28 08:44:48 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26592 for ; Tue, 28 Dec 2004 08:44:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjHTW-0001Ib-Li; Tue, 28 Dec 2004 08:33:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjHSg-00016X-RW for isis-wg@megatron.ietf.org; Tue, 28 Dec 2004 08:32:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26141 for ; Tue, 28 Dec 2004 08:32:29 -0500 (EST) Received: from rproxy.gmail.com ([64.233.170.192]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjHdb-0002IW-Vg for isis-wg@ietf.org; Tue, 28 Dec 2004 08:43:48 -0500 Received: by rproxy.gmail.com with SMTP id c16so303500rne for ; Tue, 28 Dec 2004 05:32:29 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=rOp3XVS+ZyDCdnG6pdhVsrTAYXXYFQ/61HDKqAcyE9ffKlWA+07sjN6YEqIEXEhzHWGKYHYXjE1SfsoArHw+UHHy1GkyY+RDx46vKA3C5XzNK4CHtrSXj6ekhhBxRUsyOB7HxLC2CDvgtj8+M7v0QkZ+yvsfs96T/07FUiHh4D4= Received: by 10.38.155.16 with SMTP id c16mr125450rne; Tue, 28 Dec 2004 05:32:29 -0800 (PST) Received: by 10.38.102.34 with HTTP; Tue, 28 Dec 2004 05:32:29 -0800 (PST) Message-ID: Date: Tue, 28 Dec 2004 19:02:29 +0530 From: Abhishek Verma To: hemanthbs@huawei.com Subject: Re: [Isis-wg] Strange p2p adjacencies In-Reply-To: <000101c4ece0$78b0f930$7204120a@in.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <000101c4ece0$78b0f930$7204120a@in.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: 7bit Cc: "ISIS-WG \(E-mail\)" X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Abhishek Verma List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: 7bit Thanks Hemanth .. It certainly does! Abhishek On Tue, 28 Dec 2004 18:53:50 +0530, hemanthbs wrote: > > > Hi, > > On a Broad cast network(LAN), some routers can be only L1 or only L2. > Or you might want to form only L1 adj with some routers, only L2 with > some others and both L1L2 with some others, in which case the need for 2 > separate IIH's (L1 & L2) is justified, instead of sending one single > L1L2 packet (which will be redundant). > On a P2P interface, since there is only one router(peer) connected > to you on that link, one can be sure that , the peer can be one of the 3 > types only (either L1 , or L2 or L1L2), > Hence only one type of packet would do the job for P2P link. > > Hope this answers your questions,,, > > Bye. > S.Hemanth Balaji. > Software Engineer. > Huawei Technologies India Pvt Ltd. > Bangalore, India. > > -----Original Message----- > From: Abhishek Verma [mailto:abhishekv.verma@gmail.com] > Sent: Tuesday, December 28, 2004 6:27 PM > To: hemanthbs@huawei.com > Cc: ISIS-WG (E-mail) > Subject: Re: [Isis-wg] Strange p2p adjacencies > > Hemanth, > > This tells me why we can have only one kind of adjacency in P2P links. > And thanks for that! > > But why is this so? Why has ISIS been so designed? Why do we then have > 2 kinds of adjacencies in Broadcast media? > > Any clues? > > Thanks, > Abhishek. > > > To answer your question in the simplest way, > > the ISIS protocol (10589) defines only one Hello PDU for P2P, > > ie we have L1 LAN IIH(TYPE 15), L2 LAN IIH(TYPE 16) but only one P2P > > IIH (TYPE 17). > > > > i.e we send only one type of hello on a P2P network > > > > I hope this answers your question. > > > > S.Hemanth Balaji. > > Software Engineer. > > Huawei Technologies India Pvt LTd, Bangalore. > > > > > > -----Original Message----- > > From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org] On > > Behalf Of Abhishek Verma > > Sent: Tuesday, December 28, 2004 4:36 PM > > To: ISIS-WG (E-mail) > > Subject: [Isis-wg] Strange p2p adjacencies > > > > Hi, > > > > In broadcast media by default we form both L1 and L2 adjacencies and > > never one L1/L2 adjacency. So we can have 2 kinds of adjacencies in > > broadcast media - L1 only and L2 only. Two routers can either have any > > one of these or both of these. > > > > But why in point-to-point do we have either (i) L1 only (ii) L2 only > > and (iii) L1/L2. > > > > Why dont we have two adjacencies L1 and L2 between two p2p links? Why > > do we have just one L1/L2 adjacency? > > > > Would love to get some idea! > > > > Thanks, > > Abhishek V. > > -- > > Class of 2004 > > Institute of Technology, BHU > > Varanasi, India > > > > _______________________________________________ > > Isis-wg mailing list > > Isis-wg@ietf.org > > https://www1.ietf.org/mailman/listinfo/isis-wg > > > > _______________________________________________ > > Isis-wg mailing list > > Isis-wg@ietf.org > > https://www1.ietf.org/mailman/listinfo/isis-wg > > > > -- > > -- > Class of 2004 > Institute of Technology, BHU > Varanasi, India > > -- -- Class of 2004 Institute of Technology, BHU Varanasi, India _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg