Subject: [Isis-wg] IETF 48 meeting minutes

From: Tony Przygienda <[email-masked]>
Date: Mon, 21 Aug 2000 20:43:59 +0200 (MEST)

Thanks to Alex for initial version:

* Agenda bashing & Administrativa

    1. domain-wide passed last call, unfortunately credits have not been given to
        Quaizar who contributed some key ideas
    2. mesh-groups passed last call
    3. isis-ext-eth passed last call
    4. expired te draft will be re-submitted latest 2 weeks after IETF or another 
        party will take control of the draft

* Draft on flooding optimization has not been presented. Couple of comments were 
    made and will be sent to authors. 

* Kireeti presented draft-kompella-isis-ompls-extensions-00 summarizing
   extensions to ISIS to support MPL()S.

   Q: How is this work relative to transport rings?
   Kireeti: Not quite sure. We can introduce transport ring support if necessary

   Q: Wrt link protection, not all protection schemes are covered (N:N,
      and N:1 are not included), why?
   K: We tried to keep it simple.

   K: The way to proceed with the draft seems to be to go to the new
      WG and reach the consensus there and then come back to ISIS WG.

   TonyP: Agree, let's give it a chance to be discussed in the new WG to fit
            into any "bigger" scheme of things. If that doesn't happen, we'll
            take on to work on the issue.

* Francois presented draft-lefaucheur-diff-te-ext-00 describing the extensions
   that need to be made to ISIS TE TLVs to support DiffServ-aware MPLS TE.
   The main idea is to provide BW info for each class using new sub-TLVs
   in existing TE TLVs. Francois requested the feedback from the ISIS WG.

   K: Not sure this is the right forum, but this can be coded more
      optimal if (announce overall unreserved BW and reserved BW per
      class ???)
   F: We couldn't make it work, would be happy to discuss this. (Discussion
      to go off-line)

   Curtis: 4 class types is very restrictive and 8 preemption levels may be
           too much
   F: Those are sort of things which relate to the definition of requirements
      and should be discussed in MPLS/TE WGs.

   TP: You do not address the situation where routers do not udnerstand the new
       TLVs. This could lead to loops in loose source routes scenarios. 
   F : It is addressed in the signaling component, which is not in the draft

   TP: it is still a good idea to specify what to do with TLVs if they are
       not understood. Draft may end up in the new routing area working group or
       MPLS and architectural/requirement issues will be worked out there first.
       Output of that work may find its way back into ISIS working group.

* Ran Atkinson (engineer at large :) spoke up about draft-ietf-isis-hmac-01.txt.
   The document was described as stable and clear for implementation. Ran encouraged
   WG members to read it and post the issues (if any) to the list.

   TP: There's some confusion about support of 2 keys, people wonder if it's necessary.
   R : Yes it is, in particular to support smooth key roll-over.

   TP: Paragraph on the IIH protection is still missing. Contact info needs update. 

* Chris presented draft-ietf-isis-ipv6-01.txt. The draft describes extensions to ISIS
   to propagate IPv6 routing information using TLVs similar to wide-metric TLVs for
   IPv4. One known implementation is gated, other vendors claim to be looking into this.

    K: Shouldn't the cost be 24 bits as in TE extensions, not 32 bits as in the draft?
    C: TE has different metrics

    K: There should be some allignment with TE metrics (24 bits)
    TP: Double check this, pls.
    C: I will

    Mike Shand: What about IPv6-incapable routers?
    C: Implementations may calculate 2 SPFs---one for IPv4, and another one for IPv6
       excluding IPv6-incapable routers. Seems to be more administrative issue.

    Q: The draft differentiates btw internal and external routes, while TE doesn't, why?
    A: The draft sticks with original 1195 semantics that was dropped by TE extensions,
       so the question is to TE authors.

    T: TE simplified the semantics because nobody was actually using it.
       It makes sense to stick with 1195 to avoid redistribution loops. 
       IPv6 draft is
       not implementing the I/E bit (which was not necessary) but only 
       differentiates
       between external and internal routes which is necessary to prevent 
       those loops.

* TP: draft-ietf-isis-hmac-01.txt is to go through the last call after 
	the comments
    are being incorporated and new version submitted.

        === tony

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