trill 4

Views:
 
Category: Entertainment
     
 

Presentation Description

No description available.

Comments

Presentation Transcript

Future TRILL Work: 

Future TRILL Work Donald Eastlake 3rd +1-508-786-7754 Donald.Eastlake@motorola.com

Future TRILL Work: 

Future TRILL Work Potential Future TRILL Work/Documents: IS-IS details (PDU TLVs, etc.) Management (MIB) TRILL Header Options ARP/ND/IP/… Optimization 802.1 Features Customer versus Service Rbridges (802.1ad) Connectivity Fault Management (802.1ag) Congestion Management (802.1au)

Questions on These Work Items: 

Questions on These Work Items Is the item important/high-value? Is the item urgent/time-sensitive? Who would like to work on it?

IS-IS Details: 

IS-IS Details Draft-ward-l2isis-02 defines some TLVs and an additional PDU for use with any Layer 2 application of IS-IS. An additional document is needed specifying details of how to use the facilities defined in IS-IS and in ward-l2isis and specifying some TRILL sub-TLVs.

Management (MIB): 

Management (MIB) Possibly three components: Bridge MIB stuff (Tweaked citations to RFC 4188? E.g., no STP) IS-IS MIB stuff (Tweaked citations to RFC 4444?) RBridge stuff Nickname configuration End station address learning priorities …

TRILL Header Options: 

TRILL Header Options Document to specify the general format and processing for options and some specific options: Port IDs (local port IDs so egress RBridge DA lookup is not needed if learned from data) Flow ID TRILL data frame security (based on IS-IS keys) Optimizations Etc.

IP Related Optimizations: 

IP Related Optimizations ARP/ND optimization was included in the paper cited in our Charter and in early protocol drafts but was removed from base specification by WG consensus, to be placed in a separate document. Included learning IP addresses and sometimes responding to ARP/ND.

Customer/Service RBridges: 

Customer/Service RBridges IEEE 802.1ad-2005 “Provider Bridges” is a completed amendment to 802.1Q. (not to be confused with the in process 802.1ah “Provider Backbone Bridges” amendment) Provider Bridges outer S-Tags and are transparent to some bridging multicast addresses. “Provider Edge Bridges” talk C-Tags (formerly called Q-Tags) on customer ports and S-Tags on provider ports. Should it be possible to configure Rbridges as Provider or Provider Edge Bridges and/or incrementally replaced such bridges with RBridges?

Connectivity Fault Management: 

Connectivity Fault Management 802.1ag current at Draft D8.0: ~‘… protocols to support transport fault management. These allow discovery and verification of the path, through bridges and LANs, taken for frames and isolation of a connectivity fault to a specific bridge or LAN. Networks are operated by multiple organizations, with restricted management access to each other's equipment. This standard provides capabilities for detecting, verifying and isolating connectivity failures ...’~ Does anything need to be done to Rbridges to support 802.1ag?

Congestion Management (802.1Qau): 

Congestion Management (802.1Qau) Layer 2 method to rate limit flows causing congestion. Has been progressing slowing in 802.1 but an update from Draft D0.1 to Draft D0.2 was authorized last week. Some changes to Rbridges beyond those required in 802.1 Bridges would be required to support 802.1Qau. For example, a congestion control message in response to a TRILL data frame should get back to the true origin station, not just the ingress RBridge. Latest thinking in 802.1 is that this may need to be augmented by Per Priority Pause (PPP).

authorStream Live Help