Re: [Lsr] Working Group Last Call for "OSPF Link Traffic Engineering (TE) Attribute Reuse" - draft-ietf-ospf-te-link-attr-reuse-07.txt

Hi Olivier,

On 02/05/2019 15:33 , olivier.dugeon@orange.com wrote:
> Hi Les,
>
>
> Le 13/04/2019 à 16:52, Les Ginsberg (ginsberg) a écrit :
>>
>> Olivier –
>>
>>
>>
>> As Jeff has indicated in his reply, the use cases and issues around
>> these protocol extensions have been discussed extensively on the WG
>> lists (including of course the now subsumed OSPS/IS-IS WG lists) and
>> were the subject of many presentations at many IETFs. The history of
>> these drafts dates back as far as July of 2015 when the initial
>> version of the OSPF draft was published
>> (https://datatracker.ietf.org/doc/draft-ppsenak-ospf-te-link-attr-reuse/00/
>> ). You have been a participant in this conversation as a search
>> through the mailing list archives will confirm. If you have forgotten
>> aspects of this discussion I encourage you to review the proceedings
>> of previous IETF meetings. There are many useful presentations available.
>>
>>
>>
>> I don’t think it serves this thread to attempt to rehash or summarize
>> those extensive discussions. Neither does it help for you to respond
>> as if none of these discussions took place and that there is no
>> problem to be solved. If you are going to comment on the drafts I
>> think you have a responsibility to familiarize yourself with the work
>> that has gone on for the past few years.
>>
>
> My intention was not to rehash the discussions. I just answer to the WG
> last call. Looking to the draft, I consider that section 1 & 2 are not
> sufficiently detail how this modifications are required. Or, if you
> prefer, the justification, detailing precise case where it is not
> possible to use actual TE link parameters. And, preferably, not just
> speaking about "incongruent network topology", but given details.
>
> Then, as already mention,but not take into account, TE link attributes
> are orthogonal to services and protocols.

I don't agree with the above statement. Some link attributes may have 
app specific values and that is one of the use cases being addressed  by 
this draft.

> Duplicate them to just add
> indication on who is using it, or who could used it, will brings into
> complexity as we will need to maintain both system old and new, during a
> long period.

we want multiple different values of link attribute to be advertised. 
That is not a duplication.

thanks,
Peter

>
>>
>>
>> A bit more Inline.
>>
>>
>>
>> *From:*olivier.dugeon@orange.com <olivier.dugeon@orange.com>
>> *Sent:* Friday, April 12, 2019 7:26 AM
>> *To:* Peter Psenak (ppsenak) <ppsenak@cisco.com>; Acee Lindem (acee)
>> <acee@cisco.com>; lsr@ietf.org
>> *Cc:* draft-ietf-ospf-te-link-attr-reuse@ietf.org
>> *Subject:* Re: [Lsr] Working Group Last Call for "OSPF Link Traffic
>> Engineering (TE) Attribute Reuse" -
>> draft-ietf-ospf-te-link-attr-reuse-07.txt
>>
>>
>>
>> Hello Peter,
>>
>>
>>
>> Le 12/04/2019 à 15:27, Peter Psenak a écrit :
>>
>>     Hi Oliver,
>>
>>     There are two major purposes served by the drafts:
>>
>>     1)Support of incongruent topologies for different applications
>>
>> Don't understand. What do you mean ?
>>
>> */[Les:] A simple example suffices. Consider the topology:/*
>>
>> */ /*
>>
>> */        B/*
>>
>> */     /    \/*
>>
>> */   A ------C/*
>>
>> */     \   //*
>>
>> */       D/*
>>
>> */ /*
>>
>> Suppose I want to use links A-B, B-C for RSVP-TE and Links A-D, D-C
>> for SRTE.
>>
>> And Link A-C I want to use for both applications.
>>
>>
>>
>> Absent the extensions in these drafts, there is no way with current
>> protocol machinery to support this. Both applications will see all
>> links as “enabled for TE”.
>>
>> And (to address one of your questions below) it isn’t just a matter of
>> assigning separate affinities for each application. Simply advertising
>> TE attributes (for example bandwidth) on a link signals to existing
>> RSVP-TE applications that a link is enabled for TE use.
>>
>>
>>
>> Again, alternative solutions to this problem were discussed
>> extensively on the list and in WG meetings – and the WG eventually
>> adopted these drafts.
>>
> Do you really think that operators manage their networks like that?
> especially at a large scale (I mean > 1000 routers & 10000 links).
> Enabling TE on routers is already too complex to have fun specializing
> some links for RSVP-TE and others for SR. In the same idea, for me, it's
> like enabling DiffServ and flows prioritizing on a subset of interfaces
> while leaving the other interfaces in Best-Effort mode.
>
> Olivier
>
>>
>>
>>    Les
>>
>>
>>
>>
>>     2)Advertisement of application specific values even on links that
>>     are in
>>     use by multiple applications
>>
>> Hum. Do you think it makes sense to announce different TE metric for
>> the same link for different applications ? e.g. 10 ms delay for
>> RSVP-TE, 20 ms for SR, 15 ms for LFA and 5 ms for Flex -Algo ? The
>> link has a fix delay propagation whatever the application.
>>
>> If the goal is to dedicated link per application, Resource Class/Color
>> attribute could be used. If you would advertised different metric per
>> CoS, then you need to dedicated metric per CoS like the unreserved
>> bandwidth.
>>
>>
>>     These issues are clearly articulated in the Introductions of both
>>     drafts. LSR WG acknowledged them a while back and decided to address
>>     them.
>>
>>     Issue #1 has already had a significant impact on early deployments of
>>     SRTE in networks where there is partial deployment of SR in the
>>     presence
>>     of RSVP-TE.
>>
>> Can you point me a concrete and detail example of the problem ? With a
>> PCE, there is no problem to manage both RSVP-TE and SR-TE in the same
>> network. And again, as already mention, if the problem come from
>> bandwidth reservation, the draft will not solve the issue.
>>
>>
>>     Issue #2 will be seen in deployments where Flex-Algo and SRTE (or
>>     RSVP-TE) are also present. Early implementers of Flex-Algo can
>>     attest to
>>     this.
>>
>> Again, I don't see the problem. Can you explain in detail ? I already
>> implement SR in OSPF, starting playing with TE, and there is no
>> problem to get TE information from OSPF to tune some Segment Path. If
>> it is an implementation issue, it is not a new RFC that will solve the
>> problem.
>>
>>
>>     It is simply not possible to address these issues with the existing
>>     single set of application independent advertisements.
>>
>> Why ? Again, explain in detail. I don't see a real use case that could
>> not be address with standard TE attributes.
>>
>>
>>     The solutions we provide in both drafts allow to share the link
>>     attributes between application as well as keep them separate if
>>     that is
>>     what is required.
>>
>>     thanks,
>>     Peter
>>
>>
>> Regards
>>
>> Olivier
>>
>>
>>
>>     On 11/04/2019 19:43 , olivier.dugeon@orange.com
>>     <mailto:olivier.dugeon@orange.com> wrote:
>>
>>         Hi,
>>
>>         I'm not in favour of this draft.
>>
>>         As already mention, I don't see the interest to duplicate TE
>>         attributes
>>         in new Extended Link Opaque LSA. For me, it is only a matter of
>>         implementation to look at various place in the OSPF TE
>>         Database to take
>>         Traffic Engineering information.
>>
>>         From an operator perspective, it is already hard to manage TE
>>         attribute
>>         and I'm pretty sure that we could not ask network management
>>         team to
>>         maintain 2 systems for certainly a long period of time as many TE
>>         attributes remains in the standard Opaque LSA Traffic
>>         Engineering.
>>
>>         Regards
>>
>>         Olivier
>>
>>
>>         Le 11/04/2019 à 18:11, Acee Lindem (acee) a écrit :
>>
>>
>>              LSR Working Group,
>>
>>
>>
>>             This begins a two week  WG last call for the subject
>>             document. Please
>>             enter your support or objection to the document before
>>             12:00 AM (EDT)
>>             on Friday, April 27^th , 2019.
>>
>>
>>
>>             Thanks,
>>             Acee
>>
>>
>>
>>
>>
>>
>>
>>             _______________________________________________
>>             Lsr mailing list
>>             Lsr@ietf.org <mailto:Lsr@ietf.org>
>>             https://www.ietf.org/mailman/listinfo/lsr
>>
>>
>>         _________________________________________________________________________________________________________________________
>>
>>
>>         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.
>>
>>
>>
>>
>>
>> _________________________________________________________________________________________________________________________
>>
>> 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.
>
> _________________________________________________________________________________________________________________________
>
> 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.
>