Subject: [Lsr] Deborah Brungard's Discuss on draft-ietf-ospf-te-link-attr-reuse-14: (with DISCUSS and COMMENT)

From: Deborah Brungard via Datatracker <[email-masked]>
Date: Wed, 10 Jun 2020 14:57:24 -0700

Deborah Brungard has entered the following ballot position for
draft-ietf-ospf-te-link-attr-reuse-14: Discuss

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/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This should be simple to resolve - the use of the SR-TE term is
out-of-alignment with other drafts, spring and idr. Suggest: Segment Routing
Traffic Engineering/s/Segment Routing Policy and SRTE/s/SR Policy.

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

As Warren noted, the draft is very difficult to read.

This doesn't parse:
"As soon as the router that is an RSVP-TE head-end sees the link attribute being
   advertised for that link, it assumes RSVP-TE is enabled on that link,
   even though it is not.  If such RSVP-TE head-end router tries to
   setup an RSVP-TE path via that link it will result in the path setup
   failure."
It seems there is the assumption the link is congruent with the signaling
(maybe some implementations do but not per spec). Maybe this is needed by some
implementations, but the draft seems to make it a "general problem".

But I don't think this is really the intention of the draft - even section 4.1
says duplication would be only in "rare cases". The specific problem (to me) is
the ability to support advertisement of application specific values? And, to
say, new applications MUST NOT make use of RSVP-TE LSA advertisements which is
causing confusion for (some) implementations. It would help to make this more
clearer and not muddy with implementation woes.

I don't see any discussion on the dark bandwidth problem or the security
problems identified in RFC8426? It would be helpful if the draft pointed to the
RFC8426 solution.

---

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

Hi Deborah,

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

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

##PP
It is a general problem. RSVP-TE and IGP topologies do not need to be 
congruent. All major vendors' implementation derive the link 
participation in the RSVP-TE topology from the presence of the RSVP-TE 
link attributes. So this is one of the two problems this draft solves.

> the ability to support advertisement of application specific values? 

##PP
that is the second problem that the draft is addressing.

> And, to

##PP
I don't know how to make it any more clear. There is an existing text in 
the draft:

    In recent years new applications have been introduced which have use
    cases for many of the link attributes historically used by RSVP-TE.
    Such applications include Segment Routing Traffic Engineering (SRTE)
    [I-D.ietf-spring-segment-routing-policy] and Loop Free Alternates
    (LFA) [RFC5286].  This has introduced ambiguity in that if a
    deployment includes a mix of RSVP-TE support and SRTE support (for
    example) it is not possible to unambiguously indicate which
    advertisements are to be used by RSVP-TE and which advertisements are
    to be used by SRTE.  If the topologies are fully congruent this may
    not be an issue, but any incongruence leads to ambiguity.

    An example where this ambiguity causes a problem is a network in
    which RSVP-TE is enabled only on a subset of its links.  A link
    attribute is advertised for the purpose of another application (e.g.
    SRTE) for a link that is not enabled for RSV-TE.  As soon as the
    router that is an RSVP-TE head-end sees the link attribute being
    advertised for that link, it assumes RSVP-TE is enabled on that link,
    even though it is not.  If such RSVP-TE head-end router tries to
    setup an RSVP-TE path via that link it will result in the path setup
    failure.

    An additional issue arises in cases where both applications are
    supported on a link but the link attribute values associated with
    each application differ.  Current advertisements do not support
    advertising application specific values for the same attribute on a
    specific link.

    This document defines extensions which address these issues.

If above is not sufficient, please suggest a text that would make it clear.

> problems identified in RFC8426? It would be helpful if the draft pointed to the

##PP
how is RFC8426 relevant in the context of this draft?

thanks,
Peter

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Thu, 11 Jun 2020 12:00:54 +0000

Hi Peter,

Thanks - in-line-
Deborah

-----Original Message-----
From: Peter Psenak <[email-masked]> 
Sent: Thursday, June 11, 2020 7:00 AM
To: BRUNGARD, DEBORAH A <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Acee Lindem <[email-masked]>; Yingzhen Qu <[email-masked]>; [email-masked]
Subject: Re: Deborah Brungard's Discuss on draft-ietf-ospf-te-link-attr-reuse-14: (with DISCUSS and COMMENT)

Hi Deborah,

##PP
It is a general problem. RSVP-TE and IGP topologies do not need to be 
congruent. All major vendors' implementation derive the link 
participation in the RSVP-TE topology from the presence of the RSVP-TE 
link attributes. So this is one of the two problems this draft solves.
##DB
That's too bad - sad. But as you say it is an implementation problem - that's my concern on having these sentences in this document - we will be giving visibility to it as if it is a "BCP". I think this needs to be prefaced as "Some implementations". As I said, I find this confusing and detracts from the (hopefully) main aim of the document. I'll redo my Discuss to add this qualifier as I do think we need to accurately say this is an implementation problem.
##PP
how is RFC8426 relevant in the context of this draft?
##DB
Advertising bandwidth per an application will not solve the "big problem" - dark bandwidth accounting. While not part of the advertisement, as we already have an RFC on it, it would be helpful to our user community to point to it.

thanks,
Peter

---

From: Peter Psenak <[email-masked]>
Date: Thu, 11 Jun 2020 14:31:01 +0200

Deborah,

please see inline (##PP)

> That's too bad - sad. But as you say it is an implementation problem - that's my concern on having these sentences in this document - we will be giving visibility to it as if it is a "BCP". I think…

##PP
it is not the implementation problem.

There is no standardized way to derive the RSVP-TE traffic engineering 
topology.

For example, RFC3630 says:

   "The extensions provide a way of describing the traffic engineering
    topology (including bandwidth and administrative constraints) and
    distributing this information within a given OSPF area.  This
    topology does not necessarily match the regular routed topology,"

but it does not provide any mechanism how the traffic engineering 
topology is derived. So we have a problem, where implementations picked 
a method to fill the void in the specification.

> Advertising bandwidth per an application will not solve the "big problem" - dark bandwidth accounting. While not part of the advertisement, as we already have an RFC on it, it would be helpful to o…

##PP
we are not trying to solve the "dark bandwidth accounting", so I see no 
relevance between this draft and RFC8426.

thanks,
Peter

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