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

From: "Martin, Christian" <[email-masked]>
Date: Tue, 16 Apr 2002 15:47:13 -0400

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]
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://spider.juniper.net/mailman/listinfo/isis-wg

---

From: Naiming Shen <[email-masked]>
Date: Tue, 16 Apr 2002 13:40:02 -0700

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

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 16 Apr 2002 21:54:50 -0700

>L2/L1 boundaries, where new LSPs are originated.  Thoughts?
yes, you _cannot_ change other people LSPs and if you change yours, you 
need new version number and
checksum anyway.

Comment for deletion and I'm getting picky here, you may not want to go 
into this matter. What you specified
is an ordered set or a chain but one could also think of an array, to 
give you an example, assume I send you
version 1 with 3 tags for a route {X,Y,Z}. The next version contains 
{X,Z}. The interpretation could be either

a) the route has a tag X that preceeds tag Z which could e.g. mean that 
tag X overrides certain properties
    of tag Z or any such thing.

or

b) the route had a first tag X, then a second tag Y, then a third tag Z 
and now it has a
    firs tag X and a _second_ tag Z.  First tag e.g. always encodes an 
extended community,
    second is a customer tag,
    third is tag indicating that route is a summary as example.

What does it mean? In a second interpretation, the semantics of {X,Z} 
and {X,NULL-TAG,Z} are different,
in the first interpreation both constructs mean the same.

IMO, think what you want to have or say that both are possible and 
interpretation depends on application.

And oh, you misspelled Verizon in the header unless it's a different 
company ;-)

    thanks

    -- tony