Subject: [Lsr] Roman Danyliw's No Objection on draft-ietf-ospf-te-link-attr-reuse-14: (with COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Wed, 10 Jun 2020 14:58:29 -0700

Roman Danyliw has entered the following ballot position for
draft-ietf-ospf-te-link-attr-reuse-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ospf-te-link-attr-reuse/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(revised)
** Section 5.  (same comment as raised about Section 4.1. of
draft-ietf-isis-te-app) If the possible values of SABM Length and UDABM Length
are 0, 4 and 8, and these are stored literally, why are 8 bits required?  Could
they be reallocated to the Reserved field?

** Section 13. (same comment as raised about Section 4.1. of
draft-ietf-isis-te-app) Per “Tampering with the information defined in this
document may have an effect on applications using it, including impacting
Traffic Engineering.”, I have no disagreement with this statement.  However, I
would recommend adding a brief statement what is the security impact of
“impacting Traffic Engineering”.

** Section 13.  Per "This is similar in nature to the impacts associated with
(for example) [RFC3630]", what specific text in RFC3630 was envisioned.  I
didn't follow the link.

---

From: Peter Psenak <[email-masked]>
Date: Thu, 11 Jun 2020 12:44:00 +0200

Hi Roman,

thanks for your comments, please see inline (##PP):

> https://datatracker.ietf.org/doc/draft-ietf-ospf-te-link-attr-reuse/

##PP
We did not limit the size at the beginning, but later due to limited
size of ISIS TLVs we limited it to 8 bytes to leave some space for the
attributes itself (draft-ietf-isis-te-app). We wanted to keep the
consistency between ISIS and OSPF which also helps BGP-LS. 8 octets
should be future-proof enough (64 apps).

We keep the byte for the SABM and UDABM lengths to avoid problems of
existing implementation.

> “impacting Traffic Engineering”.

##PP
TE is one of the applications using link attributes for selecting the 
explicit paths. Messing around with advertisement of the link attributes 
that TE uses may affect the TE path selection.

I modified as:

       "including impacting Traffic
        Engineering that uses various link attributes for its path
        computation."

Would that be good enough?

> (for example) [RFC3630]", what specific text in RFC3630 was envisioned.  I

Here's the text from the RFC3630:

   "However,
    tampering with TE LSAs may have an effect on traffic engineering
    computations, and it is suggested that any mechanisms used for
    securing the transmission of normal OSPF LSAs be applied equally to
    all Opaque LSAs, including the TE LSAs specified here"

thanks,
Peter