Subject: [Isis-wg] Meeting minutes ...

From: Tony Przygienda <[email-masked]>
Date: Thu, 25 Jul 2002 23:14:23 -0700

Thanks again to Tony Ward for wearing the acting chair hat this time.
Thanks to Sue Hares for taking notes during the meeting.

My comments inlined

> 1) Agenda
>
>     Accepted as indicated in the notes
>
>     1. agenda bashing
>     2. Document status - Dave Ward
>     3. Draft Lsp fragements - Amir hermelin ([email-masked] )
>     4. isis route tags - Stefano Previdi
>     5. Multi-topology - Naiming Sheng
>     6. restart - Stefano for Mike Shand
>                 7. MIB - DWard for Jeff Parker
>                 8. ITU-T Study Group 15 Stephen Trowbridge
>     9. draft iih sequence - Naiming
>     10. Draft interoperable - DWard for Jeff Parker
>     11. Draft pcsd - JP Vasseur
>     12. WG future
>
>
>
> 2) Document status
>
>     1) jumbo Frames
>         status: going informational; 1 implementation exist
>
>     2) ISIS over IP
>         status:appears to be dead; no interest from service providers
>
>     3) lsp frags
>         status: LC closed, new version; add comments back, to         
> publication
>         next action: publish revision and forward to IESG
>
>     4) 3 way -
>         status:in IESG queue
>
>     5) MT -
>         status: 2nd LC closing, AD comments back
>         next action: publish revision and send to IESG

Looks at this point in time (albeit the last call seems to have passed) 
as we need to decide
whether the description how the management forwarding 
(all-spf-computation) is working is clear enough? If not, it needs to be 
described better or scrapped. As well, we have now the comment 
outstanding about the description
how the decision is taken which RIB to look up in.

>
>
>     6) TE -
>         status: Closed, new version expected, AD comments back
>
>     7) V6
>         status: new version excepted, AD comments back
>         next action: new version of draft released by author
>
>     8) TLV code points
>         status: awaiting publication
>
>     9) hhmac
>         status: new version expected; AD comments; to publication
>
>     8) optional checksum
>         status: to publication at IESG
>
>     9) restart
>         status: two week discussion, informational, go to last call
>         action: additional discussion needs to go on the list
>
>     10) interoperaability
>         status: two weeks, go to last call

We will be starting last call soon.

>
>
>     11) Admin Tags
>         status: two weeks discussion, go to last call

same here.

>
>
>     12) GMPLS
>         status: any final comments on TLV/sub-TLV structure
>                 working group last call (Dave - please confirm)

the decision has been taken to keep the draft in the isis wg and last call
will be initiated.

>
>
>     13) MIB - 3 months of discussion on list, last call
>         draft: <draft-ietf-isis-wg-mib-08.txt>
>         status:     proposal: 1) new version of the MIB
>           2) 3 month last call requested: If implemented MIB,
>           send note to the working group chair
>
>
>     14) PCSD -
>         next action: More discussion on list;  Need to determine the
>                   interaction with CCAMP.
>
>
>     All drafts from the ISIS working group are published as 
> information RFC.
>     These are inputs to the process for the ISO subcomittee.
>
> 3)  Draft LSP fragements (lsp-01.txt)
>
>       History:
>
>     Hermelin - 02 - added ablity for mode 2
>     Hermelin 03 - merged ode 2 with other authors, changed TLV format
>     wg -00 - document change
>     wg -01     - final editor
>
>       Discussion:
>      a) zero value is not allowed
>      b) Ad indicate this draft is at  due to call on
>      c) many system-ids are now associated with the router instead of 1
>         - comments that it is an implementation detail that decribes
>           how multiple
>
>     If anyone has implemented this draft, please send a note to the ADs
>     and the authors.  It is important to know what modes were 
> implemented.
>
>     In Mode 1, the virtual nodes are not reachable except through the 
> main node.
>         - mode set to overload; can't calculate routes to the router;
>           can calculate routes on the router;
>     In Mode 2, there is not a problem.
>
>     action: 2 modes discussion of calculation needs to be discussed on 
> the mail list.
>         These comments should be combined with the changes for the AD 
> comments.

>
>
> 4)  isis admin tags
>
>     draft-martin-neal-policy-isis-admin-tags-04.txt
>     [working group document added]
>
>     Summary of Draft issues:
>
>     - route coloring
>         requirement: propagion of host routes (router's loopback 
> addresses)
>                     across levels.
>                 route tags give better control
>
>     - new sub TLV - extended Ip reachability TLV 135
>         - sub tlv 2 -
>             type - 1 octet (2)
>             length - multiple of 8
>             1 or more instance of 8 octets
>             [same syntax of Extended communities]
>
>     action: two week discussion, last call.
>
> 5) MT-ISIS
>
>     draft: Naiming Shen
>            draft-ietf-isis-wg-multi-topology-04.txt
>
>
>     MT-ISIS issues:
>     ---------------
>     draft changes:
>         a) announce MT capabilities in LSP and IIH
>         b) form MT ajacencies in p2p and LAN
>         c) announce MT IS neighbors in LSP
>           - MT based SPF calculation and RIB
>           - flooding and optimization
>           - encoding: TLV 229, 222, 235, 237
>
>         d) MT reachable
>
>         - 237, 2 byte MT membership plus the format of tLV type 236
>
>     Generic MT SPF (change)
>         - for NM purpose, need to access routers in different topologies
>         - MT capability TLV in LSP, G bit represents the router GSPF
>         - GSPF algorithm processes all the nodes with the G bit set,
>           loop at links (IS TLV) regardless of MT (back-link check still
>           coform to the MT type).
>
>           Process all MT reachable IP v4 prefies TLV with the sub TLV of
>           MT Management color; then install it into the "management" RIB.
>
>
>     Flooding -no change; optmization on p2p links.  If link adjacency has
>           MT set changes; needs to force an exchange of CSNPs.
>
>           [if don't flood like normal flooding, LSP may get lost.
>            If the MT set changes, need to flood
>
>
>     Discussion: Why is there a separate Management MIB?
>              If you have two separate RIBs, you need to choose state.
>
>             [no answer on this from naiming.

This discussion is right now on the list to be resolved as I said above

>
> 6) ISIS restart draft
>
>     Last changes:
>             - Specified TLV number as 211
>              - ONly UP adjacencies do graceful restart
>                 a) clarify that no adjacency
>             - rest of the ajacencies
>                 a) replace adj from down to "-"
>
>             - Require CSNPs for both levels
>                 a) clarify that on pt-pt circuits cancelling of T1 
> does not
>             - permit t1 to be canclled after 1st retry
>             - allow explicit resetting of holding time
>             - clarify multi-level operation
>             - clearing the olverload bit
>                 [all t2 timers cancelled out and outside [BGP or other]]
>
>     Discussion: Naiming Shen
>
>              When you receive the RR bits, the document says do not 
> refresh
>              the hold down timer.  The document should not say this 
> since it
>              is an implementation timer
>
>              Overload bit is set on the main overload bit on the node.
>
>     action:  Discussion needs to continue on the mail list.

Discussion is right now on the list

>
>
> 7) ISIS MIB
>
>     history: 5 revisions since last approaches
>     changes:
>         - clean compiles - SMiCng; add conformances
>         - "MIB"-ize
>         - MIB features needed
>             3 way handshake,
>             TE info
>             Wide Metrics
>             l2 to L1 leaking
>
>         - Work in Progress:
>             Split counters out of general system and circuit tables
>             LSP header and LSP content tables
>             wide metrics
>             textual reformating
>
>     requested: If implemented MIB, send note to the working group chair
>
>     proposal: 1) new version of the MIB
>           2) 3 month last call
>
>
> 8) ITU Study Group 15 communication to IETF ISIS working group
>
>     see presentation

could the author pls forward the presentation to the list for archiving
in some format, preferrably ASCII.

>
>
> 9) adding Sequence Ids to Hello packets
>
>    Discussion prior to presentation:
>     Chair requested the number of people who read draft: 10 (estimate)
>     Chair determined we should go on to discuss the draft.
>
>    IIH sequence number
>
>    motivation: 1) large of adjacencies
>                2) hold-down timer is low for fast convergence
>            3) congestion over the link
>            4) router process scheduling slips
>            5) massive LSP flooding
>
>     Who's fault is the fluctuation of the links.
>
>   Addition:  new TLV in Hello packet that has sequence number
>
>   Benefit:
>       1) p2mp - if only one receiving router has seq# skips,
>         probably an inbound congestion issues;
>
>         if all the receiving routes for the same router have
>          seq # skips, probably the sender is not sending out
>         the hello packet at the same time
>
>       2) [need the rest of the information here]
>
>
>    purpose:
>      1) mostly NM usage
>      2) adjust the hold time timer to prevent premature adjacency flap
>
>
>     format of the TLV:  Code: 241
>             length: 4 octets
>             value: a 32 bit unsigned number, 0xfffffff[all ones] reserved
>
>       Each level needs to keep sequence number space.
>
>     discussion from list: sub-TLV - for this sequence number is 
> expendable
>               sub-tlv - to indicate time lasp since last IIH or % of 
> interval
>                     this is symmetrical to the sequence # skip for auto
>                     hold-down time adjust.  If one knows the neighbor has
>                     repeated scheduling slips, it an optionally do 
> something
>                     to prevent an adjacency flap
>
>    request: to be a working group
>    Decision:  this draft is not ready to be working group draft
>
>    Discussion:  We do not need sequence IDs to add to hello packets.
>
>         If you receive packets and not other, it may be important to 
> drop the packets.
>
>         [Naiming shen]  It is not a protocol, but an implementation 
> issue on how
>                 to determine the link is down.
>
>         If you have lots of interfaces on the box, you minimize the 
> hello packet
>         processing.
>
>         [Naiming shen]  That's one opinion. Another is send as fast as 
> possible.
>                 This proposal is very simple and does not take much time.
>
>         [Stephen] This is trouble shooting the link and the box.
>
>         [namining shen] We do not have the tools today, and this gives 
> some additional
>                     tools.  It is not a high price.  authentiation
>
>         [Stephen] This is a high price for the additional tool.
>
>         [Ed Kern] this is cranking the complexity knob to solve an 
> edge problem.
>
>         [Naiming Shen] - This is a configuration problem. This is very 
> cheap tradeoff
>                  for trouble-shooting.
>
>         [Ed kern] authentication is required.  This doesn't tell you 
> what the problem
>               is exactly it.  I feel the complexity is increased?
>
>         [Amir] As a sequence number, it is cheap.  However, this is 
> may not be
>             the right direction.  This focus on the link protocols 
> should not
>             come from the is-is working group.  This focus should come 
> from
>             another working group.
>
>         [naiming] A problem on the adjacency is urgent due to fast 
> convergence issues.
>
>         [dave] - You are assuming a trust model with the adjacencies; you
>              have
>
>         [kareeti/dave] It is less expensive to use telnet to debug.
>
>         [xxx] replay attack is a concern. [dave ward] IP sec protects 
> against
>             this feature.  Any additions should await the RP-Sec 
> information.
>
>         [Dorian Kim] This has a good feature, but there are other 
> existing tool that can solve this problem in a network.  As operators 
> we have enough  crud in the routing code.  This feature does not 
> really buy you enoug to add more complexity to the routing system.

Dave indicated that he felt the rough consensus was to not take it on as 
workgroup item. Any contradicting opinions please to the mailing list.

>
>
>
>
> 12) Recommendation for Interopability
>
>     10 people read the draft, so the presentation will contineu
>     draft-ietf-isis-interoperable-01.txt
>
>     Summary for draft:
>     ===================
>     a) What is covered:
>         1) Variables that are constant;
>         2) Constants that are variables
>         3) What's not used
>
>     b) Chagnes for IP Networks
>         1) A number of tings that IP routers do that are not covered in
>
>     c) Tweaks to 10589
>
>     d) Description on problems with non-homogenous networks
>     e) description on how to increase the MTU size
>     f) Future work
>         1) dealing with non-homongenous networks
>         2) doppelganger LSPs
>
>     status of the document: Should it be normative or not normative
>
>     list to discuss this:  [email-masked]
>
>     Request: Comments on this draft have been quiet for the last 6 
> months.
>         Discuss two weeks on list; and then go to last call
>
> 13) JP Path commutation
>
>     If anyone has read the draft, - 5 have we will continue with 
> presentation.
>
>     motivation:
>         1) TE LSP path computation is CPU intensive
>           - optimal TE LSP placment
>           - GMPLS
>
>         2) Incomplete TE LSDB (inter-area TE, Inter-AS TE)
>             - Compare with scenarios 2,4, and 5 of the 
> draft-kompella-mpls-multiarea-03.txt
>
>         3) Uni like protocol - CE is not in the MPLS routing domain
>
>         4) backup tunnel path computation
>         [Centralized or distribute for bandwidth protection while 
> allowing   bandwidht sharing in the context of FRR draft]
>
>     draft:  automatic discovery of PCS - Packet Computation server
>
>         TLV -
>             sub-tlv - Server scope
>                   Server addresses
>                   server capability
>                   AS Domain TLV
>
>         mechanisms:  new LSP on PCSD TLV content change, rules for 
> sub-TLV  settings, PCSD TLV leaking rules on L1-L2 routers, 
> non-supporting capability, issues: no scalability
>
>     proposal:  Request for ISIS working group document
>
>     Discussion:  1) Cannot proceed in CCAMP working group
>              2) Passing along routing capabilities

Dave's take is that the consensus of the working group was to not take 
it on as workgroup item. Any dissenting opinions please on the mailing 
list. I would expect the issue to come up in the context of a 
'capability indication' draft.

>
>
>
>
> 14) future topics of the is-is working
>
>    a) continue to meet irregularly
>
>     - continue to work on email list
>
>    b) attempt to wrap up Charter work by IETF 56
>     - many drafts in last call awating final editorial chagnes
>     - several drafts going out for Last call for IETF 54
>
>    c) Most drafts becoming Informational RFCs
>
>    d) Finishing any bits V6
>
>    e) focus on finishing bits and pieces of internetworks
>     - exiting implementation considerations
>     - removing working items that are not relevant
>
>    f) wrapping-up work on extensions with existing protocols 
> architectures
>     - charter revisit at IETF 56
>     - ISIS v2 did not intend to convey to indicate a new work item 
> but, 2nd ed.
>      interaction with ISO
>
We are in the process of updating the charter to reflect realities a tad 
better
Finally, where did the draft on the p2p over ether end up ?  I thought 
that it was intended as a workgroup item and I see a requirements 
comming in from certain
class of customers for such a thing.

    thanks

    -- tony

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