Advertising Generic Information in IS-IS draft-ginsberg-isis-genapp-01.txt Les Ginsberg Stefano Previdi Mike Shand

Topics Review of the basic functionality (no change since V-00) Changes in V-01: Use of MI Contrast w Experimental

Use of TLV Codepoints Number of TLV codepoints is limited to 256 Currently 37 have been assigned Application Advertisements Could Consume this space

Use of sub-TLVs Use of sub-TLVs (introduced by RFC 3784) provides additional codepoints within the context of the parent TLV Multiple levels of sub-TLVs are allowed but create encoding inefficiency Encoding inefficiency increases the likelihood that a single TLV (255 octets) will be insufficient to describe all attributes for an object

GENAPP Solution Assign one TLV for use by all applications Define an Application ID to provide a unique context for each application Each application has 256 sub-TLV codepoints No additional TLV codepoints required ever!! Minimizes need for nested sub-TLVs Can be advertised only in LSPs – not IIHs/SNPs

TLV Format Type 251 (proposed) Length # of octets in the value field (3 to 255) Value: No. of octets +-----------------------------+ | Flags | 1 | Application ID | 2 | Application | | IP Address Info | 0 to 20 | Additional Application | 0 to (252 - | Specific Information | len of IP Address info)

Field Description 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Rsvd |V|I|D|S| Flags S – Domain wide flooding D – Down bit I – IPv4 address follows V- IPv6 address follows Application ID – assigned by IANA Application IP Address Info: IPv4 and/or IPv6 address for application (not necessarily a Router ID)

Flooding Procedures Each GENAPP TLV describes exactly one application Information with different flooding scopes requires different TLVs S-bit => domain-wide flooding D-bit set indicates L2->L1 leaking has occurred – do NOT leak back into L2 Do NOT use information in the LSP of an unreachable system – could be stale Updates SHOULD be advertised in the same LSP # whenever possible

Why Use IS-IS for Application Info There is no good reason!!  IS-IS primary function is in support of routing Advertisement of non-routing related info compromises the efficiency

By Popular Demand… IS-IS Update mechanism is attractive: Reliable Scaleable Proven to work Use of a separate instance minimizes impact on routing Independent control of flooding and processing

Use with Caution DAMPENING MUST BE DONE!! Sending additional information has the potential to negatively impact performance of the protocol DAMPENING MUST BE DONE!!

Relationship to Router Capabilities draft-ietf-isis-caps-06.txt Reserved for router capabilities (not applications) Format is not as flexible (all sub-TLVs share same context) Same flooding rules

Relationship to experimental draft-ietf-isis-experimental-tlv-05.txt Advertise information for apps which are documented publicly Uses MUST be standardized

WG Item???