Balaji, Hemanth | 1 Jul 06:40 2005

Regarding ATT bit

Hi,

 

 I have doubt regarding the setting of ATT bit when multiple areas are involved. Consider the below situation,

 

      +----------------------------- R1 -------------------------+

       |                                               |                                          |

       |                                               |                                          | 

       |                                               |                                          |  

       |                                               |                                          |   

     R2 --------------------------- R4 ------------------------ R3

 

R2 is an L1 router, all others are L1L2 routers.

All routers belong to 2 areas 49 & 50.

 

Should R1 and R4 set the ATT bit in their L1 LSPs.???

 

It would be really helpful if anyone can explain this scenario.

 

 

Thanks,

Hemanth.

 

 

 

S.Hemanth Balaji.

Member-Technical Staff

Riverstone Networks India Pvt Ltd,

Ph: +91-80-51131932 extn 292

hbalaji <at> riverstonenet.com

 

“You and your Mind are disparate entities.”

 

_______________________________________________
Isis-wg mailing list
Isis-wg <at> ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg
Paresh Khatri | 1 Jul 06:53 2005
Picon

RE: Regarding ATT bit

Hi Hemanth,
 
I believe the ATT bit should only be set if the L1/2 router has an L2 link to another area.  In your case, despite the fact that all your routers have 2 NETs configured, they all still belong to the same area (since all of the routers are configured with the same 2 area addresses).  The 2 NETs serve to merge the logical areas described by each area address, and do not create two separate areas.  The system parameter 'areaAddresses' (as defined by ISO10589) would include both area addresses in each of your routers.  So neither R1 nor R4 should set the ATT bit.
 
HTH,
Paresh.
-----Original Message-----
From: isis-wg-bounces <at> ietf.org [mailto:isis-wg-bounces <at> ietf.org]On Behalf Of Balaji, Hemanth
Sent: Friday, 01 July 2005 02:41 PM
To: isis-wg <at> ietf.org
Subject: [Isis-wg] Regarding ATT bit

Hi,

 

 I have doubt regarding the setting of ATT bit when multiple areas are involved. Consider the below situation,

 

      +----------------------------- R1 -------------------------+

       |                                               |                                          |

       |                                               |                                          | 

       |                                               |                                          |  

       |                                               |                                          |   

     R2 --------------------------- R4 ------------------------ R3

 

R2 is an L1 router, all others are L1L2 routers.

All routers belong to 2 areas 49 & 50.

 

Should R1 and R4 set the ATT bit in their L1 LSPs.???

 

It would be really helpful if anyone can explain this scenario.

 

 

Thanks,

Hemanth.

 

 

 

S.Hemanth Balaji.

Member-Technical Staff

Riverstone Networks India Pvt Ltd,

Ph: +91-80-51131932 extn 292

hbalaji <at> riverstonenet.com

 

“You and your Mind are disparate entities.”

 

This communication, including any attachments, is confidential. If
you are not the intended recipient, you should not read it - please
contact me immediately, destroy it, and do not copy or use any part of
this communication or disclose anything about it.

_______________________________________________
Isis-wg mailing list
Isis-wg <at> ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg
stefano previdi | 1 Jul 14:51 2005
Picon

Re: Regarding ATT bit

On Jul 1, 2005, at 6:53 AM, Paresh Khatri wrote:
> Hi Hemanth,
>  
> I believe the ATT bit should only be set if the L1/2 router has an L2 
> link to another area. 

I wouldn't be so strict...

I would set the ATT bit if in the level-2 lsdb there
is at least one area other than the one(s) the router
is configured into (which is different from having a
link to another area).

Anyway, in the example below no ATT bit has to be set.

>  In your case, despite the fact that all your routers have 2 NETs 
> configured, they all still belong to the same area (since all of the 
> routers are configured with the same 2 area addresses).  The 2 NETs 
> serve to merge the logical areas described by each area address, and 
> do not create two separate areas. 

that is correct.

s.

>  The system parameter 'areaAddresses' (as defined by ISO10589) would 
> include both area addresses in each of your routers.  So neither R1 
> nor R4 should set the ATT bit.
>  
> HTH,
> Paresh.
>> -----Original Message-----
>> From: isis-wg-bounces <at> ietf.org [mailto:isis-wg-bounces <at> ietf.org]On 
>> Behalf Of Balaji, Hemanth
>> Sent: Friday, 01 July 2005 02:41 PM
>> To: isis-wg <at> ietf.org
>> Subject: [Isis-wg] Regarding ATT bit
>>
>> Hi,
>>  
>>  I have doubt regarding the setting of ATT bit when multiple areas 
>> are involved. Consider the below situation,
>>  
>>       +----------------------------- R1 -------------------------+
>>        |                                     
         |  
>>                                         |
>>      
 |                                               
>> |                                          | 
>>        |                                     
         | 
>>                                          |  
>>        | 
                                             |  
>>                                         |   
>>      R2 --------------------------- R4 ------------------------ R3
>>  
>> R2 is an L1 router, all others are L1L2 routers.
>> All routers belong to 2 areas 49 & 50.
>>  
>> Should R1 and R4 set the ATT bit in their L1 LSPs.???
>>  
>> It would be really helpful if anyone can explain this scenario.
>>  
>>  
>> Thanks,
>> Hemanth.
>>  
>>  
>> <unknown.jpg> 
>> S.Hemanth Balaji.
>> Member-Technical Staff
>> Riverstone Networks India Pvt Ltd,
>> Ph: +91-80-51131932 extn 292
>> hbalaji <at> riverstonenet.com
>>  
>> “You and your Mind are disparate entities.”
>>  This communication, including any attachments, is confidential. If
>  you are not the intended recipient, you should not read it - please
>  contact me immediately, destroy it, and do not copy or use any part of
>  this communication or disclose anything about it.
>
_______________________________________________
> Isis-wg mailing list
> Isis-wg <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/isis-wg
_______________________________________________
Isis-wg mailing list
Isis-wg <at> ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg
mike shand | 1 Jul 15:16 2005
Picon

Re: Regarding ATT bit

At 13:51 01/07/2005, stefano previdi wrote:
>On Jul 1, 2005, at 6:53 AM, Paresh Khatri wrote:
>>Hi Hemanth,
>>
>>I believe the ATT bit should only be set if the L1/2 router has an L2 
>>link to another area.
>
>I wouldn't be so strict...
>
>I would set the ATT bit if in the level-2 lsdb there
>is at least one area other than the one(s) the router
>is configured into (which is different from having a
>link to another area).

Stefano is correct. It is perfectly clear in ISO/IEC 10589 (this clip from 
second edition) when you understand that areas are not the same thing as 
area addresses, and a single area can have multiple area addresses.

7.2.9.2 Setting the attached flag in level 2 intermediate systems
When executing the level 2 decision process for each supported metric, 
level 2 IS shall ascertain whether or not it can reach any destinations 
outside its area using that metric. The IS considers itself attached if either:
a) it can reach at least one other area using the coresponding routeing 
metric, or
b) it has at least one enabled reachable address prefix with the 
corresponding metric defined.
Otherwise the IS considers itself not attached.

Mike

>Anyway, in the example below no ATT bit has to be set.
>
>>  In your case, despite the fact that all your routers have 2 NETs 
>> configured, they all still belong to the same area (since all of the 
>> routers are configured with the same 2 area addresses).  The 2 NETs 
>> serve to merge the logical areas described by each area address, and do 
>> not create two separate areas.
>
>that is correct.
>
>s.
>
>>  The system parameter 'areaAddresses' (as defined by ISO10589) would 
>> include both area addresses in each of your routers.  So neither R1 nor 
>> R4 should set the ATT bit.
>>
>>HTH,
>>Paresh.
>>>-----Original Message-----
>>>From: isis-wg-bounces <at> ietf.org [mailto:isis-wg-bounces <at> ietf.org]On 
>>>Behalf Of Balaji, Hemanth
>>>Sent: Friday, 01 July 2005 02:41 PM
>>>To: isis-wg <at> ietf.org
>>>Subject: [Isis-wg] Regarding ATT bit
>>>
>>>Hi,
>>>
>>>  I have doubt regarding the setting of ATT bit when multiple areas are 
>>> involved. Consider the below situation,
>>>
>>>       +----------------------------- R1 -------------------------+
>>>        |                                               | 
 >>>                           |
>>>        |                                               | 
 >>>                           |
>>>        |                                               | 
 >>>                           |
>>>        |                                               | 
 >>>                           |
>>>      R2 --------------------------- R4 ------------------------ R3
>>>
>>>R2 is an L1 router, all others are L1L2 routers.
>>>All routers belong to 2 areas 49 & 50.
>>>
>>>Should R1 and R4 set the ATT bit in their L1 LSPs.???
>>>
>>>It would be really helpful if anyone can explain this scenario.
>>>
>>>
>>>Thanks,
>>>Hemanth.
>>>
>>>
>>><unknown.jpg>
>>>S.Hemanth Balaji.
>>>Member-Technical Staff
>>>Riverstone Networks India Pvt Ltd,
>>>Ph: +91-80-51131932 extn 292
>>>hbalaji <at> riverstonenet.com
>>>
>>>"You and your Mind are disparate entities."
>>>  This communication, including any attachments, is confidential. If
>>  you are not the intended recipient, you should not read it - please
>>  contact me immediately, destroy it, and do not copy or use any part of
>>  this communication or disclose anything about it.
>
>
>
>_______________________________________________
>>Isis-wg mailing list
>>Isis-wg <at> ietf.org
>>https://www1.ietf.org/mailman/listinfo/isis-wg
>
>
>_______________________________________________
>Isis-wg mailing list
>Isis-wg <at> ietf.org
>https://www1.ietf.org/mailman/listinfo/isis-wg
Parker, Jeff | 7 Jul 19:12 2005

Edits to version 21

I have made the following changes to the mib and run this by Joan and Mike
Heard.  The changes include

    0) Changed the name of isisSysType to isisSysLevelType
    1) Remove isisCircIfSubSelector
    2) Reword descriptions for
        a) isisSysLevelSetOverloadUntil
        b) isisCircLastUpTime
        c) isisISAdjLastUpTime

I believe that this addresses the issues that Joan and Mike have recently
raised. 

If there are no further issues, I will respin and resubmit as version 22.

- jeff parker

myrmidon:~/MIB jeff$ diff mib.21 mib
...
310c306
<     isisSysType OBJECT-TYPE
---
>     isisSysLevelType OBJECT-TYPE
1022,1023c1018,1019
<              the overload bit when isisSysLevelSetOverloadUntil
<              jave elapsed, if the system has not run out of memory."
---
>              the overload bit when isisSysLevelSetOverloadUntil seconds
>              have elapsed, if the system has not run out of memory."
1114,1115d1109
<             isisCircIfSubSelector
<                 Unsigned32,
1166,1181d1159
<     isisCircIfSubSelector OBJECT-TYPE
<         SYNTAX Unsigned32
<         MAX-ACCESS read-create
<         STATUS current
<         DESCRIPTION
<             "A specifier for the part of the interface ifIndex to which
<              this circuit corresponds, such as a DLCI or VPI/VCI.
<              If an implementation uses a single ifIndex for distinct
<              IS-IS circuits, the isisCircIfSubSelector may be used
<              to distinguish them.  This object cannot be modified after
<              creation.
< 
<              Holds 0 if not used."
<         DEFVAL { 0 }
<     ::= { isisCircEntry 3 }
< 
1189c1167
<     ::= { isisCircEntry 4 }
---
>     ::= { isisCircEntry 3 }
1205c1183
<     ::= { isisCircEntry 5 }
---
>     ::= { isisCircEntry 4 }
1224c1202
<     ::= { isisCircEntry 6 }
---
>     ::= { isisCircEntry 5 }
1236c1214
<     ::= { isisCircEntry 7 }
---
>     ::= { isisCircEntry 6 }
1246c1224
<              the settings of isisSysType. Thus if the
---
>              the settings of isisSysLevelType. Thus if the
1252c1230
<     ::= { isisCircEntry 8 }
---
>     ::= { isisCircEntry 7 }
1262c1240
<     ::= { isisCircEntry 9 }
---
>     ::= { isisCircEntry 8 }
1281c1259
<     ::= { isisCircEntry 10 }
---
>     ::= { isisCircEntry 9 }
1294c1272
<     ::= { isisCircEntry 11 }
---
>     ::= { isisCircEntry 10 }
1307c1285
<     ::= { isisCircEntry 12 }
---
>     ::= { isisCircEntry 11 }
1314,1316c1292,1294
<             "If the circuit is enabled, the number of seconds
<              since system startup when isisCircAdminState most
<              recently entered the state 'on', or 0 if the
---
>             "How long the circuit has been enabled, measured in
>              hundredths of seconds since the last re-initialization
>              of the network management subsystem, or 0 if the
1318c1296
<     ::= { isisCircEntry 13 }
---
>     ::= { isisCircEntry 12 }
1327c1305
<     ::= { isisCircEntry 14 }
---
>     ::= { isisCircEntry 13 }
1338c1316
<     ::= { isisCircEntry 15 }
---
>     ::= { isisCircEntry 14 }
2259,2260c2237,2239
<             "The number of seconds since system startup when
<              the adjacency most recently entered the state 'up'.
---
>             "When the adjacency most recently entered the state 'up',
>              measured in hundredths of a second since the last
>              re-initialization of the network management subsystem.
3829c3808
<        OBJECT isisSysType
---
>        OBJECT isisSysLevelType
3939,3943d3917
<        OBJECT isisCircIfSubSelector
<        MIN-ACCESS read-only
<        DESCRIPTION
<             "Write access is not required."
< 
4061c4035
<             isisSysType,
---
>             isisSysLevelType,
4111d4084
<             isisCircIfSubSelector,
jcucchiara | 8 Jul 17:07 2005
Picon

Re: Edits to version 21


Jeff,

These diffs look like they address my comments.

  Thanks, 
   -Joan

At 01:12 PM 7/7/05 -0400, Parker, Jeff wrote:
>I have made the following changes to the mib and run this by Joan and Mike
>Heard.  The changes include
>
>    0) Changed the name of isisSysType to isisSysLevelType
>    1) Remove isisCircIfSubSelector
>    2) Reword descriptions for
>        a) isisSysLevelSetOverloadUntil
>        b) isisCircLastUpTime
>        c) isisISAdjLastUpTime
>
>I believe that this addresses the issues that Joan and Mike have recently
>raised. 
>
>If there are no further issues, I will respin and resubmit as version 22.
>
>- jeff parker
>
>
>myrmidon:~/MIB jeff$ diff mib.21 mib
>...
>310c306
><     isisSysType OBJECT-TYPE
>---
>>     isisSysLevelType OBJECT-TYPE
>1022,1023c1018,1019
><              the overload bit when isisSysLevelSetOverloadUntil
><              jave elapsed, if the system has not run out of memory."
>---
>>              the overload bit when isisSysLevelSetOverloadUntil seconds
>>              have elapsed, if the system has not run out of memory."
>1114,1115d1109
><             isisCircIfSubSelector
><                 Unsigned32,
>1166,1181d1159
><     isisCircIfSubSelector OBJECT-TYPE
><         SYNTAX Unsigned32
><         MAX-ACCESS read-create
><         STATUS current
><         DESCRIPTION
><             "A specifier for the part of the interface ifIndex to which
><              this circuit corresponds, such as a DLCI or VPI/VCI.
><              If an implementation uses a single ifIndex for distinct
><              IS-IS circuits, the isisCircIfSubSelector may be used
><              to distinguish them.  This object cannot be modified after
><              creation.
>< 
><              Holds 0 if not used."
><         DEFVAL { 0 }
><     ::= { isisCircEntry 3 }
>< 
>1189c1167
><     ::= { isisCircEntry 4 }
>---
>>     ::= { isisCircEntry 3 }
>1205c1183
><     ::= { isisCircEntry 5 }
>---
>>     ::= { isisCircEntry 4 }
>1224c1202
><     ::= { isisCircEntry 6 }
>---
>>     ::= { isisCircEntry 5 }
>1236c1214
><     ::= { isisCircEntry 7 }
>---
>>     ::= { isisCircEntry 6 }
>1246c1224
><              the settings of isisSysType. Thus if the
>---
>>              the settings of isisSysLevelType. Thus if the
>1252c1230
><     ::= { isisCircEntry 8 }
>---
>>     ::= { isisCircEntry 7 }
>1262c1240
><     ::= { isisCircEntry 9 }
>---
>>     ::= { isisCircEntry 8 }
>1281c1259
><     ::= { isisCircEntry 10 }
>---
>>     ::= { isisCircEntry 9 }
>1294c1272
><     ::= { isisCircEntry 11 }
>---
>>     ::= { isisCircEntry 10 }
>1307c1285
><     ::= { isisCircEntry 12 }
>---
>>     ::= { isisCircEntry 11 }
>1314,1316c1292,1294
><             "If the circuit is enabled, the number of seconds
><              since system startup when isisCircAdminState most
><              recently entered the state 'on', or 0 if the
>---
>>             "How long the circuit has been enabled, measured in
>>              hundredths of seconds since the last re-initialization
>>              of the network management subsystem, or 0 if the
>1318c1296
><     ::= { isisCircEntry 13 }
>---
>>     ::= { isisCircEntry 12 }
>1327c1305
><     ::= { isisCircEntry 14 }
>---
>>     ::= { isisCircEntry 13 }
>1338c1316
><     ::= { isisCircEntry 15 }
>---
>>     ::= { isisCircEntry 14 }
>2259,2260c2237,2239
><             "The number of seconds since system startup when
><              the adjacency most recently entered the state 'up'.
>---
>>             "When the adjacency most recently entered the state 'up',
>>              measured in hundredths of a second since the last
>>              re-initialization of the network management subsystem.
>3829c3808
><        OBJECT isisSysType
>---
>>        OBJECT isisSysLevelType
>3939,3943d3917
><        OBJECT isisCircIfSubSelector
><        MIN-ACCESS read-only
><        DESCRIPTION
><             "Write access is not required."
>< 
>4061c4035
><             isisSysType,
>---
>>             isisSysLevelType,
>4111d4084
><             isisCircIfSubSelector,
>
>
>_______________________________________________
>Isis-wg mailing list
>Isis-wg <at> ietf.org
>https://www1.ietf.org/mailman/listinfo/isis-wg
>
Internet-Drafts | 11 Jul 21:50 2005
Picon

I-D ACTION:draft-ietf-isis-wg-mib-22.txt

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		: Management Information Base for IS-IS
	Author(s)	: J. Parker
	Filename	: draft-ietf-isis-wg-mib-22.txt
	Pages		: 101
	Date		: 2005-7-11
	
This document describes a management information base for the IS-IS
   Routing protocol when it is used to construct routing tables for IP
   networks.

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.

   This memo is based on an IETF draft by Chris Gunner.  This version
   has been modified to include MIB-II syntax, to exclude portions of
   the protocol that are not relevant to IP, such as the ES-IS protocol,
   and to add management support for current practice.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-mib-22.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-mib-22.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 <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-isis-wg-mib-22.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.
Attachment: message/external-body, 135 bytes
Attachment (draft-ietf-isis-wg-mib-22.txt): message/external-body, 69 bytes
_______________________________________________
Isis-wg mailing list
Isis-wg <at> ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg
C. M. Heard | 12 Jul 09:19 2005
Picon

Re: I-D ACTION:draft-ietf-isis-wg-mib-22.txt

On Mon, 11 Jul 2005 Internet-Drafts <at> ietf.org wrote:
> 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		: Management Information Base for IS-IS
> 	Author(s)	: J. Parker
> 	Filename	: draft-ietf-isis-wg-mib-22.txt
> 	Pages		: 101
> 	Date		: 2005-7-11
...
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-mib-22.txt

All of the outstanding MIB Doctor issues have been addressed.  As
far as I am concerned it's ready to be forwarded to the IESG.

Mike Heard
Christian Hopps | 12 Jul 22:47 2005

WG LC on draft-ietf-isis-wg-mib-22.txt

We are now in a "final final" WG LC on the MIB, please restrict any 
requests for modifications to changes made in the last revision. Given 
no more comments are received we will submit the MIB to the IESG 
immediately following the Paris IETF meeting.

Chris and Dave.

On Jul 12, 2005, at 12:19 AM, C. M. Heard wrote:
> All of the outstanding MIB Doctor issues have been addressed.  As
> far as I am concerned it's ready to be forwarded to the IESG.
>
> Mike Heard
>
>
> _______________________________________________
> Isis-wg mailing list
> Isis-wg <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/isis-wg
David Ward | 19 Jul 22:14 2005
Picon

Agenda requests IETF 63

All -

we are officially starting to gather agenda requests for the ISIS WG
meeting in Paris. The agenda needs to be ready by July 25th. So,
please, send your requests by the end of this week (Friday, July 22nd).

You should send your agenda request to the chairs indicating:

1) the topic you want to present
2) related Internet-Drafts
3) length of the requested agenda-slot

Thanks

Gmane