Re: [Isis-wg] draft-hegde-isis-advertising-te-protocols-02 and draft-ginsberg-isis-te-app-00

Greg Mirsky <gregimirsky@gmail.com> Fri, 02 June 2017 00:39 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B5F129B7A for <isis-wg@ietfa.amsl.com>; Thu, 1 Jun 2017 17:39:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Level:
X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rdsuGiqF_EGq for <isis-wg@ietfa.amsl.com>; Thu, 1 Jun 2017 17:39:11 -0700 (PDT)
Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7496E129B7E for <isis-wg@ietf.org>; Thu, 1 Jun 2017 17:39:01 -0700 (PDT)
Received: by mail-oi0-x22f.google.com with SMTP id l18so74225038oig.2 for <isis-wg@ietf.org>; Thu, 01 Jun 2017 17:39:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=84fs/8qCGJFMMQrbdLQNAxR8ck9QyuYyqpNzM+sDkHE=; b=E+pbFLHbsgJI4V0BzKwCvwIqYu6qMRl7JF85dWQDV/is6HaIQXbPp+VDEx7rx9XuNN z4fYf26zxOg8BCTN3DdTEdg8rBl7W4q5LUlP4tozNks7/4qyHjABu6hKEuXSemCIxAC8 i9IQvTGWQmaj7o2RJdyEHFqwHH3qvtDZNmahkAwbe9lM57VlQfC9NV7pPUWsuLYkBeOF x0lt1JrtXjU4mOr4JkJFCyaXJWMQhjXgBcGfV3DXGyHT6tmGhv16jFs1Rs0P2WCGMJ+v iXHB983TLAf1jmRhyDF3Q5+sUdtyGxQie3itbbk+4O13sVHyu+cJSYYJmUU0qPokICjs cFiQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=84fs/8qCGJFMMQrbdLQNAxR8ck9QyuYyqpNzM+sDkHE=; b=KD5JRgD2jpw5g4/tOTA8824tYWZ8SIa5Ae2xtVR5GUNKUTRIzje5cJbRjHGDFqDGsv xOkvjJTeko+rHwBB6kpUb+8NIog8tfsb0FeMJW0PkHpJUEawYGX7dAN3wyNvEuN/Z7b8 kHIwoTc02HeGc8PCyGlxKOHarsld2loae6o1JMVE/FFx+q7JBW6wBsR78VRpABZ1QrPl CKnCnYwYleW5nN3yFZt0sktH/uFYK4ccIxMbntVrd6FX/JdW85FeRTAUBkJRYuXTHXtt lm7zU0StsZaQC5zPciJ8d1b5BpVDkFurwkW7MPN1h6QHUWjMXQUnQjCMUPknGxtGVs/z E+qA==
X-Gm-Message-State: AODbwcCvw7XrfBbNIqnzE+QtV9WXqoXKEoFSinzsPaBgsnr1uHBA9Gwc 88eNtb1mKuvAc7RtUiZeNYYBbeth9qbA
X-Received: by 10.157.3.195 with SMTP id f61mr3218608otf.197.1496363940449; Thu, 01 Jun 2017 17:39:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.52.225 with HTTP; Thu, 1 Jun 2017 17:38:59 -0700 (PDT)
In-Reply-To: <10115_1496363792_5930B310_10115_7873_1_9E32478DFA9976438E7A22F69B08FF921DDBF94D@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
References: <MWHPR05MB28293E73A559496455BA7BBAA9E20@MWHPR05MB2829.namprd05.prod.outlook.com> <3547a236e630428291fccc45a0add058@XCH-ALN-001.cisco.com> <20069_1496043951_592BD1AF_20069_6728_1_9E32478DFA9976438E7A22F69B08FF921DDBDFE5@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <741b079c91ba4a5e802827793ab0a817@XCH-ALN-001.cisco.com> <1624_1496305881_592FD0D9_1624_5291_1_9E32478DFA9976438E7A22F69B08FF921DDBF2C0@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <f03a37925cda44848768880248a43674@XCH-ALN-001.cisco.com> <10115_1496363792_5930B310_10115_7873_1_9E32478DFA9976438E7A22F69B08FF921DDBF94D@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Thu, 01 Jun 2017 17:38:59 -0700
Message-ID: <CA+RyBmWkZX73WVrj2k55LOf_pY34C+JYyYQofhE3SLaUXJsm=A@mail.gmail.com>
To: isis-wg@ietf.org
Cc: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, Stephane Litkowski <stephane.litkowski@orange.com>, Chris Bowers <cbowers@juniper.net>
Content-Type: multipart/alternative; boundary="94eb2c03b4482012c90550ef6123"
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/9_BFebloxIIHZqisgrau60_RdPg>
Subject: Re: [Isis-wg] draft-hegde-isis-advertising-te-protocols-02 and draft-ginsberg-isis-te-app-00
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Jun 2017 00:39:17 -0000

Dear All,
though no formal poll has been called regarding which of proposed,
discussed in this thread methods of associating TE applications with link
attribute information I'd offer my view.
In short, I agree with arguments by Les and his proposal. I think that
using well-known bit-mapped values is robust and flexible at the same time.
I just have minor proposal about allocating bits for proprietary (P) and
experimental (X) applications. Perhaps using bits 6 and 7 may not be the
most future-proof as we may find the application bit mask of two octets
length. If WG believes that two bits are sufficient, using bit positions 0
and 1 may be an option to consider.

Regards,
Greg

>
>
> *From:* Isis-wg [mailto:isis-wg-bounces@ietf.org] *On Behalf Of *Les
> Ginsberg (ginsberg)
> *Sent:* Thursday, June 1, 2017 10:45 AM
> *To:* stephane.litkowski@orange.com; Chris Bowers <cbowers@juniper.net>;
> isis-wg@ietf.org
> *Subject:* Re: [Isis-wg] draft-hegde-isis-advertising-te-protocols-02 and
> draft-ginsberg-isis-te-app-00
>
>
>
> Stephane –
>
>
>
> Inline.
>
>
>
> *From:* stephane.litkowski@orange.com [mailto:stephane.litkowski@ora
> nge.com <stephane.litkowski@orange.com>]
> *Sent:* Thursday, June 01, 2017 1:31 AM
> *To:* Les Ginsberg (ginsberg); Chris Bowers; isis-wg@ietf.org
> *Subject:* RE: draft-hegde-isis-advertising-te-protocols-02 and
> draft-ginsberg-isis-te-app-00
>
>
>
> Pls find inline comments.
>
>
>
> Brgds,
>
>
>
>
>
> *From:* Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com
> <ginsberg@cisco.com>]
> *Sent:* Wednesday, May 31, 2017 23:48
> *To:* LITKOWSKI Stephane OBS/OINIS; Chris Bowers; isis-wg@ietf.org
> *Subject:* RE: draft-hegde-isis-advertising-te-protocols-02 and
> draft-ginsberg-isis-te-app-00
>
>
>
> Stephane –
>
>
>
> There are a number of things we agree on:
>
>
>
> o Attribute values need to be configured per application per link
>
> o IGPs do not need to understand the content of what they are
> advertising/receiving - other than to understand how to build and parse the
> necessary TLVs
>
>
>
> But here are some things I simply don't understand.
>
>
>
> 1)You say  "an opaque identifier is definitely aligned with my view of not
> having the IGP to deal with applications"
>
>
>
> Without actually proscribing an implementation I think we can agree on the
> following:
>
>
>
> For each application there is a module whose function is to determine what
> application specific attributes are to be advertised for each local link,
>
> to receive application specific link attribute values advertised by other
> nodes in the network (transported by the IGPs),
>
> and to use the set of application specific advertisements in ways specific
> to that application.
>
>
>
> In addition, given we want to be able to minimize duplicate advertisements
> when they can be shared by multiple applications,
>
> there is also logic which looks at the set of link attributes to be
> advertised by this node for a given link for all applications  and
> determines which
>
> attributes can be shared. This logic then determines what "identifier" the
> IGP can use when advertising a (set of) link attributes.
>
> This identifier could be a bit mask or it could be a scalar.
>
>
>
> IGPs then are told what link attributes to advertise for a given link and
> what identifier to use when advertising each attribute.
>
> Unless the application is inherently part of the IGP itself (e.g., LFA)
> the IGP has no need to understand the content or the use of the information
>
> being advertised beyond what is necessary for proper encoding/decoding of
> the advertisements.
>
>
>
> Whether the identifier is a scalar like "400" or a bit mask like "0x102"
> does not change in any way the awareness that the IGP has regarding
>
> the advertisements. So I fail to see how the use of a scalar identifier
> rather than a bit mask makes application data any more or less opaque to
> the IGP
>
>
>
> [SLI] Basically, scalar vs bits can both be opaque. But your bit mask is
> not opaque as you are encoding applications in it. Moreover a scalar is
> more readable for humans rather than a bit mask expressed in hex value.
>
>
>
> *[Les:] You seem to be  agreeing that the form does not matter to the
> IGPs.*
>
> *As regards “human readable”, any numerical value is likely to be
> undecipherable to a human – I would expect user friendly implementations
> would translate the numbers into application names for display purposes.*
>
>
>
> 2)You also say: "...misconfiguration, but this will only affect the local
> node, not the entire network".
>
>
>
> Even for an application like RSVP-TE where tunnel creation may only occur
> at ingress points, the tunnel headend makes use of link attribute
> advertisements
>
> from every node in the network. And to do so correctly there MUST be
> consistent use of the identifier in link attribute advertisements
> originated by all nodes
>
> in the network.
>
>
>
> [SLI] I agree, but this can happen in both solutions. The configuration of
> node attributes is done in the same way in both solutions. So both solution
> can experience misconfiguration in this area.
>
>
>
> *[Les:] For standards based applications, there is no config required when
> using a bit mask because the bit is defined in an IANA registry. It is only
> for a user defined application that any config would be required.*
>
> *When using scalars however, config is always required – so the scalar
> proposal is more vulnerable to misconfigs.*
>
>
>
> So the only difference I see between using assigned bits vs using scalar
> identifiers lies in the number of identifiers which need to be consistently
> configured on every node in the network.
>
> [SLI] Let’s say that you need to attribute sets for two applications, you
> just need two scalars.
>
> If you have 4 applications, but you need only two attribute-sets (because
> some applications share the same attributes), you need only two scalars
> again.
>
> I think it’s not a question of the number of identifiers, but more a
> question of numbers of attribute-sets (or attribute values). Using a
> scalar, you may need more attribute-sets if you try to mix sharing values
> and having differents values.
>
> Let’s say that you have two applications A1 & A2:
>
> -        A1 uses attribute 1 value 1 on node 1, attribute 1 value 2 on
> node 2, attribute 1 value 3 on node 3.
>
> -        A2 needs the same attribute combination, expect on node 3, which
> requires a value of 4  for attribute 1.
>
> In that case, if a single scalar is allowed per attribute-set, we will
> need to duplicated the attributes on node 1 and node 2 to associate them
> with a new scalar value that would be used by A2.
>
>
>
> *[Les:] I agree – but – as I stated in an earlier response to Uma – we are
> writing a specification which supports all possible deployments. Doing so
> in a way which becomes awkward to use if applications do not use identical
> attributes isn’t a good design. This is why I have made the point that with
> scalars you may have to configure “up to” ((2**N)-1) scalars. Do you really
> want to design a solution that becomes increasingly awkward as more
> applications are supported and more divergence between application
> attributes is required?*
>
>
>
> In the case of assigned bits, we only have to configure one
> bit/application - and for the standardized applications even this does not
> have to be configured since the bits are "well known".
>
>
>
> In the case of scalar identifiers, up to ((2**N) - 1) scalars have to be
> configured (where N is the number of supported applications).
>
>
>
> What then is the value add of using scalars?
>
>
>
> *[Les:] I still do not see any value add for scalars mentioned in any of
> the responses from you.*
>
>
>
> *   Les*
>
>
>
>    Les
>
>
>
>
>
> *From:* stephane.litkowski@orange.com [mailto:stephane.litkowski@ora
> nge.com <stephane.litkowski@orange.com>]
> *Sent:* Monday, May 29, 2017 12:46 AM
> *To:* Les Ginsberg (ginsberg); Chris Bowers; isis-wg@ietf.org
> *Subject:* RE: draft-hegde-isis-advertising-te-protocols-02 and
> draft-ginsberg-isis-te-app-00
>
>
>
> Hi Les,
>
>
>
> I think the best approach is to have a “merged” draft rather than
> progressing your proposals as they are today.
>
> Chris’ proposal of having an opaque identifier is definitely aligned with
> my view of not having the IGP to deal with applications, it just carries
> attributes but does not need to take care on how they must be used.
>
> Even in your proposal, if you have different attributes per application,
> you will have to configure the attribute values for each application (case
> of no value sharing) on each required router or link.
>
> The only difference is the additional configuration of the mapping between
> the app and the attributes. But it’s not really a big deal, for TE apps,
> only the head end needs the mapping conf. For LFA/rLFA, it’s more a global
> config, that could be easily automated as part of router configuration
> templates (this config is not expected to move over time). Yes, as usual
> there could be some misconfiguration, but this will only affect the local
> node, not the entire network (based on the existing applications).
>
>
>
> I think also that the TE protocol subTLV is useful to ensure that we will
> not compute a path that uses a link that does not enable the right
> signaling protocol (similar goal as IGP/LDP sync). So the semantic is
> different as the one you proposed. Your semantic is a mapping of an
> application to a set of attributes while the TE protocol subTLV describes
> which application currently runs on a particular link (this is a
> descriptive attribute).
>
>
>
>
>
> Brgds,
>
>
>
> Stephane
>
>
>
>
>
> *From:* Isis-wg [mailto:isis-wg-bounces@ietf.org
> <isis-wg-bounces@ietf.org>] *On Behalf Of *Les Ginsberg (ginsberg)
> *Sent:* Tuesday, May 16, 2017 01:52
> *To:* Chris Bowers; isis-wg@ietf.org
> *Subject:* Re: [Isis-wg] draft-hegde-isis-advertising-te-protocols-02 and
> draft-ginsberg-isis-te-app-00
>
>
>
> Chris -
>
>
>
> Thanx for the detailed write up regarding your proposed encoding for
>
> advertising link attribute information for multiple applications.
>
>
>
> My primary takeaway is that we are now in agreement regarding the need
>
> to support application specific advertisement of link attribute
> information.
>
> This is the major difference between the proposals in
>
>
>
> draft-ginsberg-isis-te-app/ppsenak-ospf-te-link-attr-reuse
>
>
>
> vs
>
>
>
> hegde-isis-advertising-te-protocols/hegde-ospf-advertising-te-protocols
>
>
>
> This means we have resolved the stalemate and that the respective WGs
> should
>
> now be able to begin work on the proposals based on the ginsberg/ppsenak
> drafts.
>
>
>
> This is a major step forward and I think achieves the task you and I were
>
> assigned in Chicago WG meetings.
>
>
>
> The remainder of my comments are specific to your encoding proposals -
>
> but it is worth emphasizing that we are no longer debating the
> requirements -
>
> we are simply discussing alternative encodings.
>
>
>
> Regarding Attribute Set Identifier
>
> ----------------------------------
>
>
>
> Your proposal is to define dynamically - via configuration on every router
> - a numeric
>
> identifier which represents a set of applications. Each identifier is
>
> associated with one or more applications - and that identifier is then
>
> advertised with a set of link specific attribute sub-sub-TLVs.
>
>
>
> As this is based on configuration, for correct operation the operator MUST
>
> configure consistent numeric value/application set mappings on EVERY
> router.
>
> To cover all possible combinations the operator would have to configure
>
> up to (2**N)-1 identifiers where N is the number of applications supported.
>
>
>
> 3 applications: up to 7 identifiers
>
> 4 applications: up to 15 identifiers
>
> 5 applications: up to 31 identifiers
>
>
>
> And the correct identifier(s) have to be associated with the appropriate
> sets of attributes
>
> on every link on each router.
>
>
>
> This seems both onerous and error prone.
>
>
>
> The stated benefit of this vs the IANA assigned bit mappings proposed
>
> by the ginsberg/ppsenak drafts is that a new application could be
> introduced
>
> without requiring a bit assignment by IANA. If we look at the existing
>
> applications (RSVP-TE, SR-TE, LFA) we note that all of these applications
>
> required IETF drafts be written to define interoperable behavior. I would
>
> expect the same would be required of any new application. Given that a
>
> draft is required, the inclusion of an IANA request for an application bit
>
> identifier in such a draft is trivial. By doing so we avoid the additional
> configuration
>
> and its risks of inconsistency.
>
>
>
> If the intent is to allow introduction of a proprietary or experimental
>
> application in a network prior to developing any standards I think there
>
> is a much easier way to support that. draft-ginsberg-isis-te-app currently
>
> defines:
>
>
>
>         Bit Mask Length: Non-zero (1 octet)
>
>         Application Bit Mask: Size is (Bit Mask Length+7)/8
>
>         The following bits are assigned:
>
>
>
>              0 1 2 3 4 5 6 7
>
>             +-+-+-+-+-+-+-+-+
>
>             |L|R|S|F|       |
>
>             +-+-+-+-+-+-+-+-+
>
>
>
>        L-bit: Applications listed MUST use the legacy
>
>           advertisements for the corresponding link
>
>           found in TLVs 22, 23, 141, 222, and 223 or
>
>           TLV 138 or TLV 139 as appropriate.
>
>
>
>        R-bit: RSVP-TE
>
>
>
>        S-bit: Segment Routing Traffic Engineering
>
>
>
>        F-bit: Loop Free Alternate
>
>
>
>
>
> We could reserve some bits (I think two would be enough) for non-standards
>
> use. For example
>
>
>
>              0 1 2 3 4 5 6 7
>
>             +-+-+-+-+-+-+-+-+
>
>             |L|R|S|F|   |P|X|
>
>             +-+-+-+-+-+-+-+-+
>
>
>
>        P-Bit: Reserved for proprietary application
>
>
>
>        X-bit: Reserved for experimental (pre-standard)
>
>                application
>
>
>
> Regarding your proposal for: Traffic-engineering Protocol sub-TLV
>
> -------------------------------------------------------------------
>
>
>
> I think what you are trying to address here are the backwards
> compatibility
>
> concerns. Today, because we lack the ability to advertise application
> specific
>
> attributes, implementations have been forced to overload the use of the
> legacy
>
> advertisements even though such advertisements were never intended to be
> used in this way.
>
> One of the issues which the ginsberg/ppsenak drafts are addressing is the
> inappropriate use
>
> of legacy advertisements. While we do recognize that until we have full
> deployment of the
>
> extensions we need to support backwards compatibility with the existing
> overloaded use
>
> of legacy advertisements, we do NOT want to standardize this behavior.
>
>
>
> draft-ginsberg-isis-te-app provides backwards compatibility by using the
> L-bit
>
> as described above. With partial deployment we then (using the example of
> SR-TE)
>
> advertise an application bit mask with L and S bits set. This indicates
> that
>
> SR-TE application is using the legacy advertisements. Even after full
> deployment
>
> of the extensions this can be used to avoid unnecessary duplication when
> SR-TE
>
> and RSVP-TE share the same attributes on a given link.
>
>
>
> However, because you are proposing to use a numeric identifier, you have
> no way to
>
> indicate when SR-TE (for example) should use legacy advertisements. In
> order to do so you have
>
> to introduce another sub-TLV which uses the equivalent of the bit mask
> which the
>
> ginsberg/ppsenak drafts already utilize. And, since IANA allocations for
> the bits in this
>
> sub-TLV are still required, you have not actually eliminated the need for
> IANA bit allocations –
>
> which is one of the goals of your proposed dynamically assigned
> identifiers.
>
>
>
> For the proposals defined in the ginsberg/ppsenak drafts this information
> has already
>
> been conveyed via the bit mask advertised as part of the link attribute
> advertisements –
>
> so there is no need for this additional advertisement.
>
>
>
> Also note that the concept of “application enabled on a link” is not what
> is required.
>
> What is required is to identify what sets of applications can use a set of
> link attribute
>
> advertisements - which is completely captured by the new application
> specific link
>
> attribute advertisements defined in the ginsberg/ppsenak drafts.
>
>
>
> There is no need for this additional sub-TLV.
>
>
>
>    Les
>
>
>
>
>
>
>
>
>
> *From:* Isis-wg [mailto:isis-wg-bounces@ietf.org
> <isis-wg-bounces@ietf.org>] *On Behalf Of *Chris Bowers
> *Sent:* Friday, May 12, 2017 10:47 AM
> *To:* isis-wg@ietf.org
> *Subject:* [Isis-wg] draft-hegde-isis-advertising-te-protocols-02 and
> draft-ginsberg-isis-te-app-00
>
>
>
> ISIS-WG,
>
>
>
> As I said at the microphone at the WG meeting in Chicago, I think there
>
> may be some common ground that can address the general goals of both
>
> draft-hegde-isis-advertising-te-protocols-02 and
>
> draft-ginsberg-isis-te-app-00.
>
>
>
> The text below describes proposed encodings that I think reflect
>
> potential common ground. The main idea is to decouple the advertisement
>
> of what protocols are enabled on a link and the advertisement of
>
> different sets of attributes on a link, and then allow applications to
>
> choose how to use that information as they see fit. This takes into
>
> account input from networks operators regarding the desire for a
>
> flexible mapping between attribute sets and the applications that use
>
> them.
>
>
>
> I look forward to feedback from the WG on these proposed encodings.
>
>
>
> The text below borrows liberally from the existing text in
>
> draft-hegde-isis-advertising-te-protocols-02 and
>
> draft-ginsberg-isis-te-app-00 with some important differences.
>
>
>
> Chris
>
>
>
> ======
>
> Attribute Set Identifier
>
>
>
> The new Attribute Set Identifier is a 32-bit value that identifies a set
>
> of attributes.  All of the attributes advertised with a given value of
>
> the Attribute Set Identifier are considered to be part of the attribute
>
> set.  This allows different applications to use different attribute sets,
>
> if desired.
>
>
>
> The Attribute Set Identifier with a value of zero is special.  Existing
>
> encodings for advertising attributes that do not explicitly support the
>
> inclusion of the Attribute Set Identifier are now understood to implicitly
>
> advertise attributes with the Attribute Set Identifier set to zero.
>
> In this framework, existing implementations using the existing encodings
>
> already support the advertisement of attributes with the Attribute Set
>
> Identifier = 0.
>
>
>
> In order to ensure a consistent view of the attribute set scoped
> attributes,
>
> for encodings that explicitly support the Attribute Set Identifier,
>
> advertising an attribute with Attribute Set Identifier set to
>
> zero is not allowed.
>
>
>
> From a standardization perspective, there is not intended to be any
>
> fixed mapping between a given Attribute Set Identifier and a given
>
> application. A network operator wishing to advertise different attribute
>
> sets could configure the network equipment to advertise attributes with
>
> different values of the Attribute Set Identifier based on their
>
> objectives. The different applications (be they controller-based
>
> applications or distributed applications) would make use of the
>
> different attribute sets based on convention within that network.
>
>
>
> As an example, a network operator might choose to advertise
>
> four different attribute sets, in support of five different applications
>
> with the following mapping.
>
>
>
> Application                                           Attribute Set
> Identifier
>
> ===========================              ========================
>
> Distributed RSVP-based                           0 (implicit)
>
> auto-bandwidth
>
>
>
> Centralized SR-based TE                          0 (implicit)
>
>
>
> Distributed SR-based FRR                         100
>
>
>
> Centralized RSVP-based                           200
>
> diverse low-latency paths
>
>
>
> Potential new application                        300
>
> that uses both SR and RSVP
>
> to build LSPs
>
>
>
> Below are descriptions of proposed encodings that allow attributes to
>
> be advertised with non-zero values of the Attribute Set Identifier.
>
> The Traffic-engineering Protocol sub-TLV is described as well, since it is
>
> needed to indicate what protocols are enabled on a link.
>
>
>
> ======
>
> Link Attribute Set sub-TLV
>
>
>
> The Link Attribute Set sub-TLV is a new sub-TLV for TLVs 22, 23, 141,
>
> 222, and 223. It allows different sets of link attributes to be
>
> advertised for the same link. This allows different applications to use
>
> different sets of attributes.
>
>
>
>         Type: to be assigned by IANA (suggested value 101 )
>
>         Length: Variable (1 octet)
>
>         Value:
>
>
>
>                 Attribute Set Identifier - a 32-bit value containing the
> non-zero
>
>                 Attribute Set Identifier that identifies a set of
> attributes. The Link
>
>                 Attribute Set sub-TLV MUST be ignored if the Attribute Set
> Identifier is
>
>                 zero. This ensures a consistent view of the attribute set
> scoped link
>
>                 attributes, where the Link Attribute sub-TLVs advertised
> directly
>
>                 in TLV#22 are now understood to be implicitly advertised
> with the
>
>                 Attribute Set Identifier equal to zero.
>
>
>
>                 Link Attribute sub-sub-TLVs - the format of these Link
> Attribute
>
>                 sub-sub-TLVs matches the existing formats for the Link
> Attribute
>
>                 sub-TLVs defined in [RFC5305] and [RFC7810]. Each Link
> Attribute
>
>                 sub-sub-TLV advertised in a given Link Attribute Set
> sub-TLV is
>
>                 associated with the Attribute Set Identifier in the Link
> Attribute Set
>
>                 sub-TLV.
>
>
>
> =======
>
> Attribute Set Scoped SRLG TLV
>
>
>
> A new TLV is defined to allow SRLGs to be advertised for a
>
> given link and associated with a specific attribute set identifier.
>
> Although similar in functionality to TLV 138 (defined by
>
> [RFC5307]) and TLV 139 (defined by [RFC6119] a single TLV provides
>
> support for IPv4, IPv6, and unnumbered identifiers for a link.
>
> Unlike TLVs 138/139 it utilizes sub-TLVs to encode the link
>
> identifiers in order to provide the flexible formatting required to
>
> support multiple link identifier types.
>
>
>
>         Type: to be assigned by IANA (suggested value 238)
>
>         Length: Number of octets in the value field (1 octet)
>
>         Value:
>
>                 Neighbor System-ID + pseudo-node ID (7 octets)
>
>
>
>                 Attribute Set Identifier - a 32-bit value containing the
> non-zero
>
>                 Attribute Set Identifier that identifies a set of
> attributes. The
>
>                 Attribute Set Scoped SRLG TLV MUST be ignored if the
> Attribute Set Identifier is
>
>                 zero. This ensures a consistent view of the attribute set
> scoped link
>
>                 attributes, where the SRLGs advertised directly in TLV#138
> and TLV#139
>
>                 are now understood to be implicitly advertised with the
>
>                 Attribute Set Identifier equal to zero.
>
>
>
>                 Length of sub-TLVs (1 octet)
>
>                 Link Identifier sub-TLVs (variable)
>
>                 0 or more SRLG Values (Each value is 4 octets)
>
>
>
>         The following Link Identifier sub-TLVs are defined. The type
>
>         values are suggested and will be assigned by IANA - but as
>
>         the formats are identical to existing sub-TLVs defined for
>
>         TLVs 22, 23, 141, 222, and 223 the use of the suggested sub-TLV
>
>         types is strongly encouraged.
>
>
>
>                    Type    Description
>
>                         4      Link Local/Remote Identifiers (see
> [RFC5307])
>
>                         6      IPv4 interface address (see [RFC5305])
>
>                         8      IPv4 neighbor address (see [RFC5305])
>
>                    12      IPv6 Interface Address (see [RFC6119])
>
>                    13      IPv6 Neighbor Address (see [RFC6119])
>
>
>
>    At least one set of link identifiers (IPv4, IPv6, or unnumbered) MUST
>
>    be present.  TLVs which do not meet this requirement MUST be ignored.
>
>
>
>    Multiple TLVs for the same link MAY be advertised.
>
>
>
>
>
> =======
>
> Traffic-engineering Protocol sub-TLV
>
>
>
> A new Traffic-engineering protocol sub-TLV is a new sub-TLV for TLVs 22,
>
> 23, 141, 222, and 223. The sub-TLV indicates the protocols enabled on
>
> the link. The sub-TLV has flags in the value field to indicate the
>
> protocol enabled on the link. The length field is variable to allow the
>
> flags field to grow for future requirements.
>
>
>
>     Type  : to be assigned by IANA (suggested value 102)
>
>     Length: Variable (1 octet)
>
>     Value:
>
>
>
>            The value field consists of bits indicating the protocols
>
>            enabled on the link.  This document defines the two protocol
> values
>
>            below.
>
>
>
>       0                   1                   2                   3
>
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>      |                         Flags                                 |
>
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
>                +----------+-------------------------------+
>
>                | Value    | Protocol Name                 |
>
>                +----------+-------------------------------+
>
>                |0x01      | RSVP                          |
>
>                +----------+-------------------------------+
>
>                |0x02      | Segment Routing               |
>
>                +----------+-------------------------------+
>
>
>
>         The RSVP flag is set to one to indicate that RSVP-TE is enabled on
> a
>
>         link.  The RSVP flag is set to zero to indicate that RSVP-TE is not
>
>         enabled on a link.
>
>
>
>         The Segment Routing flag is set to one to indicate that Segment
>
>         Routing is enabled on a link.  The Segment Routing flag is set to
>
>         zero to indicate that Segment Routing is not enabled on a link
>
>
>
> ========
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _________________________________________________________________________________________________________________________
>
>
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
>
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
>
> they should not be distributed, used or copied without authorisation.
>
> If you have received this email in error, please notify the sender and delete this message and its attachments.
>
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>
> Thank you.
>
> _________________________________________________________________________________________________________________________
>
>
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
>
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
>
> they should not be distributed, used or copied without authorisation.
>
> If you have received this email in error, please notify the sender and delete this message and its attachments.
>
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>
> Thank you.
>
>