I-D Action:draft-ietf-isis-trill-05.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           : TRILL Use of IS-IS
	Author(s)       : D. Eastlake 3rd, et al.
	Filename        : draft-ietf-isis-trill-05.txt
	Pages           : 30
	Date            : 2011-02-02

The IETF has standardized the TRILL protocol, which provides
transparent Layer 2 forwarding using encapsulation with a hop count
and IS-IS link state routing. This document specifies the data
formats and code points for the IS-IS extensions to support TRILL.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-isis-trill-05.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

I-D ACTION:draft-ietf-isis-ieee-aq-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		: IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging
	Author(s)	: D. Fedyk, P. Ashwood-Smith, D. Allan, N. Bragg, P. Unbehagen
	Filename	: draft-ietf-isis-ieee-aq-04.txt
	Pages		: 40
	Date		: 2011-2-2
	
802.1aq Shortest Path Bridging (SPB) is being standardized by the 
   IEEE as the next step in the evolution of the various spanning tree 
   and registration protocols. 802.1aq allows for true shortest path 
   forwarding in a mesh Ethernet network context utilizing multiple 
   equal cost paths. This permits it to support much larger layer 2 
   topologies, with faster convergence, and vastly improved use of the 
   mesh topology. Combined with this is single point provisioning for 
   logical connectivity membership, which includes point-to-point, 
   point-to-multi-point and multi-point-to-multipoint variations. This 
   memo documents the IS-IS changes required to support this IEEE 
   protocol and provides some context and examples.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-isis-ieee-aq-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

Re: trill-adj Section 3.3 comments

Hi,

On Mon, Jan 31, 2011 at 5:19 AM, Les Ginsberg (ginsberg)
<ginsberg <at> cisco.com> wrote:
>...
>
>> -----Original Message-----
>> From: Donald Eastlake [mailto:d3e3e3 <at> gmail.com]
>> Sent: Thursday, January 27, 2011 6:52 PM
>> To: Les Ginsberg (ginsberg); rbridge <at> postel.org
>> Subject: trill-adj Section 3.3 comments
>>
>> Response to some comments by Les Ginsberg:
>>
>> > Section 3.3
>> > -------------
>>
>> > Text says that for hellos received on a VLAN Other than the D-VLAN
>>
>> > "any TRILL Neighbor TLV in such a Hello is ignored..."
>>
>> > I assume this means that it is an implementation choice as to
>> > whether to include the neighbor TLV in such hellos? A clear
>> > statement of this would be helpful.
>>
>> To avoid the posibility of temporary confusion if there is a change in
>> the Designated VLAN, the TRILL Neighbor TLV sent on a VLAN should
>> reflect the neighbors seen on that VLAN. Since an implementation
>> conformant to this draft is only assured of having per VLAN neighbor
>> information for the Deisgnated VLAN, I think something like the

trill-adj

Response to some comments by Les Ginsberg:

> Preventing Multiple DRBs on a LAN
> ---------------------------------

> It is not clear to me how the use of multiple announcing VLANs
> achieves the stated goal of one and only one DRB in the presence of
> inconsistent connectivity / configuration.

Sending Hellos on multiple VLANs doesn't guarantee one DRB on a link
in the presence of arbitrary port and bridge configuration, which is
why there are two additional loop safety mechanisms in TRILL. But it
does a lot better than sending Hellos on only one VLAN.

> Consider the following
> simple example where VLANs(1,2,3) are in the enabled set on all RBs:

> RB Name/     DVLAN   Announcing VLANs   VLAN Connectivity
> Priority
> --------------------------------------------------------
> RB1/50         1       1,2              1,2,3
> RB2/60         1       1                1
> RB3/70         3       2                2,3

Configuring Announcing VLANs to be anything less than the default of
all enabled VLANs is to deliberately accept an increased risk of loops
in return for fewer Hellos. If you leave Announcing VLANs at its
default value, there is no problem in this case.

In the TRILL working group, the two main opinions were that RBridges

Re: [rbridge] WG last call on draft-ietf-trill-adj-01.txt

Hi Mike,

I think I failed to respond to your message below. Sorry. You wording
looks fine to me.

Thanks,
Donald

On Tue, Jan 18, 2011 at 7:44 AM, mike shand <mshand <at> cisco.com> wrote:
>  To be absolutely clear on this, perhaps the text should also describe what
> the non DRBs do. I appreciate that the example includes this,
> but it is somewhat anomalous that the normative text describes the changed
> actions of the DRB, but not (explicitly) those of the non-DRBs.
>
> So how about:-
>
>
> "If the DRB sets the bypass pseudonode bit in its TRILL
>   LAN Hellos, the RBridges on the link (including the DRB) just directly
> report all their
>   adjacencies on the LAN that are in the Report state. If the DRB does not
> set the
>   bypass pseudonode bit in its TRILL Hellos, then (as in ISO/IEC 10589) it
> sends LSPs on behalf of the pseudonode, and all RBridges report only their
> adjacency to the pseudonode. Setting the bypass pseudonode bit has no effect
> on how LSPs
>   are flooded on a link. It only affects what LSPs are generated."
>
>
>    Mike

Re: [rbridge] I-D Action:draft-ietf-trill-adj-02.txt

This version has changes from earlier resolved comments incorporated.
Donald

On Mon, Feb 7, 2011 at 11:30 PM,  <Internet-Drafts <at> ietf.org> wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Transparent Interconnection of Lots of Links Working Group of the IETF.
>
>
>        Title           : RBridges: Adjacency
>        Author(s)       : D. Eastlake 3rd, et al.
>        Filename        : draft-ietf-trill-adj-02.txt
>        Pages           : 27
>        Date            : 2011-02-07
>
> The IETF TRILL protocol provides optimal pair-wise data forwarding
> without configuration, safe forwarding even during periods of
> temporary loops, and support for multipathing of both unicast and
> multicast traffic. TRILL accomplishes this by using IS-IS link state
> routing and by encapsulating traffic using a header that includes a
> hop count. Devices that implement TRILL are called RBridges.
>
> TRILL supports multi-access LAN links that can have multiple end
> stations and RBridges attached. This document describes the TRILL LAN
> Hello protocol used on such links as regards adjacency, designated
> RBridge selection, and MTU procedures, with state machines. There is
> no change for IS-IS point-to-point Hellos used on links configured as
> point-to-point in TRILL.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-trill-adj-02.txt

RFC 6119 on IPv6 Traffic Engineering in IS-IS

A new Request for Comments is now available in online RFC libraries.

        
        RFC 6119

        Title:      IPv6 Traffic Engineering in IS-IS 
        Author:     J. Harrison, J. Berger,
                    M. Bartlett
        Status:     Standards Track
        Stream:     IETF
        Date:       February 2011
        Mailbox:    jon.harrison <at> metaswitch.com, 
                    jon.berger <at> metaswitch.com, 
                    mike.bartlett <at> metaswitch.com
        Pages:      10
        Characters: 21146
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-isis-ipv6-te-08.txt

        URL:        http://www.rfc-editor.org/rfc/rfc6119.txt

This document specifies a method for exchanging IPv6 traffic 
engineering information using the IS-IS routing protocol.
This information enables routers in an IS-IS network to 
calculate traffic-engineered routes using IPv6 addresses.
[STANDARDS-TRACK]

This document is a product of the IS-IS for IP Internets Working Group of the IETF.

Re: trill-adj Section 4 comments

Hi Les,

On Mon, Jan 31, 2011 at 4:44 AM, Les Ginsberg (ginsberg)
<ginsberg <at> cisco.com> wrote:
> Donald -
>...
>
>> -----Original Message-----
>> From: Donald Eastlake [mailto:d3e3e3 <at> gmail.com]
>> Sent: Thursday, January 27, 2011 11:24 AM
>> To: Les Ginsberg (ginsberg); rbridge <at> postel.org
>> Subject: trill-adj Section 4 comments
>>
>> Response to some comments by Les Ginsberg:
>>
>> > Section 4
...

>> I could make this into a separate sub-section, add references to it,
>> and perhaps re-word as follows:
>>
>>    Events 3 and 4 consistute losing and winning the DRB election at
>>    the port, respectivly.
>>
>>    The candidates are the local RBridge and all RBridges with which
>>    there is an adjacency on the port in a state other than Down. The
>>    winner is the RBridge with highest priority to be DRB, as
>>    determined from the 7-bit priority field in the Hellos received and
>>    the local port's priority to be DRB field, with MAC address (SNPA)
>>    as a tie breaker and Port ID as a secondary tie breaker. These

Last Call: <draft-ietf-isis-reg-purge-00.txt> (IS-IS Registry Extension for Purges) to Proposed Standard

The IESG has received a request from the IS-IS for IP Internets WG (isis)
to consider the following document:
- 'IS-IS Registry Extension for Purges'
  <draft-ietf-isis-reg-purge-00.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf <at> ietf.org mailing lists by 2011-02-23. Exceptionally, comments may be
sent to iesg <at> ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-isis-reg-purge/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-isis-reg-purge/

Please note that this document includes a normative reference to ISO/IEC 10589:2002

This last call is issued to draw the attention of the community to the following
Gen-Art observation:

"The (previous) last call did not included the note that for historical reasons the registry 
this document updates was established by an Informational RFC (RFC 3563) 
and therefore this Proposed Standard has a normative dependence upon 
that Informationl RFC."

No IPR declarations have been submitted directly on this I-D.

Protocol Action: 'Extensions to IS-IS for Layer-2 Systems' to Proposed Standard (draft-ietf-isis-layer2-10.txt)

The IESG has approved the following document:
- 'Extensions to IS-IS for Layer-2 Systems'
  (draft-ietf-isis-layer2-10.txt) as a Proposed Standard

This document is the product of the IS-IS for IP Internets Working Group.

The IESG contact persons are Stewart Bryant and Adrian Farrel.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-isis-layer2/

Technical Summary

This document specifies the IS-IS extensions necessary to support
link state routing to any protocols running directly over layer 2.
While supporting this concept involves several pieces, this document
only describes extensions to IS-IS. Furthermore, the TLVs described
in this document are generic layer 2 additions and specific ones as
needed are defined in the IS-IS technology specific extensions.

Working Group Summary

Issues arose as this document, draft-ietf-isis-trill and draft-ietf-isis-ieee-aq 
were originally one document. It was felt during review that 
draft-ietf-isis-trill and draft-ietf-isis-ieee-aq were sufficiently
different that there needed to be a "base" document (this one) 
and two separate technology documents. The opinion of the ISIS 
WG it is unfortunate that there could not be one solution for 
layer2 routing in ISIS but, this decision was not within the remit 
of the ISIS WG.