Subject: Re: [Lsr] Rtgdir last call review of draft-ietf-isis-te-app-13

From: <[email-masked]>
Date: Tue, 2 Jun 2020 16:33:09 +0000

Les,

Thanks for your answers.
Comments inline

> From: Les Ginsberg (ginsberg) [mailto:[email-masked]] 
> Sent: Saturday, May 30, 2020 12:09 AM
> 
> Bruno -
> 
> Thanx for your (as always) meticulous review.
> Responses inline.
> Once we have reached agreement I will send out an updated version.
> 
> > -----Original Message-----
> > From: Bruno Decraene via Datatracker <[email-masked]>
> > Sent: Friday, May 29, 2020 10:18 AM
> > To: [email-masked]
> > Cc: [email-masked]; [email-masked]; [email-masked]
> > Subject: Rtgdir last call review of draft-ietf-isis-te-app-13
> > 
> > Reviewer: Bruno Decraene
> > Review result: Has Issues
> > 
> >  Hello,
> > 
> > I have been selected as the Routing Directorate reviewer for this draft. The
> > Routing Directorate seeks to review all routing or routing-related drafts as
> > they pass through IETF last call and IESG review, and sometimes on special
> > request. The purpose of the review is to provide assistance to the Routing
> > ADs.
> > For more information about the Routing Directorate, please see
> > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
> > 
> > Although these comments are primarily for the use of the Routing ADs, it
> > would
> > be helpful if you could consider them along with any other IETF Last Call
> > comments that you receive, and strive to resolve them through discussion or
> > by
> > updating the draft.
> > 
> > Document: draft-ietf-isis-te-app-13
> > Reviewer: Bruno Decraene
> > Review Date: 2020-05-29
> > IETF LC End Date: 2020-05-29
> > Intended Status: Standards Track
> > 
> > Summary:
> >     I have some minor concerns about this document that I think should be
> >     resolved before publication.
> > 
> > Comments:
> >   Draft is clear.
> > 
> > Minor Issues:
> > 
> > §4.1
> > *2 (for SABM & UDABM fields)
> > OLD: The length SHOULD be the minimum required to send all bits which are
> > set.
> > I'd propose
> > NEW: The length SHOULD be the minimum required to send all the
> > meaningful bits
> > which are set.
> > 
> > Motivation; the 'bits which are sent' are the bits in the SABM field. (they do
> > include non-meaningful and padding bits)
> > 
> 
> [Les:] The definition of what is "meaningful" and what is "padding"  to me is ambiguous.
> Meaningful could be only those bits which are currently defined in the registry (speaking of SABM here). But if there are 10 bits defined in the registry and I only intend to set Bit 5, I do not need to send all 10 bits - I only need to send one octet - because we state:
> 
> "Bits that are NOT transmitted MUST be treated as if they
   > are set to 0 on receipt.  "
> 
> Also, an implementation written when there were only 4 bits defined in the registry might think that "meaningful" is different than an implementation written when more than 8 bits were defined in the registry. Yet they can still interoperate.
> 
> I believe the current language is best.

[Bruno]
I withdraw my comment. Sorry for the noise.
I had read "bits which are sent", while the text is "bits which are set".

> > ----
> > 
> > OLD: Undefined bits MUST be transmitted as 0
> > NEW: Undefined transmitted bits MUST be cleared (0)
> > 
> > Motivation: currently the number of undefined bits is 8*8-3. They SHOULD
> > not be
> > transmitted (beyond the first ones fitting in the first N required octet). The
> > sentence "Undefined bits MUST be transmitted as 0" could be read as all
> > defined
> > bits MUST be transmitted (as 0).
> > ---
> [Les:] I do not see how that could be a valid interpretation given that we state:
> 
> " The length SHOULD  be the minimum required to send all bits which are set."

[Bruno]
So we have
1) The length SHOULD  be the minimum required to send all bits which are set
2) Undefined bits MUST be transmitted as 0

Given the "MUST"  vs "SHOULD" and "transmitted" (which means "sent"), I do believe my proposal is better. But I won't insist.

> And (repeating)
> 
> "Bits that are NOT transmitted MUST be treated as if they
   > are set to 0 on receipt.  "
> 
> And again, you assume that "defined bits" is the same for all implementations - which isn't guaranteed as I discussed above.

[Bruno] I don't think that this matter as the behavior is specific to the sender.
In addition, the term " Undefined bits" is yours.
 
> 
> > User Defined Application Identifier Bits have no name. I'd propose to call
> > them
> > UDABM[0], UDABM[1]... This may avoid that different implementation use
> > different names and, more problematic, that some implementations starting
> > with
> > 1 (the first, the second) while while some other implementations starts as 0,
> > creating interop issues (SABM[1] on node A is SABM[0] on node B)
> > ---
> 
> [Les:] What implementations may name bits they assign from the User space is out of scope of this document.
> If I were implementing a non-standard User App I likely would give it a meaningful name both in my code and in any documentation I produce.

[Bruno] ok, let's leave the terminology choice for this parameter to an hypothetical yang model.
 
> As far as interoperability, if you want multiple vendors to interoperate then you need a standard application. User defined applications do not provide any guarantee of interoperability.
> 
> We do state that 
> 
> "It is recommended that [user defined] bits are used starting with Bit 0..."
> 
> but as User Defined Applications are outside the scope of the document they might choose to do otherwise.
> 
> 
> > §4.2
> > 
> > "In cases where conflicting values for the same application/attribute/link are
> > advertised all the conflicting values MUST be ignored." I'd propose to add
> > "for
> > this application" (IOW, those values are still applicable for all other
> > applications)
> > ---
> 
> [Les:] How about adding "for the specified application" ?

[Bruno] Looks good.

> > §6.2
> > I'd argue that the first part of section 3.2 is a specification of the behavior
> > and hence should be moved to section 4.1, rather than placed in the section
> > "deployment consideration" which eventually will not be read by someone
> > implementing the specification. Especially since the text in section 4.1
> > implies a different behavior: "Bits that are NOT transmitted MUST be treated
> > as
> > if they are set to 0 on receipt."
> > ---
> 
> [Les:] I think you meant to say the "first part of section 6.2"?? Correct?

[Bruno] yes, you are correct.

> 
> If so, I agree - and will move that text - though I would prefer to put it into Section 4.2.
> Section 4.1 is describing the encoding of the bit mask. Section 4.2 describes the ASLA sub-TLV and how to interpret it.
> For example, that is where L-bit is discussed.
> Sound good to you?

[Bruno] Looks good. Thank you.

> 
> > §5
> > "In the case of SRTE, advertisement of application specific link attributes
> > does NOT indicate enablement of SRTE." What does "enablement of SRTE"
> > means? Do
> > you have a pointer to a document/text?
> > 
> > I'm not sure I would keep that paragraph on SR-TE enablement.
> > ---
> 
> [Les:] The paragraph is required because we state 
> 
> "the relationship between application specific link attribute
   > advertisements and enablement for that application"
> 
> is required for all new applications.

[Bruno]   The argument seems weak to me. Change "MUST" to "SHOULD" and voilà, problem solved!
Also the requirement is 'for the future' and to be defined application. Stricto census it does not apply to you in this draft.

> In this document we are providing that definition for the three existing applications.
> 
> The paragraph does state:
> 
> "SRTE is implicitly enabled on all links
   > which are part of the Segment Routing enabled topology independent of
   > the existence of link attribute advertisements."
> 
> I will modify the first sentence to say:
> 
> "In the case of SRTE, advertisement of application specific link
   > attributes does NOT indicate enablement of SRTE  on that link."
> 
> ("on that link" is added)
> 
> Does this work for you?

[Bruno]   I still have the same question: What does "enablement of SRTE" means?

> > §6.1
> > "Under the conditions defined above, implementations which support the
> >    extensions defined in this document have the choice of using legacy
> >    advertisements or application specific advertisements in support of
> >    SRTE and/or LFA.  This will require implementations to provide
> >    controls specifying which type of advertisements are to be sent/
> >    processed on receive for these applications."
> > 
> > I think that "have the choice" is not prescriptive enough given the
> > deployment
> > issues described in section 6.3 I'd rather say that implementations MUST
> > support the use of both advertisements (legacy and application specific
> > advertisement) and MUST provide controls specifying which type of
> > advertisements are to be processed on receive for these applications.
> > 
> 
> [Les:] We know that existing deployments (pre-this draft) use legacy for SRTE/LFA.
> In the future, implementations could choose to migrate to using the new ASLA advertisements for SRTE/LFA. Whether they will do so or not is a business decision.

[Bruno] As written in the draft, this is required for interop. So I don't see this as a business decision

I'm quoting the draft
in section 6.3 "deployments using the
   extensions defined in this document must be able to co-exist with use
   of the legacy advertisements by routers which do not support the
   extensions defined in this document."

In order for deployments to be able to follow this 'must', the implementation MUST support it.

In section 6.3.1 "interoperability is achieved by using legacy advertisements and
   sending application specific advertisements with L-flag set and no
   link attribute values."

In section 6.3.3
"So long as there is any
   legacy router in the network which has any of the applications
   enabled, all routers MUST continue to advertise link attributes using
   legacy advertisements."

So from above, all routers MUST be capable of sending and receiving legacy advertisements. This seem to be aligned with my text.

--Bruno

> We do not want to declare implementations as non-conformant if they do not migrate.

   > Les

_________________________________________________________________________________________________________________________

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: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 4 Jun 2020 14:29:49 +0000

Bruno -

Thanx again for your review.
V14 of the draft has been posted to address your comments.

Please let me know if you believe there are still outstanding issues.

A few more remarks inline.

> From: [email-masked] <[email-masked]>
> Sent: Tuesday, June 02, 2020 9:33 AM
> To: Les Ginsberg (ginsberg) <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked]; rtg-
> [email-masked]
> Subject: RE: Rtgdir last call review of draft-ietf-isis-te-app-13
> 
> Les,
> 
> Thanks for your answers.
> Comments inline
> 
> > Meaningful could be only those bits which are currently defined in the
> registry (speaking of SABM here). But if there are 10 bits defined in the
> registry and I only intend to set Bit 5, I do not need to send all 10 bits - I only
> need to send one octet - because we state:
> >
> > Also, an implementation written when there were only 4 bits defined in
> the registry might think that "meaningful" is different than an
> implementation written when more than 8 bits were defined in the registry.
> Yet they can still interoperate.
> >
> Given the "MUST"  vs "SHOULD" and "transmitted" (which means "sent"), I
> do believe my proposal is better. But I won't insist.
> 

[Les:] I took a second look at this and appreciated your point better.
I changed the text to read:

" Undefined bits which are transmitted MUST be transmitted as 0..."

> > And again, you assume that "defined bits" is the same for all
> implementations - which isn't guaranteed as I discussed above.
> 
> > If I were implementing a non-standard User App I likely would give it a
> meaningful name both in my code and in any documentation I produce.
> 
> > As far as interoperability, if you want multiple vendors to interoperate then
> you need a standard application. User defined applications do not provide
> any guarantee of interoperability.
> >
> > We do state that
> >
> > Section 4.1 is describing the encoding of the bit mask. Section 4.2 describes
> the ASLA sub-TLV and how to interpret it.
> Also the requirement is 'for the future' and to be defined application. Stricto
> census it does not apply to you in this draft.
> 
[Les:] As stated in the draft, 

" SRTE is implicitly enabled
   on all links which are part of the Segment Routing enabled topology
   independent of the existence of link attribute advertisements."

This means that all links in an SR enabled topology may be used by SRTE. Link attribute advertisements serve to provide information which can be used to apply constraints, but they are not necessary in order for the link to be used as part of an SR Policy.
The most obvious example of this is a policy composed of adjacency-SIDs, directing the traffic along a specific set of links independent of any advertised link attributes.
HTH.

> > In the future, implementations could choose to migrate to using the new
> ASLA advertisements for SRTE/LFA. Whether they will do so or not is a
> business decision.
> 
> So from above, all routers MUST be capable of sending and receiving legacy
> advertisements. This seem to be aligned with my text.
> 
[Les:] Multiple deployment scenarios are possible.
There may be a deployment where legacy routers and routers supporting the extensions defined in this draft are present and SRTE (for example) is in use. In this case it is necessary that the updated routers be able to support legacy advertisements.

But there may also be a deployment where only upgraded routers are deployed and SRTE is in use. In this case support of legacy advertisements is NOT required.

Vendors may make the decision - now or in the future - to deprecate support for legacy advertisements in their implementations. Clearly, if they do so they will not be able to interoperate with legacy routers. But if they do not see such a limitation as "bad for business" then they may opt to do that.
This does not make these implementations in violation of this specification - which is why using language which requires implementations to always support legacy is inappropriate.

I did modify a sentence in Section 6.3 to say

" Therefore deployments using the
   extensions defined in this document in the presence of routers which
   do not support these extensions need to be able to interoperate with
   the use of legacy advertisements by the legacy routers."

   Les

> __________________________________________________________
> __________________________________________________________
> _____
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: <[email-masked]>
Date: Fri, 5 Jun 2020 12:55:28 +0000

Les,

Thanks for the updated draft.
Looks ok to me except the point on interoperability. 

Indeed, I was asking to reinforce the requirement for interoperability with existing attributes, as this interop issue is created by this specification/extension. But you chose the opposite direction by calling existing routers "legacy routers" and by removing the "must" in the below sentence from -13 "must be able to co-exist with use  of the legacy advertisements by routers which do not support the extensions defined in this document.".
IMHO this document was primarily motivated by interoperability issues with implementations. This was correctly pointed out in [1], more specifically " Existing IS-IS standards do not provide a mechanism to explicitly indicate whether or not RSVP has been enabled on a link.  Instead, different RSVP-TE implementations have used the presence of certain traffic engineering sub-TLVs in IS-IS to infer that RSVP signalling is enabled on a given link."

In such condition, IMHO draft-ietf-isis-te-app should not have the potential to create new interop issues in the future, otherwise its net gain with regards to existing ("legacy") attributes seems debatable to me.

Moving the requirement for interoperability on the deployment side (i.e., network operator) as per -14, may prove difficult or impossible if implementers are not willing to accommodate. Given that, as you state it, there motivation is what's good for _their_ business, it seems a possibility that such vendor would argue that the network operator should just replace all their "older" routers with new ones, and as a matter of luck, they do have a very good deal to propose. I have seen this movie before (e.g. with LDP & TDP).

I also understand your point as a vendor.
After thinking about it for a while, I'd propose a resolution around indicating that interoperability is required but only for implementations supporting both new and current attributes. This cover my point for interop and a priori cover your point to allow implementation to only support the new attributes.

e.g. with the below text in §6.1
OLD:
Under the conditions defined above, implementations which support the
   extensions defined in this document have the choice of using legacy
   advertisements or application specific advertisements in support of
   SRTE and/or LFA.  This will require implementations to provide
   controls specifying which type of advertisements are to be sent/
   processed on receive for these applications.

NEW:
Under the conditions defined above, implementations which support 
both the legacy advertisements and the extensions defined in this document MUST provide controls  specifying which type of
advertisements are to be sent and which type of advertisements are to be processed on receive for these applications.

Or possibly much closer to your original text
NEW2
Under the conditions defined above, implementations which support
 both the legacy advertisements and the extensions defined in this document
have the choice of using legacy
   advertisements or application specific advertisements in support of
   SRTE and/or LFA.  Implementations are REQUIRED to provide
   controls specifying which type of advertisements are to be sent/
   processed on receive for these applications.

I would also revert the text in section 6.3 to the one present in version -13.

Thank you
--Bruno

[1] https://datatracker.ietf.org/doc/html/draft-hegde-isis-advertising-te-protocols-03#section-1

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 5 Jun 2020 16:42:52 +0000

Bruno -

Inline.

> Sent: Friday, June 05, 2020 5:55 AM

> Indeed, I was asking to reinforce the requirement for interoperability with

> existing attributes, as this interop issue is created by this

> specification/extension. But you chose the opposite direction by calling

> existing routers "legacy routers" and by removing the "must" in the below

> sentence from -13 "must be able to co-exist with use  of the legacy

> advertisements by routers which do not support the extensions defined in

> this document.".

> IMHO this document was primarily motivated by interoperability issues with

> implementations. This was correctly pointed out in [1], more specifically "

> Existing IS-IS standards do not provide a mechanism to explicitly indicate

> whether or not RSVP has been enabled on a link.  Instead, different RSVP-TE

> implementations have used the presence of certain traffic engineering sub-

> TLVs in IS-IS to infer that RSVP signalling is enabled on a given link."

[Les:] This is not correct.

The motivations for the draft are stated in the Introduction.

The issue discussed in https://datatracker.ietf.org/doc/html/draft-hegde-isis-advertising-te-protocols-03#section-1 has nothing to do with this draft.

> In such condition, IMHO draft-ietf-isis-te-app should not have the potential

> to create new interop issues in the future, otherwise its net gain with regards

> to existing ("legacy") attributes seems debatable to me.

> Moving the requirement for interoperability on the deployment side (i.e.,

> network operator) as per -14, may prove difficult or impossible if

> implementers are not willing to accommodate. Given that, as you state it,

> there motivation is what's good for _their_ business, it seems a possibility

> that such vendor would argue that the network operator should just replace

> all their "older" routers with new ones, and as a matter of luck, they do have

> a very good deal to propose. I have seen this movie before (e.g. with LDP &

> TDP).

> After thinking about it for a while, I'd propose a resolution around indicating

> that interoperability is required but only for implementations supporting

> both new and current attributes. This cover my point for interop and a priori

> cover your point to allow implementation to only support the new attributes.

> MUST provide controls  specifying which type of

> advertisements are to be sent and which type of advertisements are to be

>  both the legacy advertisements and the extensions defined in this

> document

[Les:] It is not within the purview of the IETF to mandate what features vendors support.

What is normative in this draft - as with all protocol enhancements - is the definition of how "bits on the wire" are sent/received.

The introduction of any protocol extension in brownfield deployments creates the possibility that some routers support the extension and some do not.

How vendors handle this is an implementation issue.

We have provided guidance in this draft as to what issues may arise and what strategies can be used to address the interoperability issues - as well as how to migrate from a mixture of legacy/new to all new. But I do not believe we can make normative statements requiring implementations to support all combinations. If we did so, we would then be responsible for declaring when implementations are no longer required to support backwards compatibility because legacy support is no longer a significant issue.

I appreciate from customer POV, that vendors may be opportunistic and use backwards compatibility (or the lack thereof) as an incentive to get you to upgrade and you might prefer to do this on your timeline rather than the vendor's timeline. But this is a business issue - not a standards issue.

[Les:] The old text was:

"Therefore deployments using the

The new text is:

"Therefore deployments using the

Two changes of significance were made:

1)"in the presence of routers which do not support these extensions"

was inserted to clarify that the interoperability issue only exists when such routers are in the deployment.

2)"must" was changed to "need"

Note that the original "must" was lowercase (non-normative) quite intentionally.

I replaced it with "need" because I did not want to get a comment suggesting that I accidentally forgot to use uppercase. 😊

As discussed above, making a normative statement here is not within the scope of the draft.

   Les

> [1] https://datatracker.ietf.org/doc/html/draft-hegde-isis-advertising-te-<https://datatracker.ietf.org/doc/html/draft-hegde-isis-advertising-te-protocols-03#section-1>

> protocols-03#section-1<https://datatracker.ietf.org/doc/html/draft-hegde-isis-advertising-te-protocols-03#section-1>

> > > From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>

> > > To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>

> > > Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; rtg-

> > > [email-masked]<mailto:[email-masked]>

> > > > > From: Bruno Decraene via Datatracker <[email-masked]<mailto:[email-masked]>>

> > > > > To: [email-masked]<mailto:[email-masked]>

> > > > > Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

> > > > > I have been selected as the Routing Directorate reviewer for this

> draft.

> > > The

> > > > > Routing Directorate seeks to review all routing or routing-related

> drafts as

> > > > > they pass through IETF last call and IESG review, and sometimes on

> > > special

> > > > > request. The purpose of the review is to provide assistance to the

> > > Routing

> > > > > Although these comments are primarily for the use of the Routing

> ADs, it

> > > > > be helpful if you could consider them along with any other IETF Last

> Call

> > > > > comments that you receive, and strive to resolve them through

> > > discussion or

> > > > >     I have some minor concerns about this document that I think should

> be

> > > > > OLD: The length SHOULD be the minimum required to send all bits

> which

> > > are

> > > > > Motivation; the 'bits which are sent' are the bits in the SABM field.

> (they

> > > do

> > > > [Les:] The definition of what is "meaningful" and what is "padding"  to

> me is

> > > ambiguous.

> > > registry and I only intend to set Bit 5, I do not need to send all 10 bits - I

> only

> > > implementation written when more than 8 bits were defined in the

> registry.

> > > > > Motivation: currently the number of undefined bits is 8*8-3. They

> > > SHOULD

> > > > > transmitted (beyond the first ones fitting in the first N required

> octet).

> > > The

> > > > > sentence "Undefined bits MUST be transmitted as 0" could be read as

> all

> > > > [Les:] I do not see how that could be a valid interpretation given that

> we

> > > state:

> > > > " The length SHOULD  be the minimum required to send all bits which

> are

> > > set."

> > > 1) The length SHOULD  be the minimum required to send all bits which

> are

> > > set

> > > Given the "MUST"  vs "SHOULD" and "transmitted" (which means

> "sent"), I

> > > [Bruno] I don't think that this matter as the behavior is specific to the

> sender.

> > > > > User Defined Application Identifier Bits have no name. I'd propose to

> call

> > > > > UDABM[0], UDABM[1]... This may avoid that different

> implementation

> > > use

> > > > > different names and, more problematic, that some implementations

> > > starting

> > > > > 1 (the first, the second) while while some other implementations

> starts

> > > as 0,

> > > > [Les:] What implementations may name bits they assign from the User

> > > space is out of scope of this document.

> > > [Bruno] ok, let's leave the terminology choice for this parameter to an

> > > hypothetical yang model.

> > > > As far as interoperability, if you want multiple vendors to interoperate

> then

> > > you need a standard application. User defined applications do not

> provide

> > > > "It is recommended that [user defined] bits are used starting with Bit

> 0..."

> > > > but as User Defined Applications are outside the scope of the

> document

> > > they might choose to do otherwise.

> > > > > "In cases where conflicting values for the same

> application/attribute/link

> > > are

> > > > > advertised all the conflicting values MUST be ignored." I'd propose to

> add

> > > > > I'd argue that the first part of section 3.2 is a specification of the

> behavior

> > > > > and hence should be moved to section 4.1, rather than placed in the

> > > section

> > > > > "deployment consideration" which eventually will not be read by

> > > someone

> > > > > implies a different behavior: "Bits that are NOT transmitted MUST be

> > > treated

> > > > If so, I agree - and will move that text - though I would prefer to put it

> into

> > > Section 4.2.

> > > > Section 4.1 is describing the encoding of the bit mask. Section 4.2

> describes

> attributes

> > > > > does NOT indicate enablement of SRTE." What does "enablement of

> > > SRTE"

> > > [Bruno]   The argument seems weak to me. Change "MUST" to "SHOULD"

> > > and voilà, problem solved!

> > > Also the requirement is 'for the future' and to be defined application.

> Stricto

> > > > In this document we are providing that definition for the three existing

> > > applications.

> > >    > which are part of the Segment Routing enabled topology independent

> of

> > > [Bruno]   I still have the same question: What does "enablement of SRTE"

> > > means?

> > This means that all links in an SR enabled topology may be used by SRTE.

> Link attribute advertisements serve to provide information which can be

> used to apply constraints, but they are not necessary in order for the link to

> be used as part of an SR Policy.

> > The most obvious example of this is a policy composed of adjacency-SIDs,

> directing the traffic along a specific set of links independent of any advertised

> link attributes.

> > > > > "Under the conditions defined above, implementations which

> support

> > > the

> > > > > issues described in section 6.3 I'd rather say that implementations

> MUST

> > > > > support the use of both advertisements (legacy and application

> specific

> > > > [Les:] We know that existing deployments (pre-this draft) use legacy

> for

> > > SRTE/LFA.

> > > > In the future, implementations could choose to migrate to using the

> new

> > > [Bruno] As written in the draft, this is required for interop. So I don't see

> this

> > > as a business decision

> > > In order for deployments to be able to follow this 'must', the

> implementation

> > > MUST support it.

> > > In section 6.3.1 "interoperability is achieved by using legacy

> advertisements

> > > and

> > > So from above, all routers MUST be capable of sending and receiving

> legacy

> > There may be a deployment where legacy routers and routers supporting

> the extensions defined in this draft are present and SRTE (for example) is in

> use. In this case it is necessary that the updated routers be able to support

> legacy advertisements.

> > But there may also be a deployment where only upgraded routers are

> deployed and SRTE is in use. In this case support of legacy advertisements is

> NOT required.

> > Vendors may make the decision - now or in the future - to deprecate

> support for legacy advertisements in their implementations. Clearly, if they

> do so they will not be able to interoperate with legacy routers. But if they do

> not see such a limitation as "bad for business" then they may opt to do that.

> > This does not make these implementations in violation of this specification

> - which is why using language which requires implementations to always

> support legacy is inappropriate.

> > > > We do not want to declare implementations as non-conformant if they

> do

> > > not migrate.

> > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu

> ce

> > > message par erreur, veuillez le signaler

> > > Orange decline toute responsabilite si ce message a ete altere, deforme

> ou

> > > falsifie. Merci.

> > > 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.

> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce

> message par erreur, veuillez le signaler

> Orange decline toute responsabilite si ce message a ete altere, deforme ou

> falsifie. Merci.

> 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.

---

From: <[email-masked]>
Date: Mon, 8 Jun 2020 07:48:12 +0000

Les,

Please see inline [Bruno]

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Friday, June 5, 2020 6:43 PM
To: DECRAENE Bruno TGI/OLN
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: Rtgdir last call review of draft-ietf-isis-te-app-13

Bruno -

Inline.

[Bruno] There are multiple motivations, but this discussion is behind us now.

That been said, by changing the encoding of existing parameters, this document does create a backward compatible issue, while many networks did not need this new encoding in the first place. I believe the document needs to handle the issue it is introducing.

[Bruno] This is not what I’m proposing.

I’m proposing that _if_ a vendor _choose_ to support _both_ encodings, then the implementation must provide the control to allow which encoding is used.

We all agree that this is required for interop (there is a whole section 6 about this), so let’s write it.

[1] https://tools.ietf.org/html/draft-ietf-isis-te-app-14#section-6

--Bruno

[Les:] The old text was:

The new text is:

   Les

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 11 Jun 2020 18:30:51 +0000

Bruno –

Just to be sure we are officially closed on this discussion…

I am not planning any additional changes to the document.
If this is not acceptable to you please let me know.

Responses inline.

Sent: Monday, June 08, 2020 12:48 AM

Les,

Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Bruno -

Inline.

[Les:] We devote an entire section to deployment considerations including discussion of compatibility issues and how to transition to full use of the new sub-TLV.

So I believe we have addressed these issues.

[Les:] To repeat, I do not believe normative statements regarding implementation strategies are appropriate. We have made the point that advertisement type (legacy/new/both) controls are likely needed, which serves as a guide to implementors. I believe this is sufficient.

If you absolutely insist, I will make your suggested change – but I really do not think this is the right thing to do.

   Les

--Bruno

[Les:] The old text was:

The new text is:

   Les

Thank you.

---

From: <[email-masked]>
Date: Fri, 12 Jun 2020 13:58:12 +0000

Les,

Sent: Thursday, June 11, 2020 8:31 PM

Bruno –

I am not planning any additional changes to the document.
[Bruno] I had figured that out, but thanks for officially closing the discussion.

If this is not acceptable to you please let me know.
[Bruno] I think we both stated our points; no need to repeat. So let’s agree to disagree.

--Bruno

Responses inline.

Les,

Bruno -

Inline.

   Les

--Bruno

[Les:] The old text was:

The new text is:

   Les

Thank you.