Subject: Re: [Isis-wg] Fwd: Last Call: Draft of agreement between ISOC/IET F and SO/IEC JTC1/SC6 on IS-IS protocol development to Informational

From: Alex Zinin <[email-masked]>
Date: Fri, 1 Nov 2002 16:31:08 -0800

Jeff,

> First, let me say that I think this is a great step forward.
> Having said that, it is something we should consider pretty
> carefully in the very limited time a Last Call allows.  

I don't consider the LC as the only time frame for the discussion. It
definitely encourages document review, though, and we will also spend
time on this in Atlanta. We do need, however, to have a dead line if
we want to get somewhere sooner than 5 years from now. My plan was to
discuss this on the list now, then in Atlanta and then, depending on
the results of the review, possible issue another LC if warranted.

> I re-read this last night, and started going down the list
> of current Drafts, and tried to figure out where each would
> fall.  I would be interested to see how others would sort
> the documents.  Granted that we can still publish anything
> we like: the issue is simply the status of the document.
> But it is an interesting exercise.

> For example, where
> does the M-IS-IS work fall?

Could you have chosen another draft? ;)

Seriously though, as you have probably noticed, the key point that
makes an IS-IS extension something that should be an IETF STD tracks
submission is its being Internet-specific and not generally applicable
to the generic IS-IS framework.

The reason for that is that we're NOT taking over the protocol, but
are trying to find a reasonable balance between JTC1 owning the
protocol and IETF being able to STD'ize Internet-related stuff.

It's been a while since I read the MT draft last time, but if I'm not
mistaken, the MT concept is quite generic, and hence (lacking detailed
analysis) should probably be published as Info here and go to JTC1.

One important point here is that even when we publish stuff as Info,
we still apply the STD submission process (has been happening to
latest approved ISIS spec), which allows us to request fast track
procedure in JTC1, which is supposed to be much faster (never tried,
so don't know how fast is faster.)

> Comments below marked with leading >>.

>>> So thinking out loud about the split

> 2. Definitions

>  2.1 Core IS-IS Mechanisms

>    Core IS-S Mechanisms are subsystems with associated algorithms, data
>    structures, and PDU formats as specified in (ISO/IEC 10589),
>    constituting the core of the IS-IS protocol and including the
>    following elements:

>      a)   Framework of PDU formats, including standard TLVs

>>> Standard means?  Things defined in 10589, plus anything that
> JTCL adds?  I'm a bit leary about this term, if only because
> it suggests that TLV 0x81 isn't 'standard'.  Perhaps we could
> clarify, or call this something like "JTCL Standard". 

You got it right, "standard" here and below is alias to "as specified
in (ISO/IEC 10589)" above. I'll see how this might be clarified.

>      b)   Encapsulation of PDUs

>>> Tony has spoken to this.

Note that the agreement allows us to add supplementary core mechanisms
(encapsulation included) provided that it is obvious that their
applicability is Internet-specific, not generally applicable to
the generic IS-IS framework, etc. (see my answer to Tony's message)

>      c)   Adjacency state machine and formation logic

> We have recently played in these waters
> when adding the clause about matching IP interface
> addresses on either side.

I thought about this when working on the text. I think this can be
abstracted as a supplementary PDU filtering mechanism, which is
definitely Internet-specific.

>      d)   DIS election algorithm

>      e)   Initial LSP synchronization via CSNP exchange

>      f)   Asynchronous LSP flooding (including DIS flooding behavior)

>>> The recent draft on flooding over multiple links applies

This one will have to go to ISO, unless I'm mistaken that it
is not at all Internet-specific ;)

>      g)   LSP database maintenance including LSP origination, aging, and
>           purging

>      h)   Standard topology abstraction

>>> What about "P2P over LANs"?

Same as above. Nothing Internet-specific here.

>  2.2 Internet-specific IS-IS Extensions:

>    Internet-specific IS-IS Extensions are extensions to the IS-IS proto-
>    col that are within the work scope of the IETF (including, but not
>    limited to IPv4 or IPv6 unicast and multicast routing, MPLS, MPLS TE,
>    GMPLS, or any other routing technology that the IETF decides to work
>    on in future), and:

>>> That last clause "or any other routing technology that the IETF 
> decides to work on in future)" is very vague.  Would it apply to
> MPLS, where it not already grandfathered in?  (I could argue that
> MPLS is a switching rather than routing technology) 

Yes, MPLS would be included. Whether we like it or not, it's our baby
and could be considered as another forwarding technique, complementary
to the destination-based. If/when we come up with the next gen routing
& addressing architecture, the clause will allow us to put related
extensions to STD track as well.

Thanks.

Alex

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

---

From: Jeff Parker <[email-masked]>
Date: Thu, 7 Nov 2002 10:32:38 -0500

> Jonathan,
> 
> >> I think so. The text explicitly says "MPLS"
> 
> > How would GMPLS be handled?  Is it included in the MPLS 
> statement?  Or
> > is it seen as an effort outside of the IETF?
> 
> It was definitely within the IETF last time I looked at it :) GMPLS
> should certainly be included. I thought "MPLS" would cover it, but I
> can spell it out.
> 
> Alex

Alex -

The issue is not these protocols in particular, 
but how to make sure that we have leeway for
the next project we take on.  I agree that MPLS
and GMPLS are IETF things: but reasonable people
could differ on whether they fit under the charter
below 

I shouldn't be carping without a solution in mind.
Given that we don't want to run DNS over ISIS, 
perhaps adding a clause will cover my concern on this 
phrase.

   Internet-specific IS-IS Extensions are extensions to the IS-IS proto-
   col that are within the work scope of the IETF including any
   routing or packet forwarding technology that the IETF decides to work
   on in future.

- jeff parker