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

["Acee Lindem (acee)" <[e-mail]>]

Hi Shraddha, 

On 5/29/17, 1:52 PM, "Isis-wg on behalf of Shraddha Hegde"
<[e-mail] on behalf of [e-mail]> 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
>And do not want to run SR traffic on those links.

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 

>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:[e-mail]] On Behalf Of Peter Psenak
>Sent: Monday, May 29, 2017 7:52 PM
>To: [e-mail]; Les Ginsberg (ginsberg)
><[e-mail]>; Chris Bowers <[e-mail]>; [e-mail]
>Subject: Re: [Isis-wg] draft-hegde-isis-advertising-te-protocols-02 and
>draft-ginsberg-isis-te-app-00
>
>Stephane,
>
>On 29/05/17 16:06 , [e-mail] wrote:
>> The use case is more for SR and RSVP.
>
>can you please clarify the SR use case? There is no signaling there.
>
>thanks,
>Peter
>
>> 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:[e-mail]]
>> Sent: Monday, May 29, 2017 10:15
>> To: LITKOWSKI Stephane OBS/OINIS; Les Ginsberg (ginsberg); Chris
>> Bowers; [e-mail]
>> 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 , [e-mail] 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:[e-mail]] *On Behalf Of *Les
>>> Ginsberg (ginsberg)
>>> *Sent:* Tuesday, May 16, 2017 01:52
>>> *To:* Chris Bowers; [e-mail]
>>> *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-protoco
>>> l
>>> s
>>>
>>> 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:[e-mail]] *On Behalf Of *Chris
>>> Bowers
>>> *Sent:* Friday, May 12, 2017 10:47 AM
>>> *To:* [e-mail] <mailto:[e-mail]>
>>> *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.
>>>
>>>
>>>
>>> _______________________________________________
>>> Isis-wg mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/isis-wg
>>>
>>
>>
>> ______________________________________________________________________
>> ___________________________________________________
>>
>> 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.
>>
>> .
>>
>
>_______________________________________________
>Isis-wg mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/isis-wg
>
>_______________________________________________
>Isis-wg mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/isis-wg