headers
David Ward | 11 Jan 2007 19:37
Picon
Favicon

To standardize or not to standardize ....

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)
(Continue reading)

Permalink | Reply | 9 comments |
headers
Philip Christian | 12 Jan 2007 07:05

Re: To standardize or not to standardize ....

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

David Ward wrote:
> 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
(Continue reading)

Permalink | Reply | 1 comment |
headers
Les Ginsberg (ginsberg | 12 Jan 2007 03:16
Picon
Favicon

RE: To standardize or not to standardize ....

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:philip.christian <at> christiantena.net]
> Sent: Thursday, January 11, 2007 10:06 PM
> To: David Ward; isis-wg <at> ietf.org; chopps <at> rawdofmt.org
> Subject: Re: [Isis-wg] To standardize or not to standardize ....
> 
> 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,
(Continue reading)

Permalink | Reply | 0 comments |
headers
mike shand | 12 Jan 2007 09:58
Picon
Favicon

Re: To standardize or not to standardize ....

The list looks good to me.

         Mike

At 18:37 11/01/2007, David Ward wrote:
>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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Danny McPherson | 15 Jan 2007 04:07
Favicon

Re: To standardize or not to standardize ....


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

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

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
> ----------------------
> RI2)IS-IS Transient Blackhole Avoidance (RFC 3277) (13077 bytes)
>   Reason: No interoperability issues. SA bit in restart draft is  
> better
> mechanism

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.
(Continue reading)

Permalink | Reply | 2 comments |
headers
David Ward | 15 Jan 2007 04:33
Picon
Favicon

Re: To standardize or not to standardize ....

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

On 1/14/07 9:07 PM, "Danny McPherson" <danny <at> tcb.net> wrote:

> 
> On Jan 11, 2007, at 11:37 AM, David Ward wrote:
> 
>> 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.
> 
> Given that I've seen interop problems with this, I'd like to see
> this go standard if the others do...
(Continue reading)

Permalink | Reply | 1 comment |
headers
Danny McPherson | 15 Jan 2007 04:37
Favicon

Re: To standardize or not to standardize ....


On Jan 14, 2007, at 8:33 PM, David Ward wrote:

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

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

Thanks!

-danny
Permalink | Reply | 0 comments |
headers
Hannes Gredler | 17 Jan 2007 14:59
Favicon
Gravatar

Re: To standardize or not to standardize ....

hi dave & christian,

some comment on the optional checksums:

David Ward wrote:
> 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

> RI3)Optional Checksums in ISIS (RFC 3358) (8266 bytes)
>   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
(Continue reading)

Permalink | Reply | 0 comments |

Gmane