Jeff Parker | 3 Mar 2003 16:45

RE: draft-ietf-isis-wg-mib-11.txt


> Hi Jeff,
> 
> What does a value of "none" mean for the 
> isisLSPLevel, shouldn't the valid
> values be only L1 and L2? Or does this 
> mean irrespective of level?
> 
> Thanks,
> Vishwas

Vishwas -
	Looking at the MIB, this TC is used
a number of places where the level -is-
well defined, but it is also used in 
Notifications.  If, for example, you 
get a packet with a different version
number, you don't really know the level
of the packet, and would use "none" in
the notification.  

- jeff parker 
Manral, Vishwas | 3 Mar 2003 17:50

RE: draft-ietf-isis-wg-mib-11.txt

Jeff,

Are you saying that a value of "none" would be wrong in this particular
case?

Thanks,
Vishwas

-----Original Message-----
From: Jeff Parker [mailto:jparker <at> axiowave.com]
Sent: Monday, March 03, 2003 9:15 PM
To: 'Manral, Vishwas'
Cc: ISIS-WG (E-mail)
Subject: RE: draft-ietf-isis-wg-mib-11.txt

 
> Hi Jeff,
> 
> What does a value of "none" mean for the 
> isisLSPLevel, shouldn't the valid
> values be only L1 and L2? Or does this 
> mean irrespective of level?
> 
> Thanks,
> Vishwas

Vishwas -
	Looking at the MIB, this TC is used
a number of places where the level -is-
well defined, but it is also used in 
(Continue reading)

Les Ginsberg | 3 Mar 2003 18:22
Picon
Favicon

New Version of draft-ietf-isis-restart


Folks -

Mike Shand and I have submitted V3 of draft-ietf-isis-restart (V2 was 
withdrawn from last call at our request). Since we submitted it close to 
the deadline, it may take a while for the official announcement to appear.

In addition to making some clarifications based on review comments from the 
list, the new version includes the following changes:

1)We now make explicit that the LANID must be ignored in IIHs having the RR 
bit set. This is something that implementation experience shows is 
necessary. As it affects the bits on the wire (what is sent as LANID by 
neighbors of the restarting router) it seemed necessary to explicitly state 
this in the draft.

2)New functionality in the case of a starting (NOT restarting) router is 
defined to prevent the potential occurrence of transient blackholes due to 
the presence in the network of LSP fragments from a previous incarnation of 
the starting router.

3)The text in the draft has been restructured to more clearly show the 
commonalities and differences in behavior between the restarting and 
starting cases.

Finally, and MOST IMPORTANT, implementations based on the old version(V2) 
of the draft will interoperate with versions based on the new draft, though 
of course the new functionality will not be supported.

Cheers.
(Continue reading)

Tony Li | 3 Mar 2003 22:11

FW: IETF 56 Presentation Submissions


Would folks who are presenting, please make an effort to get their
presentations in ahead of time?

Thanks,
Tony

|    -----Original Message-----
|    From: IETF Proceedings Administrator [mailto:minutes <at> ietf.org] 
|    Sent: Monday, March 03, 2003 11:53 AM
|    To: wgchairs <at> ietf.org; bofchairs <at> ietf.org; Steve Coya
|    Subject: IETF 56 Presentation Submissions
|    
|    
|      This message is for all group chairs who will be meeting 
|    in San Francisco.
|    
|    Presentations may be submitted for online viewing at IETF 
|    56 along with
|    any interim sessions since Atlanta (55).
|    
|    These materials may be sent in until Thursday, March 14th  <at>  5:00pm.
|    After this cutoff date materials may be submitted onsite at the
|    Registration Desk, however please allow at least 1 day for 
|    new posts to
|    be listed online.
|    
|    Please see   www.ietf.org/proceedings/03mar/  for 
|    guidelines and the
|    group submission form.
(Continue reading)

Manral, Vishwas | 4 Mar 2003 11:45

RE: draft-ietf-isis-wg-mib-11.txt

Hi Jeff,

Some minor comments. Does the isisLSPTLVIndex mean the offset in bytes from
the header or the TLV number(like the first/second/nth TLV) in the contents
of the LSP?

I think its the latter. It would be nice if this was clarified further in
the "DESCRIPTION".

Besides I am not sure if I have asked you for this, but can we change
isisLSPTLVSeq to isisLSPTLVLSPSeq and isisLSPTLVChecksum to
isisLSPTLVLSPChecksum.

Also in isisLSPID description you can replace the "Fragment Number" as "LSP
Number" in isisLSPSummaryTable.

Thanks,
Vishwas

-----Original Message-----
From: Jeff Parker [mailto:jparker <at> axiowave.com]
Sent: Monday, March 03, 2003 9:15 PM
To: 'Manral, Vishwas'
Cc: ISIS-WG (E-mail)
Subject: RE: draft-ietf-isis-wg-mib-11.txt

 
> Hi Jeff,
> 
> What does a value of "none" mean for the 
(Continue reading)

Noguchi Kay | 12 Mar 2003 13:51
Favicon

draft-noguchi-isis-protocol-topology-01.txt

Hi all,

This is Kay.

I updated our draft, Protocol Topology Support for IS-IS.
You can download it from the ietf site with this URL.

http://ietf.org/internet-drafts/draft-noguchi-isis-protocol-topology-01.txt

The change includes,

 - it makes clear the adjacency section as Jeff suggested.
 - it adds one section which discribes "Migration from Node Oriented
   to Interface Oriented Protocol Support".

I'll make a presentation in the next IETF so hope you guys read the
draft before the meeting.

Thank you,

								kay
Jeff Parker | 14 Mar 2003 16:43

RE: draft-ietf-isis-wg-mib-11.txt

Cleaning up unanswered mail

> Sent 3/4/03
>
> Hi Jeff,
> 
> Some minor comments. Does the isisLSPTLVIndex mean the offset 
> in bytes from
> the header or the TLV number(like the first/second/nth TLV) 
> in the contents
> of the LSP?

Good point.  Is this clearer?

    isisLSPTLVIndex OBJECT-TYPE
        SYNTAX Unsigned32
        MAX-ACCESS read-only
        STATUS current
        DESCRIPTION
            "The index of this TLV in the LSP.  The first TLV has index 1,
		 the Nth TLV has an index on N."
    ::= { isisLSPTLVEntry 1 }

> Besides I am not sure if I have asked you for this, but can we change
> isisLSPTLVSeq to isisLSPTLVLSPSeq and isisLSPTLVChecksum to
> isisLSPTLVLSPChecksum.

Remind me why is this a good idea.  

> Also in isisLSPID description you can replace the 
(Continue reading)

Jeff Parker | 14 Mar 2003 16:54

RE: Description of isisSysLevelOverloadState


> Jeff,
> 
> The description of isisSysLevelOverloadState contains the below.
> 
>  The administrator may set the state to 'waiting' when
>  the router is initializing by setting the object
> 
> [But this is a read-only object.  How can the administrator set it?]
> 
> I think we need to modify the wording here.
> 
> -Nagi.

Nagi -
	Good point.  I have modified the text of the Description clause,
included below.  The isisSysLevelSetOverload object remains read-create.  It
is also included below for reference.
	The LevelState TC includes both overloaded (natural causes) and
waiting (set by administrator) so that a manager can tell why the system's
overload bit is set.  

- jeff

    LevelState ::= TEXTUAL-CONVENTION
        STATUS current
        DESCRIPTION
            "States of the IS-IS protocol."
        SYNTAX INTEGER
            {
(Continue reading)

Tony Li | 20 Mar 2003 00:38

Blue sheets


If anyone picked up the blue sheets after last night's meeting, could
you please get them to me.

Thanks,
Tony
Susan Hares | 20 Mar 2003 02:39

RE: Blue sheets

Tony:

I picked them up and delivered them
to the IETF folks.  You can get a copy (if you
wish from them).

Sue Hares

-----Original Message-----
From: Tony Li [mailto:Tony.Li <at> procket.com]
Sent: Wednesday, March 19, 2003 6:38 PM
To: isis-wg <at> ietf.org
Subject: [Isis-wg] Blue sheets

If anyone picked up the blue sheets after last night's meeting, could
you please get them to me.

Thanks,
Tony
_______________________________________________
Isis-wg mailing list
Isis-wg <at> ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg

Gmane