[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ms-ospf
Subject:    Re: [Lsr] Working Group Last Call for "OSPF Link Traffic Engineering (TE) Attribute Reuse" -
From:       "Acee Lindem (acee)" <acee () cisco ! com>
Date:       2019-04-18 16:03:47
Message-ID: 96F79575-3B1B-4DCF-83FF-22A5A88A3858 () cisco ! com
[Download RAW message or body]

Speaking as WG member... 

Right, there was a protracted WG discussion. IIRC, Olivier was opposed based on some \
code he had written for quagga using OSPF TE LSAs for purposes other than traditional \
RSVP TE. At the end of this discussion, we reached WG consensus with the \
understanding that some code would need to change. 

Thanks,
Acee


On 4/12/19, 10:50 AM, "Jeff Tantsura" <jefftant.ietf@gmail.com> wrote:

    Olivier,
    
    +1 Peter.
    There's has been significant amount of discussions on the topic some time ago, \
mostly with Chris Bowers. Please take a look, should provide more context.  
    Regards,
    Jeff
    
    > On Apr 12, 2019, at 15:27, Peter Psenak <ppsenak@cisco.com> wrote:
    > 
    > Hi Oliver,
    > 
    > There are two major purposes served by the drafts:
    > 
    > 1)Support of incongruent topologies for different applications
    > 
    > 2)Advertisement of application specific values even on links that are in
    > use by multiple applications
    > 
    > 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.
    > 
    > 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.
    > 
    > It is simply not possible to address these issues with the existing
    > single set of application independent advertisements.
    > 
    > 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
    > 
    >> On 11/04/2019 19:43 , 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
    >>> 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.
    >> 
    > 
    

_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


[prev in list] [next in list] [prev in thread] [next in thread]