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

From: Tony Przygienda <[email-masked]>
Date: Sat, 13 Jan 2001 01:24:09 +0100 (MET)

Many kudos to Alex for a great job scribbling them
down in the heat of the moment.

	-- tony

TP informed the WG about upcoming last calls and gave
short overview of ongoing works:

 o IPv6 extensions: there were no objections, last
   call to follow

 o 3-Way and more drafts that have implementation 
   experience and have been deployed will go last call

ISO Ballot:

 o Ballot authors were "no show".

 o requirements are expected from IETF

 o the ISO document should be published as an RFC,
   volunteers are sought. None materialized. 

Senthil presented his slides on ISIS extensions for
inter-area TE LSP setup. The idea is to summarize TE information
(as a min/max couple) and flood it to L1 areas in order to
give head-end LSRs more info on available resources and
decrease the number of signaling cranck-backs.

Jim: How does min/max announcement address colors?

  S: For each network, there're multiple TE attributes,
     including colors and BW. The results depend on how
     much summarization is done. It is configurable on
     per-color/per-BW basis.

  Q: What about BW encoding? Bytes per sec does not scale
     up to OC-48
  S: Agree
 TP: Need to agree on a format, point taken
  S: Good point
Radia: Fixing this is one thing. Metrics do not help all the time,
     dynamism in BW advertisement...

Sadheer: Depends on the service in the network,
     Granularity will vary per configuration.

Curtis: I though the format was floating point.

Some discussion about the floating point format occurred.
Rough consensus was that floating point will allow to represent
up to 10^128, which is more than enough.

Curtis: there may be a way to deal with colors
TP: Kireeti's draft should help
C : Combinatorial explosion of color advertisements is a bit scary.
    Color-based summarization should have limited support

George: Colors can be used as binary "AND" or "OR". Considering
    all possible combinations, it would be too much to announce.
    No use to summarize the colors.                                    

 ?: Do you have any estimation on the number of TLVs announced
    as a result of TE summarization?

 S: Depends on how many networks are in the domain and how
    you summarize.

 ?: Dijkstra is the one to be simplified, so the number of links
    should be decreased.

Alex: As mentioned at the TE WG meeting, it would be really nice
    to have some simulation results. Summarization may do harm
    to signaling---increase the number of cranckbacks or just
    be as good as randomly selecting the first ABR.

Motion was made to make the draft a workgroup item and after short
discussion in which multiple people including George Swallow 
observed that there was NO decision from MPLS to work on that 
issue, even less an agreement on what kind of approach should 
be taken, dismissed. 

Alex presented draft-ietf-ospf-isis-flood-opt-00.txt proposing
some flooding optimizations for the case where neighboring nodes
are connected with multiple parallel links.

 TP: The draft covers both ISIS & OSPF. John is going to present
     a counter-proposal for OSPF at the OSPF WG meeting. As for
     the ISIS part, we need implementation experience first.

 AZ: Agreed.

Alex has asked a while ago to make flooding optimizations 
workgroup draft and it was agreed to given implementation 
experience. Depending how the 
work develops, especially in the light of similar effort
going on in OSPF group, we may see or not see a submission. 

Don presented draft-fedyk-isis-ospf-te-metrics-01.txt effectively
describing different metric types and proposing container TLVs
for additional TE metrics. Don presented this draft in Washington,
DC and was asked to demonstrate customer support.

 Enke: Is this a real problem or theoretical?
       ISIS has multiple metrics already

  Don: Metrics we propose are used for MPLS TE extensions.
       Different purpose.

 Multiple speakers indicated it would be a good idea to
 assign semantics to the metrics. Don suggested firming
 the definition of metrics, TP indicated units would be
 necessary. Metric started to mutate in its meaning 
 on the fly during the discussion.

 Dave Oran: routers need to agree on the semantics

 Curtis: They do in hop-by-hop routing, but not in TE.

 Dave: Need to know what to do if these metrics are not
       understood.

 Curtis to Don: We already have SPs using metric as the link
       delay, why do we need another one?

 Don: It is another option. We do not specify what exactly
      these metrics are.

Motion was made again to make it workgroup item and 
there was some argument back and forth about usability and 
necessity of these metrics and no decision has been made. 
Punted to ADs to look at the topic and come up with a decision. 
Footnote: OSPF workgroup ended up with pretty much the same 
result. 

Francois presented draft-lefaucheur-diff-te-isis-00.txt, proposing
additions to ISIS TE extensions to help DiffServ-aware MPLS TE.
Francois requested the draft is accepted as a WG item.

 Jim: Why use such encoding scheme

 F: to minimize impact on IGP, amount of flooding, BW overhead,
    may help in processing as well

 Kireeti to Jim: these are sub-TLVs of the Ext. Reachability TLV,
    it is useful to compress.

 K: Scope of priority per class-type?  Answer unclear.

 F: Proposal to accept as a WG item

 Alex Mondrus: Should we wait for the TE WG to comment on the
    requirement document

 George: We should move further.

 Rough consensus was to accept the draft.

 TP: Will check with the other Tony but accepted until 
        stated otherwise. 

Cengiz presented draft-alaettinoglu-ISIS-convergence-00.txt
discussing the possibility for ISIS to improve convergence time
to a subsecond level. Proposed techniques included subsecond
Hello timers, incremental SPF, as well as fixing bugs affecting
the flood behavior. The presentation initiated an active
discussion.

 Alex: Not comfortable with too frequent Hellos. P2p links usually
       do not need this. In case of multi-access segments convergence
       is fast if there's a backdoor flooding path, otherwise, some
       smarter mechanisms could be used. IGP mechanisms should not
       substitute L2 ones.

       SPF: even without incremental SPF per se, some smarter SPF
       scheduling can be used.

 Cengiz: The point is to remove the Hello interval limitation from
       the IGPs, if some other mechanisms would help, then fine.

 VJ:   Current definition of Hello intervals in IGPs is an unnecessary
       limitation.

    ? : In case of an FR cloud, SPs do not always support correct VC
        status announcement, so we need subsecond hellos here.

  Alex: Once implemented, we can't control where these hello are
        configured.

        As far as the FR example is concerned, ask the SP to fix
        the network, not router vendors to accept the problem.
        IGP should not perform L2 functions.

 Kireeti? : Regarding you incremental SPF modeling, did you use
        a single topo change or multiple. Multiple changes is
        where the complexity starts.

     C: We used a single change, but multiple is possible.

     K: Multiple changes is more realistic in a big network and
        this is a big network where we need incremental SPF.

    VJ: Incremental is at least as good as normal Dijkstra

  Alex: Was a real LSDB used in simulation of incremental SPF?
        Detecting which link has gone up or down is where incremental
        has more overhead than standard Dijkstra and may be more
        expensive when multiple topo changes are processed.

 Padma: Exponential delays for topology change announcement
        would be a good idea to decrease the impact of flapping
        interfaces.

     C: Up and Down interface transitions should be processed
        differently

     ?: Exponential for up, but not for the down even seems
        a good idea.

     ?: Was any traffic injected in the network while tests were done?

     C: No

     ?: In the real world, this would cause resource contention
        and would affect the results

     ?: Subsecond Hellos are dangerous, and may affect flooding, etc.

     TP: flooding complexity should be addressed via network partitioning
         (areas)

   Enke: It is trade-off btw stability and fast convergence.
         SPs care more about stability and even increase Hello interval
         for the sakes of it.

      C: The question is why there's instability. Different processing
         of Up and Down events should help.

   Enke: Also, SPF is not a concern.

    Jim: Full mesh topologies have different properties and may need to
         be addressed separately???                            

     VJ: Some ISPs are using long timers for stability reasons. The theory
         says it is not necessary. We found that SPF complexity affects
         flooding behavior and fwd'ing functionality

   Alex: Regardless of how much time SPF takes, it does not affect fwd'ing
         and should not affect flooding.

      ?: One of the carriers built a huge flat fully-meshed wireless 
         network and OSPF melted, even with normal intervals.

     TP: That's rather a deployment problem, pls read applicability 
         statement of the protocol.  

The discussion was taken off-line.

_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg