Subject: [Isis-wg] RE: draft-martin-neal-policy-isis-admin-tags-05.txt - additions a nd c orrections

From: "Martin, Christian" <[email-masked]>
Date: Tue, 16 Apr 2002 17:38:41 -0400

Naiming,

Agreed.  I wanted to make sure this was explicit.  Changing TLV contents is
not allowed, except at are borders when creating new LSPs.  I shall
incorporate the language and resend to the group.  If there are no
objections, I will submit to the rfc-editor.

chris

>-----Original Message-----
>From: Naiming Shen [mailto:[email-masked]] 
>Sent: Tuesday, April 16, 2002 4:40 PM
>To: Martin, Christian
>Cc: [email-masked]'; 'stefano previdi'; Tony 
>Li; 'Tony Przygienda'; Hannes Gredler; [email-masked]
>Subject: Re: draft-martin-neal-policy-isis-admin-tags-05.txt - 
>additions and c orrections 
>
>
>
>we don't have the right to touch(alter) someone else's packet. 
>in the leaking case, we form our new packets, so we can do 
>whatever we want.
>
>thanks.
>
> ] Ok, here are the incorporated changes.  One issue I have to 
>address and  ] (hopefully) get comments on is the SubTLV 
>changing/deletion issue.  ] Originally, we had specified the 
>possibility of an IS deleting or reordering  ] a (set) of 
>SubTLV(s).  My concern after thinking on it is that this isn't 
> ] possible without causing the LSP to be invalidated because 
>of the new  ] checksum.  Before I submit, I'd like to get 
>comments on this.  I have  ] included verbage in section 6 
>that states this, however, I have also  ] included the 
>possibility of changing the subTLVs in section 7.  I am  ] 
>thinking we should NOT allow the SubTLV contents to be altered 
>except at  ] L2/L1 boundaries, where new LSPs are originated.  
>Thoughts?  ] 
> ] Regards,
> ] chris
> ] 
> ] 
> ] 
> ] 
> ] 
> ] Network Working Group                                   
>Christian Martin
> ] INTERNET DRAFT                             Verzion Global 
>Networks, Inc.
> ]                                                             
>   Brad Neal
> ]                                                 Broadwing 
>Communications
> ]                                                          
>Stefano Previdi
> ] April 2002                                                 
>Cisco Systems
> ] 
> ] 
> ] 
> ]      A Policy Control Mechanism is IS-IS Using Administrative Tags
> ]            <draft-martin-neal-policy-isis-admin-tags-05.txt>
> ] 
> ] 
> ] 1. Status of this Memo
> ] 
> ]    This document is an Internet-Draft and is in full 
>conformance with
> ]    all provisions of Section 10 of RFC 2026.
> ] 
> ]    Internet-Drafts are working documents of the Internet Engineering
> ]    Task Force (IETF), its areas, and its working groups.  Note that
> ]    other groups may also distribute working documents as Internet-
> ]    Drafts.
> ] 
> ]    Internet-Drafts are draft documents valid for a maximum 
>of six months
> ]    and may be updated, replaced, or obsoleted by other 
>documents at any
> ]    time.  It is inappropriate to use Internet- Drafts as reference
> ]    material or to cite them other than as "work in progress."
> ] 
> ]    The list of current Internet-Drafts can be accessed at
> ]    http://www.ietf.org/ietf/1id-abstracts.txt
> ] 
> ]    The list of Internet-Draft Shadow Directories can be accessed at
> ]    http://www.ietf.org/shadow.html.
> ] 
> ] 
> ] 2. Abstract
> ] 
> ]    This document describes an extension to the IS-IS protocol to add
> ]    operational capabilities that allow for ease of management and
> ]    control over IP prefix distribution within an IS-IS 
>domain.  The IS-
> ]    IS protocol is specified in [1], with extensions for 
>supporting IPv4
> ]    specified in [2] and further enhancements for Traffic 
>Engineering [4]
> ]    in [3] and [6].
> ] 
> ]    This document enhances the IS-IS protocol by extending the
> ]    information that a Intermediate System (IS) [router] can place in
> ]    Link State Protocol Data Units (LSPs) as specified in [2].  This
> ] 
> ] 
> ] 
> ] Martin, Neal, Previdi                                   [Page 1]
> ] 
> ] 
> ] 
> ] 
> ] 
> ] 
> ] INTERNET DRAFT                                              
> April 2002
> ] 
> ] 
> ]    extension will provide operators with a mechanism to control IP
> ]    prefix distribution throughout multi-level IS-IS domains.
> ]    Additionally, the information can be placed in LSPs that 
>have TLVs as
> ]    yet undefined, if this information is used to convey the 
>same meaning
> ]    in these future TLVs as it is used in the currently defined TLVs.
> ] 
> ] 
> ] 
> ] 3. Specification of Requirements
> ] 
> ]    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 
>"SHALL NOT",
> ]    "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and 
>"OPTIONAL" in this
> ]    document are to be interpreted as described in [RFC 2119].
> ] 
> ] 
> ] 4. Introduction
> ] 
> ]    As defined in [2] and extended in [3], the IS-IS 
>protocol may be used
> ]    to distribute IP prefix reachibility information 
>throughout an IS-IS
> ]    domain.  The IP prefix information is encoded as TLV 
>type 128 and 130
> ]    in [2], with additional information carried in TLV 135 
>as specified
> ]    in [3] and TLV 235 as defined in [6].  In particular, 
>the extended IP
> ]    Reachabilty TLV (135) contains support for a larger 
>metric space, an
> ]    up/down bit to indicate redistribution between different 
>levels in
> ]    the hierarchy, an IP prefix, and one or more sub-TLVs that can be
> ]    used to carry specific information about the prefix.  
>TLV 235 is a
> ]    derivative of TLV 135, with the addition of 
>MultiTopology membership
> ]    information [6].
> ] 
> ]    As of this writing no sub-TLVs have been defined; 
>however, this draft
> ]    proposes 2 new sub-TLVs for both TLV 135 and TLV 235 
>that may be used
> ]    to carry administrative information about an IP prefix.
> ] 
> ] 
> ] 5. Sub-TLV Additions
> ] 
> ]    This draft proposes 2 new "Administrative Tag" sub-TLVs 
>to be added
> ]    to TLV 135 and 235.  These TLVs specify one or more 
>ordered, 32 or 64
> ]    bit unsigned integers that may be associated with an IP prefix.
> ]    Example uses of these tags include controlling 
>redistribution between
> ]    levels and areas, different routing protocols, or 
>multiple instances
> ]    of IS-IS running on the same router, or carrying BGP standard or
> ]    extended communites.
> ] 
> ]    The methods for which their use is employed is beyond 
>the scope of
> ]    this document and left to the implementer and/or operator.
> ] 
> ]    The encoding of the sub-TLV(s) is discussed in the following
> ] 
> ] 
> ] 
> ] Martin, Neal, Previdi                                   [Page 2]
> ] 
> ] 
> ] 
> ] 
> ] 
> ] 
> ] INTERNET DRAFT                                              
> April 2002
> ] 
> ] 
> ]    subsections.
> ] 
> ] 
> ] 5.1. 32-bit Administrative Tag Sub-TLV 1
> ] 
> ]    The Administrative Tag shall be encoded as one or more 4 octet
> ]    unsigned integers using Sub-TLV 1 in TLV-135 [3] and TLV 
>235 [6]. The
> ]    Administrative Tag Sub-TLV has following structure:
> ] 
> ]         1 octet of type (value: 1)
> ]         1 octet of length (value: multiple of 4)
> ]         one or more instances of 4 octets of administrative tag
> ] 
> ]    An implementation may consider only one of the encoded 
>tags, in which
> ]    case the first encoded tag must be considered.  A tag 
>value of zero
> ]    is reserved and should be treated as "no tag".
> ] 
> ] 
> ] 5.2. 64-bit Administrative Tag Sub-TLV 2
> ] 
> ]    The Administrative Tag shall be encoded as one or more 8 octet
> ]    unsigned integers using Sub-TLV 2 in TLV-135 [3] and TLV 
>235 [6]. The
> ]    64-bit Administrative Tag Sub-TLV has following structure:
> ] 
> ]         1 octet of type (value: 1)
> ]         1 octet of length (value: multiple of 8)
> ]         one or more instances of 8 octets of administrative tag
> ] 
> ]    An implementation may consider only one of the encoded 
>tags, in which
> ]    case the first encoded tag must be considered.  A tag 
>value of zero
> ]    is reserved and should be treated as "no tag".
> ] 
> ] 
> ] 6. Ordering of Tags
> ] 
> ]    The ordering of tags is implied.  That is, tags set by an LSP
> ]    originator should be flooded throughout the IS-IS domain 
>unchanged.
> ]    Each IS that receives an LSP with TLV 135 or TLV 235, that have
> ]    additional SubTLV 1 and/or 2 MAY operate on the tag values as
> ]    warranted by the implementation.  Tag values SHOULD NOT 
>be deleted or
> ]    changed within an area.  If an implementation needs to 
>change tag values,
> ] 
> ]    for example, at an area boundary, then the TLV(s) SHOULD 
>be copied to the
> ]    IS Level-2 LSP at which point, the contents of the SubTLV(s) MAY
> ]    change.
> ] 
> ] 
> ] 
> ] 
> ] 
> ] 
> ] 
> ] Martin, Neal, Previdi                                   [Page 3]
> ] 
> ] 
> ] 
> ] 
> ] 
> ] 
> ] INTERNET DRAFT                                              
> April 2002
> ] 
> ] 
> ] 7. A compliant IS-IS implementation:
> ] 
> ]    MUST be able to assign one tag to any IP prefix in 
>TLV(s) 135 and/or
> ]    235.
> ] 
> ]    MAY be able to assign more than one tag to any IP prefix 
>in TLV(s)
> ]    135 and/or 235.
> ] 
> ]    MAY be able to rewrite or remove one or more tags 
>associated with a
> ]    prefix in TLV 135.
> ] 
> ] 
> ] 8. Operation
> ] 
> ]    An administrator associates an Administrative Tag value with some
> ]    interesting property.  When IS-IS advertises 
>reachability for some IP
> ]    prefix that has that property, it adds the 
>Administrative Tag to the
> ]    IP reachability information TLV for that prefix, and the 
>tag "sticks"
> ]    to the prefix as it is flooded throughout the routing domian.
> ] 
> ]    Consider the network in figure 1. We wish to "leak" L1 
>prefixes [5]
> ]    with some property, A, from L2 to the L1 router R1.  
>Without policy-
> ]    groups, there is no way for R2 to know property A prefixes from
> ]    property B prefixes.
> ] 
> ] 
> ] 
> ]                     R2--------R3--------R4
> ]              L2     /                    \           
> ]              - - - /- - - - - - - - - - - - - -
> ]              L1   /                        \               
> ]                 R1                         R5----1.1.1.0/24 (A)
> ]                                             |
> ]                                             |
> ]                                       1.1.2.0/24 (B)
> ] 
> ] 
> ]                            Figure 1
> ] 
> ]    We associate Administrative Tag 100 with property A, and have R5
> ]    attach that value to the IP extended reachability 
>information TLV for
> ]    prefix 1.1.1.0/24. R2 has a policy in place to "match 
>prefixes with
> ]    Administrative Tag 100, and leak to L1."
> ] 
> ]    The previous example is rather simplistic; it seems that 
>it would be
> ]    just as easy for R2 simply to match the prefix 
>1.1.1.0/24. However,
> ]    if there are a large number of routers that need to 
>apply some policy
> ]    according to property A and large number of "A" prefixes, this
> ] 
> ] 
> ] 
> ] Martin, Neal, Previdi                                   [Page 4]
> ] 
> ] 
> ] 
> ] 
> ] 
> ] 
> ] INTERNET DRAFT                                              
> April 2002
> ] 
> ] 
> ]    mechanism can be quite helpful.
> ] 
> ] 
> ] 
> ] 9. Security Considerations
> ] 
> ]    This document raises no new security issues for IS-IS, as any
> ]    annotations to IP prefixes should not pass outside the 
>administrative
> ]    control of the network operator of the IS-IS domain.  Such an
> ]    allowance would violate the spirit of Interior Gateway 
>Protocols in
> ]    general and IS-IS in particular.
> ] 
> ] 
> ] 10. IANA Considerations
> ] 
> ]    The authors have chosen "1" as the typecode of the 32-bit
> ]    Administrative Tag sub-TLV and "2" as the typecode of the 64-bt
> ]    Administrative Tag SubTLV.  These must be allocated by IANA.
> ] 
> ] 
> ] 11. Acknowledgments
> ] 
> ]    The authors would like to thank Henk Smit for clarifying the best
> ]    place to describe this new information, Tony Li and Tony 
>Przygienda
> ]    for useful comments on this draft, Danny McPherson for some much
> ]    needed formatting assistance, and Mike Shand for useful 
>discussions
> ]    on encoding structure of the sub-TLV.
> ] 
> ] 
> ] 12. References
> ] 
> ]    [1] "Intermediate System to Intermediate System 
>Intra-Domain Routeing
> ]        Exchange Protocol for use in Conjunction with the 
>Protocol for
> ]        Providing the Connectionless-mode Network Service 
>(ISO 8473)",
> ]        ISO 10589.
> ] 
> ]    [2] Callon, R., RFC 1195, "Use of OSI IS-IS for routing 
>in TCP/IP and
> ]        dual environments", RFC 1195, December 1990.
> ] 
> ]    [3] Li, T., and Smit, H., "IS-IS extensions for Traffic 
>Engineering",
> ]        Internet Draft, "Work in Progress", September 2000.
> ] 
> ]    [4] Adwuche, D., Malcolm, J., Agogbua, M., O'Dell, M. 
>and McManus,
> ]        J., "Requirements for Traffic Engineering Over 
>MPLS," RFC 2702,
> ]        September 1999.
> ] 
> ]    [5] Li,T., Przygienda, T., Smit, H., "Domain-wide Prefix 
>Distribution
> ]        with Two-Level IS-IS" RFC 2966, October 2000
> ] 
> ] 
> ] 
> ] Martin, Neal, Previdi                                   [Page 5]
> ] 
> ] 
> ] 
> ] 
> ] 
> ] 
> ] INTERNET DRAFT                                              
> April 2002
> ] 
> ] 
> ]    [6] Przygienda, T., Shen, N., Sheth, N., "M-ISIS: Multi Topology
> ]        Routing in IS-IS", draft-ietf-isis-wg-multi-topology-03.txt, 
> ]        April 2002.
> ] 
> ] 
> ] 
> ] 13. Authors' Address
> ] 
> ]    Christian Martin
> ]    Verizon Global Networks, Inc.
> ]    1880 Campus Commons Dr
> ]    Reston, VA 20191
> ]    Email: [email-masked]
> ]    Voice: 1 (703) 2954394
> ]    Fax: 1 (703) 2954279
> ] 
> ]    Brad Neal
> ]    Broadwing Communications
> ]    1835 Kramer Lane - Suite 100
> ]    Austin, TX 78758
> ]    USA
> ]    Email: [email-masked]
> ]    Voice: 1 (512) 7421310
> ]    Fax: 1 (512) 7421333
> ] 
> ]    Stefano Previdi
> ]    Cisco Systems, Inc.
> ]    De Kleetlaan 6A
> ]    1831 Diegem - Belgium
> ]    email: [email-masked]
> ] 
> ] 
> ] 
> ] 
> ] 
> ] 
> ] 
> ] 
> ] 
> ] 
> ] 
> ] 
> ] 
> ] 
> ] 
> ] 
> ] 
> ] 
> ] 
> ] 
> ] 
> ] Martin, Neal, Previdi                                   [Page 6]
>
>- Naiming
>
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://spider.juniper.net/mailman/listinfo/isis-wg