Subject: [Isis-wg] Meeting Minutes

From: Tony Przygienda <[email-masked]>
Date: Wed, 24 Sep 2003 21:01:21 +0200

Thanks to Cengiz

    -- tony

ISIS WG Minutes

- Agenda
 Draft Status
 Capabilities

- Draft Status:  Tony P. gave the draft status and summarized the 
discussion from the
 mailing list.
MIB                            (12)            Ready for Last Call ?
Cryptographic Authentication   (05)            Editors Queue
GMPLS Extensions               (16)            Waiting for AD Comments
TE Extensions                  (04)            AD Comments
IPv6                           (05)            Waiting for AD Comments
M-ISIS                         (06)            Was discussed again, AD
Extended Ether Frame           (01)            Abandoned
Restart                        (03)            LC Passed, Mailing List
P2P over LAN                   (01)            External Party
256+ Fragments                 (02)            Editors Queue
Automatic Encapsulation        (02)            Under Discussion
Administrative Tags            (01)            Mailing List, Expired
Experimental TLVs              (00)            Ready for LC now ?
Interoperable IP Networks      (00)            AD Comments
Interoperable Networks         (00)            AD Comments

Three-Way Handshake            RFC 3373        Published

No comments from the audience.

- Optional Router Capabilities (Naiming Shen)

Follow up to Yokohoma discussion. That document has been split into an
OSPF and ISIS only documents.

Draft proposes a new TLV to encode a router's capabilities. It is useful
to encode this information for troubleshooting, figure out misconfigs
and
also to signal certain services, path computation server, location, etc.

The TLV has its own encoding of the router id. An L1/L2 router verbatim
copies these TLV's in its L1 area into its own L2 LSP. The flooding of
these TLVs are controlled by using the following bits:
     F bit: flood to the whole domain
     T bit: to signal an external application
     Up/Down bit: to stop looping (see route leaking).

The capabilities themselves are encoded as sub-tlv's.

Paranta(sp?) from MCI: He is worried that the verbatim copying of these
tlv's
can spread effect of buggy routers in one L1 area into the whole
domain. He would prefer if the L1/L2 router would first interpret these
TLV's and later rewrote them, similar to route leaking.

Kireetee: He wanted to know how the ambiguity is resolved if two L1/L2
routers were to summarize these TLVs differently. Or if the origin
router
was to incosistently send multiple of these tlvs. Naiming said you
should
pick the one you heard last, or you can adopt another scheme which is
deterministic (e.g. of closest/farthest router to you based on
metric). You can check for errors, length, etc, before making it your
own
lsp.

Kireeti requested to make the length in bytes.

Tony P. said 1. we cant do anything about faulty implementations. Tony
favors copying verbatim, and thinks it might be buggier if the router
regenerated it from what it interpreted. 2. providers have to determine
for themselves what to leak and supress. 3. he said the scheme
introduces
redundancy in a nasty way, if a bit is set, the router has the
capability
and it is enabled, but there is no gurantee this tlv is heard before
another LSP using the capabiltiy. Hence, he is not sure if the
capability
feature is really useful. As an example he gave: What happens when a
router sends you wide metric and not set the corresponding capability
bit.

An IETFer from Juniper suggested router id to be made in a subtlv so
that
that subtlv can be used conveniently inside other tlvs in order to
reduce
number of encoding of the router id. He also said inside the same area
this subtlv can be skippped.

Stephan: Makes l1/l2 router's lsps big...

Dave Ward: no requirement to set bits for your capabilities. the tlv is
only
adivisory. does the bit show how they are configured or does it actually
imply the router is using the capability? (i.e. what is configured and
what is actually being done can be different).

Tony P: the bit has to be trusted, so it is not truely informational.
There was a question of which LSP fragment this tlv should be inside.
Naiming, any lsp number. When there is a change, and the tlv can come
inside any lsp and the latest lsp always overrides the earlier one.

Someone pointed out the tlv is limited to v4 router ids only.

Tony gave the group 2 options and asked for show of hands:
Options: 1. A per capabiltiy section has to be written, and one other
iteration has to be done before becoming a WG document. 2. Make it a WG 
document now.
6 hands for option 1, 5 hands for option 2. Tony said too close to call
and asked to take it to the WG mailing list.

Dave Ward suggested an alternative: Lets split the document (and
encoding)
into two pieces, one for informational pieces and one for hard coded
pieces. There was a clear concensus on this split.

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