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

From: Chris Bowers <[email-masked]>
Date: Fri, 12 May 2017 17:47:17 +0000

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

========

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 15 May 2017 23:52:11 +0000

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:[email-masked]] On Behalf Of Chris Bowers
Sent: Friday, May 12, 2017 10:47 AM
To: [email-masked]
Subject: [Isis-wg] draft-hegde-isis-advertising-te-protocols-02 and draft-ginsberg-isis-te-app-00

ISIS-WG,

Chris

======
Attribute Set Identifier

======

=======

                   Type    Description

=======

      0                   1                   2                   3

========

---

From: <[email-masked]>
Date: Mon, 29 May 2017 07:45:50 +0000

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:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Tuesday, May 16, 2017 01:52
To: Chris Bowers; [email-masked]
Subject: Re: [Isis-wg] draft-hegde-isis-advertising-te-protocols-02 and draft-ginsberg-isis-te-app-00

Chris -

vs

             0 1 2 3 4 5 6 7
            +-+-+-+-+-+-+-+-+
            |L|R|S|F|       |
            +-+-+-+-+-+-+-+-+

       R-bit: RSVP-TE

             0 1 2 3 4 5 6 7
            +-+-+-+-+-+-+-+-+
            |L|R|S|F|   |P|X|
            +-+-+-+-+-+-+-+-+

   Les

From: Isis-wg [mailto:[email-masked]] On Behalf Of Chris Bowers
Sent: Friday, May 12, 2017 10:47 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Isis-wg] draft-hegde-isis-advertising-te-protocols-02 and draft-ginsberg-isis-te-app-00

ISIS-WG,

Chris

======
Attribute Set Identifier

======

=======

                   Type    Description

=======

      0                   1                   2                   3

========

_________________________________________________________________________________________________________________________

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.

---

From: Peter Psenak <[email-masked]>
Date: Mon, 29 May 2017 10:15:04 +0200

Hi Stephane,

On 29/05/17 09:45 , [email-masked] wrote:
> 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).

can you please describe me how would you use the information about an 
application running on the remote link. For example, what will you do 
with the information that LFA or SR is enabled on some remote link? What 
is the exact use case?

thanks,
Peter

>
> Brgds,
>
> Stephane
>
> *From:*Isis-wg [mailto:[email-masked]] *On Behalf Of *Les
> Ginsberg (ginsberg)
> *Sent:* Tuesday, May 16, 2017 01:52
> *To:* Chris Bowers; [email-masked]
> *Subject:* Re: [Isis-wg] draft-hegde-isis-advertising-te-protocols-02
> and draft-ginsberg-isis-te-app-00
>
> Chris -
>
> sub-TLV are still required, you have not actually eliminated the need
> for IANA bit allocations –
>
> been conveyed via the bit mask advertised as part of the link attribute
> advertisements –
>
> Also note that the concept of “application enabled on a link” is not
> what is required.
>
> *From:*Isis-wg [mailto:[email-masked]] *On Behalf Of *Chris Bowers
> *Sent:* Friday, May 12, 2017 10:47 AM
> *To:* [email-masked] <mailto:[email-masked]>
> *Subject:* [Isis-wg] draft-hegde-isis-advertising-te-protocols-02 and
> draft-ginsberg-isis-te-app-00
>
> ISIS-WG,
>
> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg
>

---

From: <[email-masked]>
Date: Mon, 29 May 2017 14:06:43 +0000

The use case is more for SR and RSVP.
You need to ensure that when a head end computes an RSVP-TE path it uses links where RSVP is currently running. This prevents signaling failures.

-----Original Message-----
From: Peter Psenak [mailto:[email-masked]] 
Sent: Monday, May 29, 2017 10:15
To: LITKOWSKI Stephane OBS/OINIS; Les Ginsberg (ginsberg); Chris Bowers; [email-masked]
Subject: Re: [Isis-wg] draft-hegde-isis-advertising-te-protocols-02 and draft-ginsberg-isis-te-app-00

Hi Stephane,

On 29/05/17 09:45 , [email-masked] wrote:
> Hi Les,
>
> I think the best approach is to have a "merged" draft rather than 
> Chris' proposal of having an opaque identifier is definitely aligned 
> 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.
>
> 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).
> 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).

can you please describe me how would you use the information about an application running on the remote link. For example, what will you do with the information that LFA or SR is enabled on some remote link? What is the exact use case?

thanks,
Peter

> for IANA bit allocations -
>
> ______________________________________________________________________
> ___________________________________________________
>
> 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.

---

From: Peter Psenak <[email-masked]>
Date: Mon, 29 May 2017 16:22:29 +0200

Stephane,

> The use case is more for SR and RSVP.

can you please clarify the SR use case? There is no signaling there.

thanks,
Peter

> .

---

From: Shraddha Hegde <[email-masked]>
Date: Mon, 29 May 2017 17:52:00 +0000

Hi Peter,

There could be deployments that allocate Adj-SIDs for links for OAM purposes but do not want to include the link for SR-TE topology
And do not want to run SR traffic on those links. 

Leaving out the TE attribute advertisement for such links does not really indicate anything.
An explicit indication that RSVP/SR enabled on the link is necessary.

Rgds
Shraddha
-----Original Message-----
From: Isis-wg [mailto:[email-masked]] On Behalf Of Peter Psenak
Sent: Monday, May 29, 2017 7:52 PM
To: [email-masked]; Les Ginsberg (ginsberg) <[email-masked]>; Chris Bowers <[email-masked]>; [email-masked]
Subject: Re: [Isis-wg] draft-hegde-isis-advertising-te-protocols-02 and draft-ginsberg-isis-te-app-00

Stephane,

thanks,
Peter

>> 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).
>>
>> 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).
>
>> hegde-isis-advertising-te-protocols/hegde-ospf-advertising-te-protoco
>> l
>> s
>>
>> _____________________________________________________________________
>> _ ___________________________________________________
>>

---

From: Peter Psenak <[email-masked]>
Date: Tue, 30 May 2017 10:18:33 +0200

Hi Shraddha,

> And do not want to run SR traffic on those links.

there is no such thing as SR-TE topology. SR-TE is done based on the 
regular IGP topology (unlike RSVP TE, where the two can be 
in-congruent). If you wan to avoid a link to be used for SR-TE you can 
do that by using affinity and use these during cSPF on the head-end or 
controller. And you can still install Adj-SID for such link.

thanks,
Peter

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 30 May 2017 18:39:29 +0000

Hi Shraddha, 

On 5/29/17, 1:52 PM, "Isis-wg on behalf of Shraddha Hegde"
<[email-masked] on behalf of [email-masked]> wrote:

>Hi Peter,
>
>There could be deployments that allocate Adj-SIDs for links for OAM
>purposes but do not want to include the link for SR-TE topology

I believe this would be contrary to the REQ#2 in
https://www.ietf.org/id/draft-ietf-spring-sr-oam-requirement-03.txt Hence,
I don’t feel that this is valid example.

Thanks,
Acee 

>To: [email-masked]; Les Ginsberg (ginsberg)
><[email-masked]>; Chris Bowers <[email-masked]>; [email-masked]
>> You need to ensure that when a head end computes an RSVP-TE path it
>>uses links where RSVP is currently running. This prevents signaling
>>failures.
>>
>>
>>>        |                         Flags
>>>|
>>> 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.
>>>
>>> privileged information that may be protected by law; they should not
>>>be distributed, used or copied without authorisation.
>> 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.
>>
>> privileged information that may be protected by law; they should not be
>>distributed, used or copied without authorisation.

---

From: <[email-masked]>
Date: Wed, 31 May 2017 07:12:01 +0000

There is no signalling, but some nodes could be SR while some nodes may not.
For SR you can deduce this by looking at the SR capability but this brings two different logics to handle. Having a single one may ease implementation.
Moreover it will allow an operator to prevent some SR links to be used in an SR-TE topology.

-----Original Message-----
From: Peter Psenak [mailto:[email-masked]] 
Sent: Monday, May 29, 2017 16:22
To: LITKOWSKI Stephane OBS/OINIS; Les Ginsberg (ginsberg); Chris Bowers; [email-masked]
Subject: Re: [Isis-wg] draft-hegde-isis-advertising-te-protocols-02 and draft-ginsberg-isis-te-app-00

Stephane,

thanks,
Peter

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 31 May 2017 21:47:58 +0000

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

???

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.

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.

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

From: [email-masked] [mailto:[email-masked]]
Sent: Monday, May 29, 2017 12:46 AM
To: Les Ginsberg (ginsberg); Chris Bowers; [email-masked]
Subject: RE: draft-hegde-isis-advertising-te-protocols-02 and draft-ginsberg-isis-te-app-00

Hi Les,

Brgds,

Stephane

From: Isis-wg [mailto:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Tuesday, May 16, 2017 01:52
To: Chris Bowers; [email-masked]<mailto:[email-masked]>
Subject: Re: [Isis-wg] draft-hegde-isis-advertising-te-protocols-02 and draft-ginsberg-isis-te-app-00

Chris -

vs

             0 1 2 3 4 5 6 7
            +-+-+-+-+-+-+-+-+
            |L|R|S|F|       |
            +-+-+-+-+-+-+-+-+

       R-bit: RSVP-TE

             0 1 2 3 4 5 6 7
            +-+-+-+-+-+-+-+-+
            |L|R|S|F|   |P|X|
            +-+-+-+-+-+-+-+-+

   Les

ISIS-WG,

Chris

======
Attribute Set Identifier

======

=======

                   Type    Description

=======

      0                   1                   2                   3

========

Thank you.

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 31 May 2017 22:00:25 +0000

Looked at both proposals and here are my specific comments:

-          Perhaps without any application identifier/bit the value can be used for all applications. But specifying and ID can restrict to that particular application. With this, I don't see an explosion of identifiers per application as suggested below.

-          One drawback I see with application identifiers -  these would be specific to a domain/AS.  If these values have to be used by a controller for mapping different application identifier in one domain to corresponding

application identifier in another domain would be difficult.  In that sense IANA define application bit mask might fit well.

-          On the new TLV (TLV 238) proposed in https://tools.ietf.org/html/draft-ginsberg-isis-te-app-00

o   Not sure why SRLG need to be a separate TLV to start with as done in RFC 5307 for IPv4 and RFC 6119 for IPv6. This indeed, created lot of grief during BGP-LS time too from  both specification and implementation PoV.

If this need to be fixed these should be brought under T LVs 22, 23, 141, 222, and 223 not a 'new' separate TLV.

o   Hence, strongly disagree to clean-up this SRLG mess with yet another high level TLV

--
Uma C.

From: Isis-wg [mailto:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Monday, May 15, 2017 4:52 PM
To: Chris Bowers <[email-masked]>; [email-masked]
Subject: Re: [Isis-wg] draft-hegde-isis-advertising-te-protocols-02 and draft-ginsberg-isis-te-app-00

Chris -

vs

             0 1 2 3 4 5 6 7
            +-+-+-+-+-+-+-+-+
            |L|R|S|F|       |
            +-+-+-+-+-+-+-+-+

       R-bit: RSVP-TE

             0 1 2 3 4 5 6 7
            +-+-+-+-+-+-+-+-+
            |L|R|S|F|   |P|X|
            +-+-+-+-+-+-+-+-+

   Les

ISIS-WG,

Chris

======
Attribute Set Identifier

======

=======

                   Type    Description

=======

      0                   1                   2                   3

========

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 31 May 2017 23:21:04 +0000

Uma -

From: Uma Chunduri [mailto:[email-masked]]
Sent: Wednesday, May 31, 2017 3:00 PM
To: Les Ginsberg (ginsberg); Chris Bowers; [email-masked]
Subject: RE: draft-hegde-isis-advertising-te-protocols-02 and draft-ginsberg-isis-te-app-00

[Les:] No one - certainly not me - is predicting an "explosion" of applications. That isn't the point I am trying to make.

If we support 3 applications - say SR-TE, LFA, and one User defined App(UDA).

On any interface I could have a need to advertise a link attribute with any of the following scopes:

1)SR-TE only

2)LFA only

3)UDA only

4)SR-TE and LFA

5)SR-TE and UDA

6)LFA and UDA

7)SR-TE and LFA and UDA

If  a bit is assigned to each application (IANA registry or runtime definition), only three bit definitions are needed in order to support all of the above cases.

If a scalar is assigned to represent each combination, then 7 scalars have to be defined.

In order for advertisements to be interpreted consistently by every node these definitions have to be assigned consistently on every node in the network.

If we add support for another UDA then the list above expands to 15 entries ((2**N)-1) for scalars - but only one additional bit need be defined when using a bit mask.

[Les:] I agree with this point.

[Les:] I understand your concern. However, we have existing formats. What we have deliberately done with the extensions is to make sure we do NOT change existing formats for attribute advertisements - we only "encapsulate" with the "application bit mask". This should allow a significant amount of existing TLV parsing code to be reused.

In the case of SRLG if we followed that model precisely we would have had to define two new top level TLVs - one for IPv4/unnumbered and one for IPv6. We wanted to be more frugal in consuming TLV code points so we elected to make the new TLV format flexible enough to accommodate IPv4/IPv6, and unnumbered.

Your proposal is more "ambitious", but I am not sure the benefits are significant enough. There are downsides to advertising SRLG in IS-neighbor TLVs. AS a link may well have multiple SRLG values it could significantly bloat the TLV space used, forcing multiple TLVs for the same neighbor - which would defeat the purpose. And it is harder for an implementation to determine whether a topology change is signaled by the revised IS-neighbor advertisement - so unnecessary SPFs might be triggered as a result.

NOTE: One could make the same argument for link attribute advertisements -that a separate TLV might have been a better solution -  but that ship sailed many years ago.

   Les

--
Uma C.

From: Isis-wg [mailto:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Monday, May 15, 2017 4:52 PM
To: Chris Bowers <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Isis-wg] draft-hegde-isis-advertising-te-protocols-02 and draft-ginsberg-isis-te-app-00

Chris -

vs

             0 1 2 3 4 5 6 7
            +-+-+-+-+-+-+-+-+
            |L|R|S|F|       |
            +-+-+-+-+-+-+-+-+

       R-bit: RSVP-TE

             0 1 2 3 4 5 6 7
            +-+-+-+-+-+-+-+-+
            |L|R|S|F|   |P|X|
            +-+-+-+-+-+-+-+-+

   Les

ISIS-WG,

Chris

======
Attribute Set Identifier

======

=======

                   Type    Description

=======

      0                   1                   2                   3

========

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 31 May 2017 23:57:40 +0000

Les,

For #1, I was saying, if you want to assign a different attribute per application then yes, you need a different scalar. But, if the assumption is most of the attributes are application agnostic you don't have to advertise a separate scalar.

Cheers!
--
Uma C.

From: Uma Chunduri [mailto:[email-masked]]
Sent: Wednesday, May 31, 2017 3:00 PM
To: Les Ginsberg (ginsberg); Chris Bowers; [email-masked]<mailto:[email-masked]>
Subject: RE: draft-hegde-isis-advertising-te-protocols-02 and draft-ginsberg-isis-te-app-00

1)SR-TE only

2)LFA only

3)UDA only

4)SR-TE and LFA

5)SR-TE and UDA

6)LFA and UDA

7)SR-TE and LFA and UDA

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 1 Jun 2017 00:57:57 +0000

Uma -

If all attributes apply to all supported applications on all links on all routers  it is just as easy to use a bit mask as it is a scalar.
If however there is any exception to the above i.e. any link on any router where some attributes cannot be shared by all applications then it is simpler and less error prone to use a bit mask.

We are defining a specification which provides support for all possible use cases.

Besides, you have pointed out another good reason for having standard per application identifiers - they are not domain specific and so can be used across AS's.

   Les

From: Uma Chunduri [mailto:[email-masked]]
Sent: Wednesday, May 31, 2017 4:58 PM
To: Les Ginsberg (ginsberg); Chris Bowers; [email-masked]
Subject: RE: draft-hegde-isis-advertising-te-protocols-02 and draft-ginsberg-isis-te-app-00

Les,

Cheers!
--
Uma C.

1)SR-TE only

2)LFA only

3)UDA only

4)SR-TE and LFA

5)SR-TE and UDA

6)LFA and UDA

7)SR-TE and LFA and UDA