Subject: [Lsr] Opsdir last call review of draft-ietf-ospf-te-link-attr-reuse-12

From: Scott Bradner via Datatracker <[email-masked]>
Date: Wed, 27 May 2020 08:17:05 -0700

Reviewer: Scott Bradner
Review result: Not Ready

This is an OPS-DIR review of OSPF Link Traffic Engineering Attribute Reuse
(draft-ietf-ospf-te-link-attr-reuse)

This ID describes application-specific attribute advertisements for use in OSPF.

I found this ID hard to read and recommend that it be reviewed for readability.

I have a basic question about this proposal – the ID describes specific
advertisements to be used when particular applications want to make use of
specific link attributes and says that other applications should not make of
the information in the advertisement without saying why such use would be a
problem.  I can imagine some reasons but it seems to me that it would be good
if this document just explained the problem it is trying to solve.

Some specific issues in the document

Page 6 – the text says “Standard Application Identifier Bit Mask: Optional set
of bits, where each bit represents a single standard application.  Bits are
defined in [I-D.ietf-isis-te-app].”  - it seems to me that this should be in an
IANA registry for extensibility but it does not seem to be in the referenced ID
but I could not actually tell

Page 6 – text says “The bits are repeated here for informational purpose” 
maybe point to a IANA registry or say “current assignments”

Page 6 – text says “If the link attribute advertisement is limited to be used
by a specific set of applications”  - maybe say “intended” rather than
“limited” since I do not see a way to actually limit a future application from
eavesdropping on the advertisement

Page 7 – the text says “If the SABM or UDABM length is other than 0, 4, or 8,
the ASLA sub-TLV MUST be ignored by the receiver.”  - it would seem to be
useful operations-wise to say that an indication of an error should be recorded
somewhere

Page 7 – a “User Defined Application Identifier” is introduced but never
described – what uses it and what is it used for

Section 11 – I found this discussion of the relationship between the existence
of a particular advertisement and the possible existence of an application to
use that advertisement to be quite confusing – if the existence of a particular
advertisement does not indicate that any application is listening why not just
say that?

Section 12.1 – it would help to say what problem is trying to be solved – why
is the use of RSVP-TE LSA advertisements a problem?

Section 12.3.3 – I could not tell if this section is saying that the
application specific attribute advertisements could not be used if there is
even a single legacy router present of if the presence of such a router means
that the application specific attribute advertisements can be used but the old
advertisements must also be used Section 14 – it might help to say how new
Sub-TLV types can be added to the registry

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 27 May 2020 22:07:49 +0000

Hi Scott, 

On 5/27/20, 11:17 AM, "Scott Bradner via Datatracker" <[email-masked]> wrote:

    Reviewer: Scott Bradner
    Review result: Not Ready

We had a lengthy discussion of the requirements in the working group and I'm not sure why you are asking what problem this is solving when it is clearly stated in the abstract and further elaborated in the "Introduction".  A side benefit is that we will not have to advertise the OSPF TE LSAs which would need to be correlated with the LSAs for applications. Perhaps that should also be stated. See one more inline below. 

Perhaps the LSR WG COULD have solved the problem with the existing RSVP-TE LSAs. However, this was not the consensus of the WG and the, IMO, the resultant encodings would have been sub-optimal. The resultant information would have been spread over more LSAs and you would have more chicken and egg situations with the correlation of LSAs. Now, with OSPFv3 Extended LSAs, all the required information is advertised in a single LSAs. 

Thanks,
Acee

---

From: Peter Psenak <[email-masked]>
Date: Thu, 28 May 2020 16:09:13 +0200

Hi Scott,

please see inline (##PP):

> if this document just explained the problem it is trying to solve.

##PP

There are two problems mentioned in the Introduction section:

1) Ambiguity in terms of which of the advertisements are to be used by 
RSVP-TE and which ones should not be. When RSVP was the only application 
using these attributes, advertisement of these attributes meant that 
RSVP was enabled on the link. Such link was considered as a part of the 
RSVP-TE topology. With other applications using and advertising these 
link attributes, this logic can not be used anymore, which created the 
mentioned ambiguity.

2) Lack of support for application specific values for the link attribute.

I thought this was clear, but if it is not, please suggest what else 
needs to be said.

> but I could not actually tell

##PP
that's a fair point. I have changed to:

"Bits are defined in the Link Attribute Application Identifier Registry, 
which has been defined in [I-D.ietf-isis-te-app]."

> maybe point to a IANA registry or say “current assignments”

##PP
sure, changed to "current assignments”

> eavesdropping on the advertisement

##PP
changed to "intended to be only used by"

> useful operations-wise to say that an indication of an error should be recorded

##PP
fair enough, changed to:

"MUST be ignored by the receiver and an error SHOULD be logged (subject 
to rate limiting)."

> described – what uses it and what is it used for
##PP
we provide a way for the user to advertise link attributes for the 
purpose of something that is not defined as standardized application. 
What such application might be is not subject to the specification.

> advertisement does not indicate that any application is listening why not just

##PP
there are applications where the application enablement on the link is 
relevant - e.g. RSVP-TE - one need to make sure that RSVP is enabled on 
the link before sending a RSVP signaling message over it.

There are applications, where the enablement of the application on the 
link is irrelevant and has nothing to do with the fact that some link 
attributes are advertised for the purpose of such application - e.g. LFA.

We have provided full flexibility to support both.

> is the use of RSVP-TE LSA advertisements a problem?

##PP
please see my response above in the context of the Introduction section.

> advertisements must also be used 

##PP
a) as long as there is a single legacy router present, all routers MUST 
continue to advertise link attributes using legacy advertisements to 
allow the legacy router to function properly.

b) new advertisements can be used in parallel and they can be used by 
the routers that do understand them.

The text in 12.3.3 says:

    "Send application specific advertisements while continuing to
     advertise using legacy (all advertisements are then duplicated)."

> Section 14 – it might help to say how new Sub-TLV types can be added to the registry

##PP
we are not defining a nynew registry, we only use existing ones. These 
registries have their own registration procedures.

thanks,
Peter

---

From: "Scott O. Bradner" <[email-masked]>
Date: Sat, 30 May 2020 14:38:20 -0400

thanks for the reply - see in line

> On May 28, 2020, at 10:09 AM, Peter Psenak <ppsenak=[email-masked]> wrote:
> 
> Hi Scott,
> 
> 1) Ambiguity in terms of which of the advertisements are to be used by RSVP-TE and which ones should not be. When RSVP was the only application using these attributes, advertisement of these attributes meant that RSVP was enabled on the link. Such link was considered as a part of the RSVP-TE topology. With other applications using and advertising these link attributes, this logic can not be used anymore, which created the mentioned ambiguity.
> 
> I thought this was clear, but if it is not, please suggest what else needs to be said.

yes - I saw that but I missed seeing why these are a  problem - what harm can come form specifically the first one?
I fully expect there are real problems but I think it would be useful to say what they are

<snip>

> we provide a way for the user to advertise link attributes for the purpose of something that is not defined as standardized application. What such application might be is not subject to the specification.

can that just be said?

> there are applications where the application enablement on the link is relevant - e.g. RSVP-TE - one need to make sure that RSVP is enabled on the link before sending a RSVP signaling message over it.
> 
> There are applications, where the enablement of the application on the link is irrelevant and has nothing to do with the fact that some link attributes are advertised for the purpose of such application - e.g. LFA.
> 

I think it would help to say that in the ID

<snip>

> a) as long as there is a single legacy router present, all routers MUST continue to advertise link attributes using legacy advertisements to allow the legacy router to function properly.
> 
> b) new advertisements can be used in parallel and they can be used by the routers that do understand them.
> 
> The text in 12.3.3 says:
> 

I found it confusing - can you say what you said here?

> we are not defining a nynew registry, we only use existing ones. These registries have their own registration procedures.

I did not see a clear statement that said that was what you are doing or a clear pointer to where someone should go if they wanted to add a new value

Scott

> 
> thanks,
> Peter
> 
> 
> 
> 
> 
> 
> -- 
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call