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: Jeff Parker <[email-masked]>
Date: Sat, 2 Nov 2002 11:09:20 -0500

> I don't consider the LC as the only time frame for the discussion. 

Great - let's see if I can understand better the
verbage we have.  

> 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.)
> 
> 
> >      a)   Framework of PDU formats, including standard TLVs
> 
> >>> Standard means?  Things defined in 10589...?
> 
> 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.

I'll look for the clarification

> >      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.

"PDU filtering mechanisms"?  In Drama, I believe this is
called "Deus ex Machina".  I think we should call a spade 
a spade, and retain some control over adjacency formation
in IP networks.  

Consider the missing ISH in adjacency formation.  I claim 
the filtering concept doesn't apply, as we want to say it is 
acceptable to form an adjacency in the absence of the ISH.  
No amount of filtering will restore something that isn't 
there.  Help me understand why JTC1 would be motivated to
drop the requirement for the ISH.   
 
> >>> 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 ;)
> 
> >>> What about "P2P over LANs"?
> 
> Same as above. Nothing Internet-specific here.

Agreed on both.  So when we have a new idea, we
write it up/implement it, and issue an Informational
RFC and wait for JTC1 to rule on it.  Is that 
enough cover to maintain the rate of inovation?

> >  2.2 Internet-specific IS-IS Extensions:
> 
> > any other routing technology that the IETF 
> > decides to work on in future)
> 
> >>> 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.
> 
> Alex

Alex -
	I agree MPLS is our baby.  My question is, "Does the
language above cover it?"  I guess I am being legalistic,
but I find the phrase at once too broad (whatever we want
to do in the future might include re-defining 10589) and
too restrictive (routing technology may rule out MPLS).
If good fences make good neighbors, it is important that
we make the fence correct.   

- jeff parker

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

---

From: Alex Zinin <[email-masked]>
Date: Tue, 5 Nov 2002 20:24:03 -0800

Jeff,

  Sorry for the long delay. See comments below, pls.

> I'll look for the clarification

Would "specified" instead of "standard" be good enough?

> "PDU filtering mechanisms"?

yes, this could be positioned as an *additional* core mechanism
as opposed to a modification of the existing adjacency formation
logic.

> In Drama, I believe this is

I think this would be a stretch. The idea was to avoid taking
over control on the core protocol mechanisms as mush as possible
and adjacency formation is one of them... Do we have a generic
requirement that would justify going that far?

> drop the requirement for the ISH.   

This is a different case. This one could be grandfathered by
2.2 c)

> enough cover to maintain the rate of inovation?

This is almost what is already happening now, except that
I don't think anyone is actually submitting anything to JTC1.
The fast track procedure is supposed to make things
faster compared to what would happen to a regular submission
brought in by a country.

> language above cover it?"

I think so. The text explicitly says "MPLS"

> I guess I am being legalistic,

I think we're good enough here. By talking about "routing"
technologies, we identify the scope of applications for
IS-IS in the IETF (e.g., DNS over IS-IS won't fly). We then
go ahead and enumerate some specific technologies to make
sure they (and their derivatives) are included, but, of course,
we can't really come up with the exhaustive list of future
topics... I'd open to suggestions if you have some specific
text improvements in mind, but if not, again, I think we're good.

Thanks.
Alex

---

From: Les Ginsberg <[email-masked]>
Date: Wed, 06 Nov 2002 12:58:35 -0800

First, let me offer some public praise to Alex for taking on this issue and 
making some
real progress. I am pleased to see this and believe that the text of the 
draft is largely
sensible. I do believe, however, that there are significant issues on "both 
sides of the
aisle".

1)I would love to have some substantive input from the ISO side that would 
explain
who is going to handle the increased workload associated with IETF 
contributions to
IS-IS. The unfortunate story of the past few years has been that ISO has 
had difficulty
living up to its commitments associated with the Version 2 draft of ISO 10589.
As a result it has progressed very slowly and seems to currently be languishing
in a black hole for no apparent reason. Given that this work was largely 
non-controversial
and therefore did not require extensive review/discussion, it makes me 
wonder how ISO realistically
expects to take on IETF contributions, whatever the "speed" of the track, 
which are likely to
require more intensive review/discussion if only to make sure that there is 
consistency between
the ISO version and the IETF submission. What within ISO is about to change 
as regards IS-IS that will
provide additional resources??

2)The lack of IS-IS expert participation within ISO over the last few years 
has compromised the
member country TAGs ability to vote in an educated manner on IS-IS related 
issues (e.g. ISO 10589
1998 draft!!). I see nothing which makes me think IS-IS experts will be 
more active directly
in ISO TAGs in the future, so I am wondering if we could add some wording 
to the draft which states that when
the IETF reviews JTC1/SC6 IS-IS related work (under draft section 3.3.4) 
that the recommendations
of the IETF be forwarded to all member country TAGs to be used as input to 
their voting decision.
This would at least provide them with some expert opinion to use a basis 
for a vote.

3)When the IETF submits an info RFC to JTC1 for fast track approval (under 
3.3.2) I am wondering what
form the corresponding ISO document is expected to take? Are we thinking 
that the substance of the
RFC will be incorporated into a revised version of ISO 10589? Either as a 
DR or a TC? Or will there
simply be a list of RFCs which are considered formally approved by ISO? 
While the form may differ
for each case, the work involved to transform the RFC into ISO form while 
preserving
consistency with the original may well be considerable. Which leads me to...

4)I would love to see a "show of hands" as to how many of the authors of 
drafts/RFCs which fall
into the category of extensions required to be submitted to ISO under 
Section 3.1 are ready and willing
to commit to the work required to:

a)Meet the requirements associated with IETF standards track RFCs
b)Transform the extension into an ISO approved form and shepherd the 
document through the
   ISO approval process

Without an overwhelming majority commitment to this work, the agreement 
defined in the draft will
not be worth much.

As an aid to the "show of hands" I have tried to make a list of current 
work which I believe
falls into the category of extensions requiring ISO approval. I am sure 
there may be differences
of opinion on how accurate my list is, but I believe it is not too far off 
the mark and certainly
serves to demonstrate the point that we must be committed to do some real 
work to make this
agreement meaningful, and if we are not, then why bother.

IS-IS Automatic Encapsulation
Recommendations for Interoperable Networks using IS-IS
TLV for Proprietary Use
Restart signaling for ISIS
Extending the Number of IS-IS LSP Fragments Beyond the 256 Limit
Use of OSI IS-IS for Routing in TCP/IP and Dual Environments (RFC 1195)
IS-IS Mesh Groups (RFC 2973)
Optional Checksums in ISIS (RFC 3358)
Three-Way Handshake for IS-IS Point-to-Point Adjacencies (RFC 3373)

6)As to how we evaluate whether IETF work falls inside or outside the "core 
IS-IS mechanisms"
definition, it seems to me that the litmus test should(must?) be "Would 
implementations which are
strictly conformant to ISO 10589 have interoperability problems with 
implementations using the
extension?" If the answer is YES then we have mucked with the core. By way 
of example, certainly
the extensions used for adjacency formation have been demonstrated to cause 
interoperability
issues with strict ISO 10589 implementations so it seems we have no choice 
but to submit
these to ISO.

    Les

---

From: Alex Zinin <[email-masked]>
Date: Wed, 6 Nov 2002 23:56:04 -0800

Les,

Wednesday, November 06, 2002, 12:58:35 PM, Les Ginsberg wrote:
> First, let me offer some public praise to Alex for taking on this
> issue and making some real progress. I am pleased to see this and
> believe that the text of the draft is largely sensible. I do
> believe, however, that there are significant issues on "both sides
> of the aisle".

Thanks for your positive feedback and detailed comments,
please see my answers below.

> 1)I would love to have some substantive input from the ISO side that
> would explain who is going to handle the increased workload
> associated with IETF contributions to IS-IS. The unfortunate story
> of the past few years has been that ISO has had difficulty living up
> to its commitments associated with the Version 2 draft of ISO 10589.
> As a result it has progressed very slowly and seems to currently be
> languishing in a black hole for no apparent reason. Given that this
> work was largely non-controversial and therefore did not require
> extensive review/discussion, it makes me wonder how ISO
> realistically expects to take on IETF contributions, whatever the
> "speed" of the track, which are likely to require more intensive
> review/discussion if only to make sure that there is consistency
> between the ISO version and the IETF submission. What within ISO is
> about to change as regards IS-IS that will provide additional
> resources??

I will take your question to the JTC1/SC6 folks for comments.
Meanwhile, I'd like to note that the fast-track process is supposed to
be simpler and faster than the one for the regular submissions, but
no, I don't have the first hand experience.

> 2)The lack of IS-IS expert participation within ISO over the last
> few years has compromised the member country TAGs ability to vote in
> an educated manner on IS-IS related issues (e.g. ISO 10589 1998
> draft!!). I see nothing which makes me think IS-IS experts will be
> more active directly in ISO TAGs in the future, so I am wondering if
> we could add some wording to the draft which states that when the
> IETF reviews JTC1/SC6 IS-IS related work (under draft section 3.3.4)
> that the recommendations of the IETF be forwarded to all member
> country TAGs to be used as input to their voting decision. This
> would at least provide them with some expert opinion to use a basis
> for a vote.

This is a very reasonable request, and will take to it JTC1/SC6 guys.
In fact, I suspect that as a Category A liaison, we already have
the capability to provide our comments to the NBs, but definitely
the document would benefit from making this clear.

> 3)When the IETF submits an info RFC to JTC1 for fast track approval
> (under 3.3.2) I am wondering what form the corresponding ISO
> document is expected to take? Are we thinking that the substance of
> the RFC will be incorporated into a revised version of ISO 10589?
> Either as a DR or a TC?

Good question. I can't say for sure if it will be possible to
maintain one-to-one correspondence between IETF and JTC1 docs.
I will clarify this.

> Or will there simply be a list of RFCs which
> are considered formally approved by ISO?

I don't think this is the case. From reading the JTC1 procedures,
it should finally be published as an International Standard spec.

> for each case, the work involved to transform the RFC into ISO form
> while preserving consistency with the original may well be
> considerable. Which leads me to...

Actually, reading the same source, it seems to be a bit better
than that:

> 13.9 If, after the deliberations of this ballot
> resolution group, the requirements of 9.6 are met,
> the Project Editor shall prepare the amended DIS
> (or DAM) and send it to the SC Secretariat who
> shall forward it to the ITTF for publication as an IS.
> For its initial publication, the document is not
> required to be in ISO/IEC format, but can be
> published in the format of the submitting
> organization.

> a)Meet the requirements associated with IETF standards track RFCs

FWIW, we're already operating in this mode, i.e., the IESG
requests the IETF WG LC for the documents coming from the ISIS WG.

> b)Transform the extension into an ISO approved form

see my comment above

> and shepherd the 

this one will indeed be necessary. As the text of the agreement
and JTC1 procedures say, there should be a "Project Editor", who'll
be willing to coordinate with JTC1 to get things done.

> defined in the draft will

Sort of. If no one takes an Info RFC to JTC1 for any reason, we will
be no worse than today (note the SHOULD in the text).

What the agreement does is essentially the following three things:

 1. Explicitly clarify what ISIS documents the IETF can put
    on its STD track (I do believe we should be able to STD'ize
    Internet-related technology)

 2. Give guidelines for the mode we're kind of operating in--
    publish Info RFC and submit to JTC1

 3. Solve the ISIS registry problem.

The approach was to have a good enough result and make sure
that if something doesn't work (such as the submission to
JTC1 part), we don't get in a situation worse than we are in
at the moment. In fact if bullet 2 above does not work, we
still have bullets 1 and 3 that are helpful.
 
> As an aid to the "show of hands" I have tried to make a list of
> current work which I believe falls into the category of extensions
> requiring ISO approval. I am sure there may be differences of
> opinion on how accurate my list is, but I believe it is not too far
> off the mark and certainly serves to demonstrate the point that we
> must be committed to do some real work to make this agreement
> meaningful, and if we are not, then why bother.

I don't want us to argue on this much, but here's some
> Recommendations for Interoperable Networks using IS-IS

I recommended that this one was split into IETF-specific
and ISO-specific parts, which Jeff did. The former should
not have to go there, the latter should, of course.

> Use of OSI IS-IS for Routing in TCP/IP and Dual Environments (RFC 1195)

This one is an IETF STD doc, so it actually can't go there.

> 6)As to how we evaluate whether IETF work falls inside or outside
> the "core IS-IS mechanisms" definition, it seems to me that the
> litmus test should(must?) be "Would implementations which are
> implementations using the extension?" If the answer is YES then we
> have mucked with the core.

Right, and I think the text in section 2.2 emphasizes this a lot, as
well as tries to find a balance between a strict "stop right there"
and our ability to do STD'ize useful things we develop for IP and
those we've already done.

> By way of example, certainly the
> extensions used for adjacency formation have been demonstrated to
> cause interoperability issues with strict ISO 10589 implementations
> so it seems we have no choice but to submit these to ISO.

This should probably be in a more specific discussion.

Thanks again.

Alex