Re: [Technical Errata Reported] RFC5303 (2587)

I've looked at Errata 2587, 2588, 2589, 2590, 2591, 2593, and 2594 and
they appear to be correct. These are all single digit errors in
references relative to ISO 10583:2002 2nd Edition, except the last one
which asserts that the reference is wrong. Presumably the right thing
would be to fix the first six errata which would then make the seventh
errata erroneous.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street
 Milford, MA 01757 USA
 d3e3e3 <at> gmail.com

On Fri, Oct 29, 2010 at 8:54 AM, RFC Errata System
<rfc-editor <at> rfc-editor.org> wrote:
>
> The following errata report has been submitted for RFC5303,
> "Three-Way Handshake for IS-IS Point-to-Point Adjacencies".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=5303&eid=2587
>
> --------------------------------------
> Type: Technical
> Reported by: Mohammad Fahad Imteyaz <fahad_ax <at> yahoo.com>
>
> Section: 3.2

Re: [Technical Errata Reported] RFC5303 (2587)

Donald -

Errata 2594 is referring to a typo in Section 6:

"ISP 10589" should be "ISO 10589"

   Les

> -----Original Message-----
> From: isis-wg-bounces <at> ietf.org [mailto:isis-wg-bounces <at> ietf.org] On
> Behalf Of Donald Eastlake
> Sent: Sunday, October 31, 2010 5:23 PM
> To: RFC Errata System
> Cc: chopps <at> rawdofmt.org; isis-wg <at> ietf.org; fahad_ax <at> yahoo.com;
> dkatz <at> juniper.net; adrian.farrel <at> huawei.com;
> rajesh.saluja <at> tenetindia.com
> Subject: Re: [Isis-wg] [Technical Errata Reported] RFC5303 (2587)
> 
> I've looked at Errata 2587, 2588, 2589, 2590, 2591, 2593, and 2594 and
> they appear to be correct. These are all single digit errors in
> references relative to ISO 10583:2002 2nd Edition, except the last one
> which asserts that the reference is wrong. Presumably the right thing
> would be to fix the first six errata which would then make the seventh
> errata erroneous.
> 
> Thanks,
> Donald
> =============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street

Re: [Technical Errata Reported] RFC5303 (2587)

Hi Les,

You are correct. Perhaps my eyes glazed over a bit by the 7th errata.
But it was funnier the way I interpreted it.

Thanks,
Donald

On Mon, Nov 1, 2010 at 2:29 AM, Les Ginsberg (ginsberg)
<ginsberg <at> cisco.com> wrote:
> Donald -
>
> Errata 2594 is referring to a typo in Section 6:
>
> "ISP 10589" should be "ISO 10589"
>
>   Les
>
>> -----Original Message-----
>> From: isis-wg-bounces <at> ietf.org [mailto:isis-wg-bounces <at> ietf.org] On
>> Behalf Of Donald Eastlake
>> Sent: Sunday, October 31, 2010 5:23 PM
>> To: RFC Errata System
>> Cc: chopps <at> rawdofmt.org; isis-wg <at> ietf.org; fahad_ax <at> yahoo.com;
>> dkatz <at> juniper.net; adrian.farrel <at> huawei.com;
>> rajesh.saluja <at> tenetindia.com
>> Subject: Re: [Isis-wg] [Technical Errata Reported] RFC5303 (2587)
>>
>> I've looked at Errata 2587, 2588, 2589, 2590, 2591, 2593, and 2594 and
>> they appear to be correct. These are all single digit errors in

IS-IS WG LC: IS-IS Registry Extension for Purges

All -

We'd like to start the WG LC on this draft:

"IS-IS Registry Extension for Purges"
https://datatracker.ietf.org/doc/draft-ietf-isis-reg-purge/

The LC ends Nov 7 0800 PST. It is a bit unusually short but, the draft is outstandingly straightforward on
Purges and the registry organization.

Please reply with any comments.

Thanks

-DWard, CHopps

FYI - IEEE 802.1aq 1st IS-IS SPB Interop completed - some slides posted on IEEE website

We had fun plugging a few real shortest path enabled bridges together this
past week in Ottawa. Also included was a large network emulator. We managed
to get most of the SPBM functionality tested between two vendors with very
few issues. This included the IS-IS control plane (to 37 nodes), 802.1ah
data plane (ASIC and NPU based) x 2 ECT paths, and 802.1ag management plane
(L2 pings only).

We captured some lab pictures, network topology, LSP dumps, FIBs etc. and
they are available here:

http://ieee802.org/1/files/public/docs2010/aq-ashwood-interop1-1110.pdf

I won't be in Beijing but Sue Hares and Paul Unbehagan have generously
offered to talk about it briefly at the is-is wg meeting and we'll also
present a very brief overview next week in Dallas at the IEEE 802.1 meeting
in parallel.

Note that this test was based on an earlier L2 pre-split draft (so not the
most recent one) but it none the less demonstrates (using slightly different
TLV formats) most of the main moving parts.

Please let me know if you have any questions. We will put together another
round of testing to be based on the latest draft probably to take place in
Ottawa some time in late December or early in the new year. More emulators
and real or partial implementations are of course welcome to participate.  

Cheers,

Peter

Progressing draft-ietf-isis-trill

Ralph and Stewart (as ADs responsible for TRILL and ISIS WGs) have
agreed on the following way forward with regard to
draft-ietf-isis-trill.

draft-ietf-isis-trill will include a normative reference to a new
document to be produced by the TRILL WG. For the purposes of this
email we will call it draft-ietf-trill-adj.

draft-ietf-isis-trill will now proceed to the IESG for review and
approval in the normal process, but will wait in the RFC Editor's
queue on the normative reference (as it would wait for the publication
of any other normative reference) to draft-ietf-trill-adj.

draft-ietf-trill-adj will provide a state machine description of the
adjacency formation including:

- Adjacency formation
- DRB (aka DIS) election
- rules for two-way and MTU matching for advertisements
- creation/use of pseudo-nodes

Stewart and Ralph

DRAFT: ISIS agenda for IETF 79

All -

Here is the meeting for the IETF ISIS WG meeting

- administrivia
- AD direction setting on ISIS-TRILL
- .aq interop report

If you would like a short slot please let the chairs know.

Meeting time and location:

Wed Nov 10, 2010
Afternoon Session II 1510-1610
Garden Ballroom 3

-DWard, CHopps

Re: Progressing draft-ietf-isis-trill

I am struggling to appreciate the rationale behind this two document
approach.

It is as if when defining the Three-Way-Handshake (RFC 5303) it was
decided that there would be two documents - one to define the state
machine and provide exposition - and a second to define the encoding of
the TLV. It could be done this way (though I am unclear on the
motivation) - but if so there would be interdependence between the two
documents and it would not be possible to conduct a complete review of
one without the other.

I have no wish to extensively discuss "process" - so if there is
consensus that in this case we should have two documents rather than one
- I will not argue the point. But I do not see that it is logical to
review/progress draft-ietf-isis-trill independent of the proposed
draft-ietf-trill-adj (or vice versa).

   Les

> -----Original Message-----
> From: isis-wg-bounces <at> ietf.org [mailto:isis-wg-bounces <at> ietf.org] On
> Behalf Of Ralph Droms
> Sent: Sunday, November 07, 2010 5:27 PM
> To: rbridge <at> postel.org; isis list mailing
> Cc: int-ads <at> tools.ietf.org; rtg-ads <at> tools.ietf.org
> Subject: [Isis-wg] Progressing draft-ietf-isis-trill
> 
> 
> Ralph and Stewart (as ADs responsible for TRILL and ISIS WGs) have
> agreed on the following way forward with regard to

Re: Progressing draft-ietf-isis-trill

Les, you are not alone in this concern, however I've been refraining from
comment because a) I'm not there and don't know what the discussions were
and b) I'm somewhat biased given my work on competing technology.

Peter

-----Original Message-----
From: isis-wg-bounces <at> ietf.org [mailto:isis-wg-bounces <at> ietf.org] On Behalf
Of Les Ginsberg (ginsberg)
Sent: Wednesday, November 10, 2010 8:39 AM
To: Ralph Droms; rbridge <at> postel.org; isis list mailing
Cc: int-ads <at> tools.ietf.org; rtg-ads <at> tools.ietf.org
Subject: Re: [Isis-wg] Progressing draft-ietf-isis-trill

I am struggling to appreciate the rationale behind this two document
approach.

It is as if when defining the Three-Way-Handshake (RFC 5303) it was
decided that there would be two documents - one to define the state
machine and provide exposition - and a second to define the encoding of
the TLV. It could be done this way (though I am unclear on the
motivation) - but if so there would be interdependence between the two
documents and it would not be possible to conduct a complete review of
one without the other.

I have no wish to extensively discuss "process" - so if there is
consensus that in this case we should have two documents rather than one
- I will not argue the point. But I do not see that it is logical to
review/progress draft-ietf-isis-trill independent of the proposed

I-D Action:draft-ietf-isis-genapp-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IS-IS for IP Internets Working Group of the IETF.

	Title           : Advertising Generic Information in IS-IS
	Author(s)       : L. Ginsberg, et al.
	Filename        : draft-ietf-isis-genapp-04.txt
	Pages           : 12
	Date            : 2010-11-10

This draft describes the manner in which generic application
information (i.e. information not directly related to the operation
of the IS-IS protocol) should be advertised in IS-IS LSPs and defines
guidelines which should be used when flooding such information.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-isis-genapp-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
Isis-wg mailing list
Isis-wg <at> ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg