Subject: [Isis-wg] Notes from IETF 63 ISIS WG meeting

From: David Ward <[email-masked]>
Date: Fri, 12 Aug 2005 09:59:55 -0500

ISIS WG meeting minutes from IETF 63

Thanks to Alia Atlas for taking the minutes.

0) Status & Admin:
     Admin-tags
	moving forward in process - cleared AD Last Call
	Please send in implementation info.  I'll send out a last 
call for these.
     M-ISIS:  cleared ADLC & LC for implementation reports
     MIB:
                Going to LC any day now
     Capability Advert:  dependent on ISIS-TE
        one last revision needed
     BFD Bit:  very little discussion on list... requested to be a WG
        item.  If any comments, interesting to hear those.  (No comments).
        Multi-instance ISIS:  after presenation, see about WG item
     Traffic Engineering: Finally an informational RFC.  Want to now
        submit it for standardization.  Will allow others to become
        standard.  Are going to take another run around this.  I'd
        expect to see it for the first rev to be exactly the same as the
        Informational RFC.  Reason it went informational, hadn't cleared up
        responsibility between ITU and IETF, but now is clear.
     V6:  protocol analysis
     Experimental TLV:  Need implementation report - know of none & can't
       move forward.  Without any implementation, very hard to have become a
       standard.
     V6TE:  dying & expired.  Will contact the authors directly.   When
       take the TE draft, may take the V6 in.  (ADs indicate lack of caring
       about whether this is in separate draft or same.)
     In Editor queue:
       Alex:  checking what the P2P over LAN is stuck on.  It is in
              edit state, which means they are working on text.
       Dave:  GMPLS is stuck on the TE drafts.
       Bill:  (shows scary graph of dependencies for the GMPLS
         extensions.  mpls-bundle was blocking everything.  They're all clear
         now.   MPLS-bundle was pulled from queue shortly after it was
         approved, b/c a fatal flaw was found, it's been reworked, and then got
         put back into the queue.  So complicated, not sure RFC Editor has
         caught up.  It's unclear, so I'm going to talk to RFC Editor this week
         to make sure.  This group of 20 docs is going to pop out of the RFC
         Editor's queue some day when we're not looking.
     Bill:  We're in a situation where even docs without any blocking
         references, etc, it's taking about 6 months for docs to get through
         the RFC Editor's queue.
     Alex:  Doc can stay in edit state for few weeks to few months,
         depending on how complicated the doc is.

Milestones:
    Dave:  On track - completely amazing, but we are.  In Vancouver,
         we're supposed to recharter, so bring items.
      TRILL related drafts to appear & need to see where work will
         be.
      Jumbo frames

    Alex:  Had conversation with IEEE about jumbo frames & we came to
pretty good agreement.  No objections to an informational RFC on what
people do & what to look out for.  They agreed to provide us with a
technical advisor to give us some guidance on jumbo frames.  The
thinking is that we need to decide where we want to scope this work;
whether it should stay here or be a design team between here & INT,
because they're interested also.

    Dave:  ISIS-IP has come & gone & come & gone.  Various meetings
where people want to run IPSEC over ISIS.  It might come back, but
let's save discussion for Vancouver & list.
============

1) Multi-Instance IS-IS:  Stefano Prevardi
   draft will be released very very soon

   Stefano: Idea is to allow multiple instances of ISIS to run over the
     same links.  Ships in the night approach.  Similar approach for
     OSPFv3.  Add an instance identifier via a new TLV and add to each
     ISIS packet.  Mechanism intended just to distinguish multiple
     instances.  How to forward is out of scope.

       Still need to submit draft.  Just flushing out the details.
       We're still looking at the backwards compatibility because
       routers not supporting this extension will silently ignore the
       IID TLV.  think it's similar to migration from narrow metric to
       wide metric, so not expecting any major issues.  A special IID
       value of 0 may be used to indicate the default topology to ease
       transitions.

Questions?:

Radia Perlman:  What kind of problems do you have in mind for this to
address?

Stefano:  Personally no problems, but customers want ways of having
separate topologies.  Not sharing fate, flooding scope.  Which
topologies should converge first.  What if topology 1 is having an SPF
& topology 2 that is higher priority then needs one.

Radia:  Did you have in mind something like VLANs, where you want to
have totally separate networks.  Then you'd probably have to

Dino:  I think we're at a point where we're not sending ISH

Tony Li:  Real problem I see here is to resurrect QoS routing...

Acee Lindem:  Actually, in all 3 protocols, in BGP, you can mix
address families.  In OSPF, can have a single adjacency or have per
address family/adjacency, can demux various packets.  I don't think
that there's a problem with being able to do this two different ways.
Make it easier to debug if just want separate neighbor databases,
topologies, etc.

tony Li:  Thanks, don't see how that's arguing against what I'm
saying.  There are multiple ways

Dave Ward:  Just use generic term "service separation".

Acee:  Could use this to separate IPv4 versus IPv6 or unicast versus
multicast topology.  Any way you want to slice & dice.

Dave:  Assume you want to take this to WG as an item.

Stefano:  First, we have to submit a draft.

Dave:  Details, details ....

Alex:  Just to be clear, we're not talking about adding the ID yet to
be submitted as a WG item, but talking about adding a work item to the
charter.

Dave:  yes

Dino:  Might want to consider having run on a different MAC address, so
those not participating, won't have to hear.

Stefano:  Yeah, we thought about.  I'm not sure that it brings that
much other than another method of complexity.  Would give two levels
of complexity.  We're talking about control packets so not flooding
much.

Dave:  What it would allow is routers in an LAN where some don't
support & some do.  Might help with interop.

Dino: Would help with densely meshed.  This might be something to add in
addition, so as not to bother the single instance box.

Dave:  Any comments on this.  Should all welcome Hank Smith back.  See
you all on the list.

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

---

From: "C. M. Heard" <[email-masked]>
Date: Sat, 13 Aug 2005 11:01:55 -0700 (PDT)

On Tue, 12 Jul 2005, Christian Hopps wrote:
> We are now in a "final final" WG LC on the MIB, please restrict any
> requests for modifications to changes made in the last revision. Given
> no more comments are received we will submit the MIB to the IESG
> immediately following the Paris IETF meeting.

Having seen no more comments on the list regarding this document, it
seems to me that the time has come to submit it to the IESG.

Thanks,

//cmh