Subject: [Isis-wg] Minutes

From: "Tony Li" <[email-masked]>
Date: Tue, 22 Apr 2003 00:02:18 -0700

All,

Papadimitriou Dimitri was kind enough to take copious notes
during the last meeting.  Unfortunately, these just popped to the
top of my work stack.  My bad, sorry.

Tony

IS-IS Working Group (isis)

Tuesday, March 18 - 17:00-18:00
===============================

Meeting Minutes:
---------------

1) IS-IS document status:

- MIB for IS-IS:				Updated 6/03
- IS-IS Cryptographic Authentication: 	 	Revisions needed (moving
forward)
- IS-IS extensions for Traffic Engineering: 	Under IESG evaluation
- Routing IPv6 with IS-IS: 		 	Under AD evaluation
- IS-IS Extensions in Support of GMPLS:   	Under AD evaluation
- M-ISIS Multi Topology (MT) Routing in IS-IS:  Revisions needed
- Extended Ethernet Frame Size Support:	 	Push Back from IESG
						WG killed this i-d
- Restart signaling for IS-IS:		 	Updated 6/03
- Point-to-point operation over LAN in
  link-state routing protocols:		 	Under AD evaluation
- Extending the Number of IS-IS LSP 
  Fragments Beyond the 256 Limit:		In RFC editor queue
- IS-IS Automatic Encapsulation:		due 6/03
- Policy Control Mechanism is IS-IS Using
  Administrative Tags: 				Under AD evaluation
- TLV for Proprietary Use: 
- Recommendations for Interoperable IP
  Networks using IS-IS:				Under AD evaluation
- Recommendations for Interoperable
  Networks using IS-IS:				Under AD evaluation
- TLV for Experimental Use: 			Updated 6/03

Discussions:
-----------

Tony Li: Any question ? 

Note: No questions from the group

------------------------------------------------------------------------
--------
2) Multi-Level IS-IS Without Protocol Extensions (Jonathan Sadler)
   draft-sadler-isis-ml-bcp-00.txt

Summary:
-------

o Problem statement:

  - Context of Sonet/SDH networks using ASON and GMPLS routing
  - Not the same use of IS-IS as in DCN networks
  - The scale of Sonet/SDH networks is larger than IP networks with 
    sometimes more than 10.000 switching nodes (OXCs and ADMs) to be 
    managed hierarchically (using more than two levels of hierachy) 
  - Sometimes political/geographical/administrative boundaries defining
    these hierarchical levels

o Picture showing typical transport networks topology (remark from 
  the author: in general no nice construction of the control plane 
  topology)

o Approach:

  This is not a new question, back in '98 concerning multi-level IS-IS
  approaches:
  1) distance vector
  2) stick to isis levels

  Here proposed approach without protocol extensions, nothing to be 
  added concerning the bits on the wire (except concerning the use of 
  the RFC 2966 up/down bit to prevent looping)

  Nodes participating to multi-level at the same time makes use of 
  GRE tunnels to have such kind of aggregations (remark from the 
  author: new item in the charter ?)

o What is needed
  - Rules for info exchange between levels
  - Rules for info exchange within a level
  - Rules for route preference

o Scoped Problem Statement

  - How to deal with prefix propagation between levels ? By extending
the
    RFC 2966 up/down bit semantic (keeping track of the instance
top->down 
    and bottom->up) here this mechanism can used between level n <-> n+1

  - Within a level ? in the present context, level 2 doesn't have
anymore 
    a specific status, the announcement of prefixes should allow ->
usage 
    of RFC 1195 and (transit) areas that can be used as tansit for
higher 
    levels

  Discussion on how a level n can provide transit capabilities -> create

  neighbor adjacencies (GRE tunnels) between devices in order to create 
  this "tunneling". 

  - Also there is the need to define preference rules in RFC 2966. 

o Conclusion:
  - Requires work on multi-level hierarchies to be taken out of 
    hibernation (any specific charter issue ?)
  - Can be done without any extensions to IS-IS

o Questions:
  - Is the IS-IS wg interested ? (remark from the author: i hope yes 
    pointing also to the Q14/SG15 request) 
  - Is this work in the charter ? (remark from the author: quite open 
    question but doesn't seem to be out of charter)
  - Proposals to the group: working group i-d ?
  - Number of items have been identified as places for further work to 
    support multi-level, for instance automation of peer-wise adjacency 
    establishment, also what happens on LAN interfaces... there are
lot's 
    of interesting things to be discussed (that are **NOT** solved by 
    the present document)

Discussions:
-----------

- Tony Li: Questioning the group "Is this useful ?" 

  Note: 2 or 3 people raise their hand

- Tony Li: key question, making appropriate protocol changes to define
packets 
  going at level 3, 4, 5 ? Addressing the group "Has somebody taken a
look at 
  this alternative approach ?"

- Jonathan Sadler: level 2 lsp can be used with some extensions with
specific 
  markup

- Tony Li: recollection from the lsp pdu format, 8 bits are available 
  and it is trivial to take this lsp pdu and define all these other bits

- Jonathan Sadler: carry the level information ? here we need to be
capable 
  to insert level in between levels, thus it seems to be better to keep
the 
  relationship between the levels so that you can (more easily) insert
them

- Tony Li: here limited to level2-level3 ? given there is not a lot of
demand,
  proposes to take this discussion on the mailing list since it doesn't
seem 
  this i-d has an exciting demand

- Jonathan Sadler: understood (and seems to agree)

- Steve Throwbridge: Liaison from Q14/SG15, present the motivation for
such
  i-d, Steve encourages (the group) for reading G.7715 to address the
Q14/SG15 
  requirements and asks for receiving the input from the ietf routing
expets

- Naiming Shen: on the link we are obliged to tell at which level the
neighbors
  are sitting thus we have a need for identifiying the level 

- Jonathan Sadler: agrees this is needed to route protocol traffic but
here the
  approach with the GRE tunnels is proposed 

- Naiming Shen: with tunneling limited to point-to-point interfaces

- Jonathan Sadler: agrees, and underlines that this is a serious
limitation 
  that requires more work from the working group

------------------------------------------------------------------------
--------
2) Protocol Topology Support for IS-IS (Kay Nogushi)
   draft-noguchi-isis-protocol-topology-01.txt

Summary:
-------

o RFC 1195 Restitctions:

   - Every router in a level-1 area must be capable of all network layer

     protocols that are present in that area
   - Protocol support must be identical on all interfaces. Thus the 
     protocol capabilities must be made available on all interfaces 
     (node oriented support capabilities). Thus can't mix IPv4 only and 
     IPv6 only in areas

o Goals: 
 
   - IPv4, IPv6 and IPv4/v6 dual routers can coexist with different 
     protocol support on each interface

o New TLV and new sub-TLV (Changes to RFC 1195):
   
   - New TLV: Interface Protocols Supported TLV in IS-IS Hellos, 
   - New sub-TLV: Protocols Supported sub-TLV (in Extended IS
     Reachability TLV)

o Adjacency formation:
   
   Modified rules of when to establish an adjacency: each router must 
   drop IS-IS hello which doesn't carry interface protocols supported 
   TLV on point-to-point interfaces (must not form an adjacency if at 
   least one of the protocol capabilities is not met by the neighboring 
   router)

o LSP encoding:

   The rules for encoding the Protocols Supported sub-TLV depend on the 
   type of interface:
   - for point-to-point interface: ANDing the local side of interface 
     oriented protocol support capability with the remote side of 
     interface oriented protocol support capability
   - broadcast interfaces using two Protocols Supported sub-TLV: one
     in regular lsp and one in pseudo-node lsp

o SPF Calculation:

   - Changes must be calculated separately for each layer network 
     supported
   - New Protocol Supported sub-TLV must be used instead of old (ie
     previously defined) Protocol Supported sub-TLV

o Migration mechanism:

   - Start advertising new TLV and sub-TLV in addition to the old tlv
   - Change the adjacency formation and spf calculation based on this 
     draft
   - Stop advertising the old Protocols Supported TLV in IS-IS Hello's
   - Reconfigure the interface protocol capabilities when applicable

Discussions:
-----------

- Acee Lindem: there is an existing igp capability draft that you can  
  use since there is a limited number of AF that you can support (on a 
  node basis) as opposed to an a per interface support

- Rahul Aggarwal: this has been worked out at the ospf working group;

- Albert Tian: What enables this new approach compared to the existing
  M-ISIS ?

- Kay Noguchi: showing an additional slide
  
   o non M-ISIS IPv4 router and M-ISIS IPv6 router
     -> how to make the adjacency ?

   o non M-ISIS IPv4/IPv6 dual router and M-ISIS IPv4/IPv6
     -> possible routing loop

   o IPv6 reachability TLV and MT Reachable IPv6 Prefixes (M-ISIS) 
     -> Do we need both ?

Discussion on the first point:
-----------------------------

- Naiming Shen: intent is to describe the mechanismn, here we need to 
  have an interoperability document explaining interoperability issues
  between non M-ISIS and with M-ISIS with lot of details. Currently, 
  how they do this ? the check is performed on the subnet using the 
  hello packet for this particular interface that then can setup the
  adjacencies

  But this possible when configured with IPv4, they are supposed to 
  build these adjacencies, otherwise they will refuse to build up 
  these adjacencies (here only IPv4 used as workaround)

- Kay Noguchi: do we have some draft that describes this ?

- Naiming Shen: no we don't; this a workaround, there is a way to get 
  outside of it and this is obvious (pointing to the first bullet), how 
  to make them work is by putting or configuring IPv4 within the packet 
  ... but if you reboot you need to setup the adjacency again

- Kay Noguchi: do you mean reboot the IPv4 router ?

- Naiming Shen: yes, or "no IPv4 checking" is to be configured

- Kay Noguchi: so we need to change the code 

- Naiming Shen: you have delivered one

- Kai Noguchi: do we need a document for that purpose ?

- Naiming Shen: yes we probably need an M-ISIS interop draft to explain 
  the interoperability between non-M-ISIS and M-ISIS nodes

Discussion of the second point (on routing loop)
------------------------------

- Naiming Shen: in the latest revision of the M-ISIS draft, two types...

- Kay Noguchi: two types meaning here ?

- Naiming Shen: the M-ISIS draft defines different types of reachable 
  prefixes in specific TLVs and these two types shouldn't be mixed up; 
  
- Kay Noguchi: this one is not for reachability but for IS Reachability
TLV

- Alex Zinin: they just can't mix

- Naiming Shen: concerning the prefixes they shouldn't mix since we have

  two types of prefixes (thus on different spf trees)

- Kay Noguchi: here we speak about IS reachability TLV's

- Naiming Shen: no mix between M-ISIS and no M-ISIS 

- Kay Noguchi: is there a standard policy for M-ISIS ?

- Naiming Shen: it can't be the same address corresponding to the same 
  topology, this problem is already in IPv4/v6, but here we have two 
  different topologies within M-ISIS

- Kay Noguchi: my draft solves only the IPv4 issue

- Naiming Shen: no, the core router won't understand the IPv6 adjacency,
  and it will not understand the adjacency since we speak about
different 
  TLV's (not on the spf tree)

- Kay Noguchi: here we speak about Extended IS Reachability

- Naiming Shen: here we should support both IPv4/IPv6, thus there is no
  difference

- Kay Noguchi: this is exactly the problem

- Naiming Shen: correct, here we speak about a specific IPv6 adjacency
or 
  a specific IPv4 adjacency, thus i don't understand where the problem
is

- Kay Noguchi: my argumentation is in terms of dual routers 

- Tony Li: we need only one solution thus please find a compromise

- Kay Noguchi: today ?

- Tony Li: through the mailing list

- (?): you should give the proper credit from people having done this 
  before - please reference where this draft is positioned with respect 
  to prior work

- Kay Noguchi: agrees

------------------------------------------------------------------------
--------
3) JTC1 Liaison (Alex Zinin)

Announcement: agreement with the JTC1 has been signed and IETF will sign

from its side during this week

Meeting is adjourned.

========================================================================
========
_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg