Re: [Teas] Benjamin Kaduk's No Objection on draft-ietf-teas-sr-rsvp-coexistence-rec-03: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

On Wed, May 16, 2018 at 06:03:45PM +0000, Harish Sitaraman wrote:
> 
> Hi Benjamin,
> 
> Thanks for your comments. See inline [HS]...
> 
> On 5/9/18, 11:29 AM, "Benjamin Kaduk" <[e-mail]> wrote:
> 
>     Benjamin Kaduk has entered the following ballot position for
>     draft-ietf-teas-sr-rsvp-coexistence-rec-03: 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CXKOXD_3UIPrRhmyXS8lTOnJ2ZY8S-bng806Yu9IBa0&m=_tLKZKFvpi0prUcbEb71howrp22CMZWd7Z90brs1b30&s=ax9fC-mTvSYj0Z7VznTX_3stX3oy242dhwVDWyL9blk&e=
>     for more information about IESG DISCUSS and COMMENT positions.
>     
>     
>     The document, along with other ballot positions, can be found here:
>     https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dteas-2Dsr-2Drsvp-2Dcoexistence-2Drec_&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CXKOXD_3UIPrRhmyXS8lTOnJ2ZY8S-bng806Yu9IBa0&m=_tLKZKFvpi0prUcbEb71howrp22CMZWd7Z90brs1b30&s=TzqnOj98uGBD0O8eSxeHBvB-OhwazjQBmex5fSuN0Ew&e=
>     
>     
>     
>     ----------------------------------------------------------------------
>     COMMENT:
>     ----------------------------------------------------------------------
>     
>     TED/its expansion should be introduced in the Introduction, not the
>     Abstract, since the Abstract and the rest of the document must be
>     able to be read in a standalone manner.
> 
> [HS] Ok - we can retain " traffic engineering database" and remove "(TED)" in the abstract and move it to the Introduction.
>     
>     In line with Alvaro's comment, I would suggest moving Sections 3.1
>     through 3.4 into a new parent section "Discarded Options" or
>     similarly-named.
>     
> [HS] The solutions are not discarded and it is left to the operator's choice even though a solution may not satisfy all the requirements. 
>         I had responded to Alvaro's comment and proposed adding some text in section 3 (before 3.1) to clarify this.

Indeed, I did not look at other IESG ballots before entering mine,
and should have left this topic to Alvaro's ballot.

>     Section 3.5
>     
>        [...] It is RECOMMENDED that the IGP-TE update
>        threshold SHOULD be lower in order to flood unreserved bandwidth
>        updates often.
>     
>     Lower than what?
>     
> [HS] Vendors may offer the ability for the operator to decide how often (as a %/value of change) to flood changes to available bandwidth and unreserved bandwidth for a TE link. As part of Alvaro's comments, we are removing RECOMMENDED. We could further change the above to "The IGP-TE update threshold SHOULD allow for more frequent flooding of unreserved bandwidth".

The further proposed change seems helpful to me; otherwise I would
suggest using "relatively low" instead of just "lower", since
"lower" implies a comparison with some fixed known value, and
"relatively low" implies to use the lower end of a known range.

>     Section 7
>     
>     It feels odd to say that these "do not require any new security
>     considerations" and then go and list some new security
>     considerations.  I would suggest something like "The security
>     considerations of each protocol are unaffected by the presence of
>     the other, so only the interactions of the TED consistency solution
>     with the individual protocols needs to be considered."
>     
>     I would probably also want to expand the text a bit, noting that:
>     
>     A hijacked SR traffic stream could potentially cause disruption to
>     RSVP-TE LSPs in two ways: directly, but consuming sufficient
>     bandwidth to cause traffic loss, and indirectly, by consuming
>     sufficient traffic to result in the TED consistency solution
>     proposed in this document reducing the bandwidth available to
>     RSVP-TE paths.  The former is possible whenever RSVP-TE and SR
>     traffic share links, independently of whether this specification is
>     in use; the latter is new behavior with this specifciation but is
>     seen as preferrable to the alternative, since the impact to RSVP-TE
>     traffic can be controlled and paths re-routed.  However, some latent
>     risk of disruption remains because this specification is a reactive
>     protcol, relying on taking measurements and only adopting to new
>     traffic flows after the measurement period.  The finite duration of
>     the measurement window leaves open a period of potential disruption
>     before remediation can be applied.
>  
> [HS] Thanks for the suggestion. We can update the security section to the following:
> [HS]
>    This document describes solution options for the co-existence of
>    RSVP-TE and SR LSPs in the same administrative domain.  The security
>    considerations for SR are described in
>    [I-D.ietf-spring-segment-routing].  The security considerations
>    pertaining to RSVP-TE are described in [RFC5920].  The security
>    considerations of each architecture are typically unaffected by the
>    presence of the other.  However, when RSVP-TE and SR LSPs co-exist,
>    it is possible for a hijacked SR traffic stream to maliciously
>    consume sufficient bandwidth and cause disruption to RSVP-TE LSPs.

"sufficient" is another word that implies a comparison to something
else (a threshold value), but I don't know what value that is
supposed to be here.

>    With the solution option specified in Section 3.5, the impact to
>    RSVP-TE traffic can be controlled and paths re-routed.  Some latent
>    risk of disruption still remains because this solution option relies
>    on taking statistics samples and adopting to new traffic flows only after
>    the adjustment period.  The defensive mechanisms
>    described in the base SR security framework should be employed to
>    guard against situations that result in SR traffic hijacking or
>    denial of service.    
> [HS]

But other than the above note, your proposed text is a big
improvement, thanks!

>     This guidance seems like it could be (very) roughly characterized as
>     "these are the ranges of values that are not insane to use".  Is it
>     possible to give more precise/active guidance, such as (taking a
>     wild guess) "Values between 0.9 and 1.1 allow for taking accunt of
>     estimated future traffic growth during the current measurement
>     period while reducing the risk of leaving large amounts of bandwidth
>     underutilized.  The measurement period should be smaller than a
>     minute in order for this tight of a growth window to make sense."
> 
> [HS] M is used to multiply SR traffic average at the adjustment period (N) and to update the maximum-reservable-bandwidth to over-state/under-state the actual availability. I'm not sure we can offer better guidance than to explain the effects of M < 1 and M > 1 and that choice is up to the operator, where the default of 1 is to not under/over-state.

Okay.  Perhaps if there is ever a -bis of this document there will
be more deployment experience and more guidance can be provided at
that time.

Thanks,

Benjamin