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

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

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

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

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

6. 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 | to 20
| Additional Application | to (252 -
| Specific Information | len of IP Address info)

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

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

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

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

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

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

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

14. WG Item???