Subject: [Isis-wg] To standardize or not to standardize ....

From: David Ward <[email-masked]>
Date: Thu, 11 Jan 2007 12:37:34 -0600

All -

As discussed at the last WG we (w/ help from Les Ginsberg) created a
proposed list of items in ISIS to standardize, the ones that cause ambiguity
and those NOT to be standardized.

The full  suggested list follows. Please discuss if the list needs
add/deletes/mods. We will present this list (w/ edits from the WG) in Prague
(amongst other things) and explain to the authors and the WG how get from
INFO to PS at that time. Again the goal is to get all the specs that had to
be INFO in the past due to inter-stds body issues (that have been since
resolved) to PS.

-DWard, CHopps

Special note: the items which provoked the most ambiguity were,

DI1)Point-to-point operation over LAN in link-state routing protocols
(draft-ietf-isis-igp-p2p-over-lan-06.txt)

and

Generic Routing Encapsulation over CLNS Networks (RFC 3147) ??? (not on WG
agenda)

Should Be Standard
-------------------
RS1)Use of OSI IS-IS for Routing in TCP/IP and Dual Environments (RFC 1195)

RS2)Dynamic Hostname Exchange Mechanism for IS-IS (RFC 2763)

RS3)Domain-wide Prefix Distribution with Two-Level IS-IS (RFC 2966)

RS4)Three-Way Handshake for IS-IS Point-to-Point Adjacencies (RFC 3373)

RS5)Intermediate System to Intermediate System (IS-IS)Cryptographic
Authentication (RFC 3567)

RS6)IS-IS extensions for Traffic Engineering (RFC 3784)

RS7)Restart signaling for IS-IS (RFC 3847)

RS8)Intermediate System to Intermediate System (IS-IS) Extensions in Support
of Multi-Protocol Label Switching (GMPLS) (RFC 4205)

RS9)Management Information Base for Intermediate System to Intermediate
System (IS-IS) (RFC 4444)

RS10)Routing IPv6 with IS-IS (draft-ietf-isis-ipv6-06.txt)

DS1)M-ISIS: Multi Topology (MT) Routing in IS-IS
(draft-ietf-isis-wg-multi-topology-11.txt)

DS2)A Policy Control Mechanism is IS-IS Using Administrative Tags
(draft-ietf-isis-admin-tags-03.txt)

DS3)Definition of an IS-IS Link Attribute sub-TLV
(draft-ietf-isis-link-attr-02.txt)

DS4)IPv6 Traffic Engineering in IS-IS (draft-ietf-isis-ipv6-te-03.txt)

DS5)IS-IS Extensions for Advertising Router Information
(draft-ietf-isis-caps-06.txt)

DS6)Simplified Extension of LSP Space for IS-IS
(draft-ietf-isis-wg-extlsp-00.txt)

DS7)IS-IS HMAC SHA Cryptographic Authentication
(draft-ietf-isis-hmac-sha-00.txt)

DS8)Generic Routing Encapsulation over CLNS Networks (RFC 3147) ??? (not on
WG agenda)

MAY be a Standard
------------------
DI1)Point-to-point operation over LAN in link-state routing protocols
(draft-ietf-isis-igp-p2p-over-lan-06.txt)
   Reason:Technically, this is mainly a consistent configuration issue and
so could be informational. However, if, for example, the ISs multicast
address is not used by everyone for sending PDUs, then some could be missed
depending on whether a system was L1 or L1L2.

Should NOT Be Standard
----------------------
RI1)IS-IS Mesh Groups (RFC 2973) (14846 bytes)
  Reason: No interoperability issues

RI2)IS-IS Transient Blackhole Avoidance (RFC 3277) (13077 bytes)
  Reason: No interoperability issues. SA bit in restart draft is better
mechanism

RI3)Optional Checksums in ISIS (RFC 3358) (8266 bytes)
  Reason: Cryptographic Auth provides better functionality

RI4)Reserved TLV Codepoints in ISIS (RFC 3359) (7843 bytes)
  Reason: Obsolete - replaced by IANA registry

RI5)Recommendations for Interoperable Networks using IS-IS (RFC 3719) (33939
bytes)
   Reason: This is intended to be an informational/BCP type of document.

RI6)Extending the Number of IS-IS LSP Fragments Beyond the 256 Limit (RFC
3786) (29164 bytes)
   Reason: Soon to be obsolete

RI7)Recommendations for Interoperable IP Networks using IS-IS (RFC 3787)
(25426 bytes)
   Reason: This is intended to be an informational/BCP type of document.

RI8)Cooperative Agreement Between the ISOC/IETF and ISO/IEC Joint Technical
Committee 1/Sub Committee 6 (JTC1/SC6) on IS-IS Routing Protocol Development
(RFC 3563)
   Reason: Administrative

RI9)Calculating Interior Gateway Protocol (IGP) Routes Over Traffic
Engineering Tunnels (RFC 3906)
   Reason: Different algorithms can still interoperate - although it is good
to have one expected behavior.

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

---

From: Philip Christian <[email-masked]>
Date: Thu, 11 Jan 2007 22:05:35 -0800

Concerning RFC 3147:-
The same encapsulation mechanism is specified in ITU-T G.7712. This 
would suggest maybe that it should be a standard; however it has nothing 
to do with IS-IS routing. It's an encapsulation technique for IP over 
CLNP/CLNS, not a routing protocol.
If it needs some work then as the original author I would be up for it.
I would like to hear what the confusion is as it seems pretty simple to me.

Concerning TLV 16:-
TLV 16 is still listed in IANA isis-tlv-codepoints as being a draft, 
which is now long since dead.  However TLV 16 is also specified in ITU-T 
G.7712.  I don't understand after all this time why the IANA doc doesn't 
state this.  One day someone will forget this and the ISIS WG will 
re-use it causing a horrible clash with ITU-T G.7712; and it would be so 
easy to fix. It seems a no-brainer to mention G.7712 in 
isis-tlv-codepoints to me and yet it doesn't happen.

Regards,

Philip Christian

---

From: "Les Ginsberg \(ginsberg\)" <[email-masked]>
Date: Thu, 11 Jan 2007 18:16:19 -0800

Philip -

I think the "???" regarding RFC 3147 was not so much related to content
but rather as to whether it is officially regarded as owned by the IS-IS
WG. It is not listed on the WG Web page.

I generally try to plead ignorance on administrative issues. :-)

   Les

> -----Original Message-----
> From: Philip Christian [mailto:[email-masked]]
> Sent: Thursday, January 11, 2007 10:06 PM
> To: David Ward; [email-masked]; [email-masked]
> Subject: Re: [Isis-wg] To standardize or not to standardize ....
> 
> Concerning RFC 3147:-
> I would like to hear what the confusion is as it seems pretty simple
to
> me.
> > add/deletes/mods. We will present this list (w/ edits from the WG)
in
> Prague
> > INFO to PS at that time. Again the goal is to get all the specs that
had
> to
> > Generic Routing Encapsulation over CLNS Networks (RFC 3147) ??? (not
on
> WG
> > agenda)
> >
> >
> >
> > Should Be Standard
> > -------------------
> > RS1)Use of OSI IS-IS for Routing in TCP/IP and Dual Environments
(RFC
> 1195)
> > DS8)Generic Routing Encapsulation over CLNS Networks (RFC 3147) ???
(not
> on
> >    Reason:Technically, this is mainly a consistent configuration
issue
> > RI5)Recommendations for Interoperable Networks using IS-IS (RFC
3719)
> (33939
> >    Reason: Different algorithms can still interoperate - although it
is
> good

---

From: mike shand <[email-masked]>
Date: Fri, 12 Jan 2007 08:58:38 +0000

The list looks good to me.

         Mike

---

From: Danny McPherson <[email-masked]>
Date: Sun, 14 Jan 2007 20:07:35 -0700

On Jan 11, 2007, at 11:37 AM, David Ward wrote:

> issue and

Given that I've seen interop problems with this, I'd like to see
this go standard if the others do...

> Should NOT Be Standard

While I agree with the conclusion I don't agree with the reason,
unless you're also proposing removing the OL bit altogether
when the move to Standard of the base spec occurs?  I'm not
aware of anyone using the SA-bit for this functionality today,
though I am aware of several folks using the OL-bit functionality.

I agree with the rest...

-danny

---

From: David Ward <[email-masked]>
Date: Sun, 14 Jan 2007 21:33:41 -0600

Danny -

    The OL bit is NOT going to be removed when we PS the base spec. Given
this (and if I get the wording of your statement on 3277 below), I don't
think that 3277 can move to PS as there aren't any protocol changes proposed
in 3277. As you state below, you agree w/ the conclusion to keep it INFO.
Just double checking, are we good to go?

I agree the functionality in 3277 is useful and widely deployed.

-DWard

---

From: Danny McPherson <[email-masked]>
Date: Sun, 14 Jan 2007 20:37:34 -0700

> Just double checking, are we good to go?

Yep, correct, conclusion was fine, just wanted to clarify reasoning.
3277 doesn't have any protocol changes..

Thanks!

-danny

---

From: Hannes Gredler <[email-masked]>
Date: Wed, 17 Jan 2007 14:59:42 +0100

hi dave & christian,

some comment on the optional checksums:

>   Reason: Cryptographic Auth provides better functionality

i'd put this on the standard list - it may be true that MD5 provides
better protection, however one of the pro's of optional checksums is
that it requires zero configuration making it a candidate for
new default behaviour ...

/hannes