Subject: Re: [OSPF] WG Adoption Poll for draft-ppsenak-ospf-te-link-attr-reuse

From: Chris Bowers <[email-masked]>
Date: Tue, 1 Nov 2016 16:04:55 +0000

OSPF WG,

I do not support adoption of draft-ppsenak-ospf-te-link-attr-reuse-03 as a WG document.  

The draft-ppsenak-ospf-te-link-attr-reuse has highlighted a real issue that needs to be addressed.  
OSPF does not have a standardized mechanism to determine if RSVP is enable on a link.  Implementations
have instead relied on the presence of the TE Opaque LSA with a given Link TLV to infer 
that RSVP is enabled on a link.  This presents a problem when one wants to use TE attributes carried
in the Link TLV of the TE Opaque LSA in an environment with both RSVP and non-RSVP applications.   There 
is currently no standardized way for a TE attribute to be advertised on a link for use by a non-RSVP application
without causing existing implementations to infer that RSVP is enabled on the link.  

The solution proposed by draft-ppsenak-ospf-te-link-attr-reuse is to allow the TE attributes originally
defined to be carried in the Link TLV of the TE Opaque LSA to be advertised in the Extended Link TLV of the
Extended Link Opaque LSA.  The current draft proposes allowing the advertisement of the following 
attributes in either the Link TLV of TE Opaque LSA or the Extended Link TLV of the Extended Link Opaque LSA.

Remote interface IP address
Link Local/Remote Identifiers
Shared Risk Link Group
Unidirectional Link Delay
Min/Max Unidirectional Link Delay
Unidirectional Delay Variation
Unidirectional Link Loss
Unidirectional Residual Bandwidth
Unidirectional Available Bandwidth
Unidirectional Utilized Bandwidth

There has already been a great deal of discussion on the OSPF list about the potential problems caused by
moving or replicating the advertisement of existing TE attributes in different containers.   It can create problems 
for both implementers and network operators when the same attribute can be advertised in multiple places. 
Implementers need to apply some logic to figure out where to advertise and where to find the value of the attribute 
that should be used in a given set of circumstances.  Different implementers may apply subtly different logic.  Network 
operators will have to test the different implementations against each other to make sure that the logic applied 
produces the desired result in their network.  In many cases, they will also have to test these different new implementations 
against existing software that only sends and receives TE attributes in the TE Opaque LSA.  

A few months ago we published draft-hegde-isis-advertising-te-protocols which addresses the same basic issue in ISIS.
The same approach also works for OSPF, so we recently published draft-hegde-ospf-advertising-te-protocols.  
draft-hegde-ospf-advertising-te-protocols-00 proposes a straightforward solution to the problem described above. 
It defines a new TE-protocol sub-TLV to be carried in the Link TLV of the TE Opaque LSA to indicate which 
TE protocols are enabled on a link.  Currently it defines values for RSVP and SR.  The draft also provides clear backward
compatibility mechanisms for routers that have not yet been upgraded to software that understands this new sub-TLV.

The approach in draft-hegde-ospf-advertising-te-protocols-00 is straightforward.  It leaves the existing TE
attributes in the TE Opaque LSA, allowing implementations to continue to advertise and find traffic engineering
the information in the TE Opaque LSA.

The latest version of draft-ppsenak-ospf-te-link-attr-reuse (the -03 version) added an Application Bit Mask.  The idea 
of the Application Bit Mask is to allow different values of TE attributes to be defined for different applications.
It is not clear to me that this part of the draft addresses an existing problem.  The text gives one example use
case involving having different sets of SRLGs for SR and for LFA.  If network operators do in fact have a need for 
different sets of SRLGs, then we should figure out what is needed and propose a solution based on what is actually
needed.  This draft would also provide encodings to advertise different Link Delay and Link Loss values for a given link.
I can't think of a potential use case for that, since Link Delay and Link Loss are measured values.

Overall, this draft has been useful in highlighting the existing lack of a standardized mechanism to indicate 
whether or not RSVP is enabled on a link.  However, I don't think that the solution it proposes is a good starting point 
for the WG to address this issue.

Chris

-----Original Message-----
From: OSPF [mailto:[email-masked]] On Behalf Of Abhay Roy
Sent: Wednesday, October 26, 2016 12:28 AM
To: [email-masked]; [email-masked]
Subject: [OSPF] WG Adoption Poll for draft-ppsenak-ospf-te-link-attr-reuse

Dear WG,

Authors of draft-ppsenak-ospf-te-link-attr-reuse would like to poll the WG for adoption of this document as a WG Draft. Please send your opinions / concerns.

This begins the two week WG adoption poll which will conclude on Nov 9th 2016.

Authors, we need your explicit response on this thread to capture your answer on if you are aware of any IPR related to this draft.

Regards,
-Abhay

_______________________________________________
OSPF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ospf

---

From: Peter Psenak <[email-masked]>
Date: Thu, 03 Nov 2016 11:53:26 +0100

Chris,

draft-hegde-ospf-advertising-te-protocols has following limitations:

1. only solves the problem of RSVP and Segment Routing TE. It does not 
address any other non-TE applications - e.g. LFA, SPF based on the delay 
or bandwidth, or anything that may come in the future.

2. it took the approach of "indicating the protocols enabled on the 
link". While this may be good for RSVP, it does not work for other 
applications. For example the fact that the LFA is enabled on a remote 
link is orthogonal to the fact whether the SRLG value on such link is 
going to be used by LFA calculation on other nodes in a network.

3. does not support per application values. You questioned the use case 
of SRLG. Well, we have a real use case, where operator runs RSVP TE and 
SRTE in parallel and wants to know bandwidth available for each.

You mentioned problems with advertising same attribute in multiple 
places. Well, we already do this today with metric, we advertise IGP 
metric in Router LSA and TE metric in TE Opaque LSA. There is no problem 
here, because each application knows where to look. RSVP TE has its own 
container and any data in this container are clearly RSVP TE specific. 
Rest of the applications should never look at these. RFC7684 defines the 
container for generic link attributes and that is what we should use for 
any non-RSVP applications.

When original RSVP TE extensions for IGPs were done, nobody was thinking 
about other applications using these link attributes. Today we clearly 
have use cases and now we need to address the lack of support for other 
applications.

The authors of the draft-ppsenak-ospf-te-link-attr-reuse draft strongly 
believe that as we make the link attributes available for other 
applications, it is the right time to add the support for per 
application values, so we do not need to come back and address that 
problem again in the future. The proposed encoding in the draft avoids 
any replication if there is a single value of the attribute used by 
all/several applications, while allowing the per application values to 
be advertised if needed.

In summary, draft-hegde-ospf-advertising-te-protocols only address the 
subset of the problems that draft-ppsenak-ospf-te-link-attr-reuse is 
solving.

thanks,
Peter

On 01/11/16 17:04 , Chris Bowers wrote:
> .

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 3 Nov 2016 16:53:05 +0000

Speaking as a WG member:

I agree with all the points Peter has made.  Furthermore, I’d like to
emphasis the fact that we standardized the OSPF Prefix/Link Attribute (RFC
7684) as
the generic attribute container. When applications such as segment routing
are deployed, we don’t want to also have to advertise OSPF TE LSAs in
addition to the OSPF Prefix/Link Attribute LSAs. In addition to the
advertisement overhead, having to track and correlate these multiple LSAs
will result in additional implementation complexity. Once we get
draft-ietf-ospf-ospfv3-lsa-extend implementations, we’ll have all the
non-TE link attributes in the E-Router-LSA. This is where we want to end
up 

Thanks,
Acee 

On 11/3/16, 6:53 AM, "Peter Psenak (ppsenak)" <[email-masked]> wrote:

>> defined to be carried in the Link TLV of the TE Opaque LSA to be
>>advertised in the Extended Link TLV of the
>> moving or replicating the advertisement of existing TE attributes in
>>different containers.   It can create problems
>> Implementers need to apply some logic to figure out where to advertise
>>and where to find the value of the attribute
>> that should be used in a given set of circumstances.  Different
>>implementers may apply subtly different logic.  Network
>> operators will have to test the different implementations against each
>>other to make sure that the logic applied
>> produces the desired result in their network.  In many cases, they will
>>also have to test these different new implementations
>> A few months ago we published draft-hegde-isis-advertising-te-protocols
>>which addresses the same basic issue in ISIS.
>> The same approach also works for OSPF, so we recently published
>>draft-hegde-ospf-advertising-te-protocols.
>> TE protocols are enabled on a link.  Currently it defines values for
>>RSVP and SR.  The draft also provides clear backward
>> compatibility mechanisms for routers that have not yet been upgraded to
>>software that understands this new sub-TLV.
>>
>> The approach in draft-hegde-ospf-advertising-te-protocols-00 is
>>straightforward.  It leaves the existing TE
>> attributes in the TE Opaque LSA, allowing implementations to continue
>>to advertise and find traffic engineering
>> The latest version of draft-ppsenak-ospf-te-link-attr-reuse (the -03
>>version) added an Application Bit Mask.  The idea
>> of the Application Bit Mask is to allow different values of TE
>>attributes to be defined for different applications.
>> case involving having different sets of SRLGs for SR and for LFA.  If
>>network operators do in fact have a need for
>> different sets of SRLGs, then we should figure out what is needed and
>>propose a solution based on what is actually
>> needed.  This draft would also provide encodings to advertise different
>>Link Delay and Link Loss values for a given link.
>> whether or not RSVP is enabled on a link.  However, I don't think that
>>the solution it proposes is a good starting point
>> Authors of draft-ppsenak-ospf-te-link-attr-reuse would like to poll the
>>WG for adoption of this document as a WG Draft. Please send your
>>opinions / concerns.
>>
>> Authors, we need your explicit response on this thread to capture your
>>answer on if you are aware of any IPR related to this draft.
>>
>> Regards,
>> -Abhay
>>

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 03 Nov 2016 10:48:08 -0700

Hi,

Some history to add on top of Peter’s, IMO absolutely correct comments. 
The issue is well known, we have had first discussions on the topic during the time rLFA was going thru standardization and implementation.
Back then however there was no clean and painless way to so. 

draft-ppsenak-ospf-te-link-attr-reuse addresses exactly the issue we have seen starting from the time TE seized to be the only application, however now, with the new extensions (7684) we have got much better and cleaner way. 
 
Cheers,
Jeff

---

From: Rob Shakir <[email-masked]>
Date: Thu, 03 Nov 2016 18:47:28 +0000

Hi OSPF chairs, Peter, Chris,

To add my opinion to this thread. The issue of having multiple places in
which one might advertise TE related information is one that I think there
can be multiple takes on. Particularly, whilst I can see that there is an
argument that duplication of such attributes might result in ambiguity in
which is used, we must also consider what happens when the TE information
for one protocol does not apply for others that are running within the same
network. This is particularly important during the period where there is
coexistence of multiple protocols on the device. In order to explicitly
allow the operator to choose how resources might be partitioned on the
network, then to me it seems like we need more than simply "is this link
eligible to carry TE paths that are signalled via protocol X".

As well as resource partitioning (e.g., subsets of bandwidth being
available per application for example), there appear to me to be potential
use cases where the administrative groups across the protocols may differ,
when a subset of links are eligible for a particular protocol's paths and
not another's. Not being able to do this scoping makes the difficult
problem of coexistence even more difficult, so having the flexibility to
tag particular attributes for links based on application seems
(generically) to be more useful than the simple ability of partitioning the
network link-by-link that is proposed in draft-hegde-ospf-advertising-t
e-protocols-00.

Operationally - yes - if one specifies metrics in multiple places this
might have some ambiguity, however, we have many years of experience of
such a scenario - where TE metric might make RSVP-TE act differently in
terms of path selection than the base IGP metric. Those networks that do
not derive benefit from the additional attributes will simply not set them,
or make their value exactly mirrored between the different protocols that
they run. Those that do have benefit will have the flexibility to utilise
them, but have to deal with the additional operational overhead that comes
with it.

I would prefer that we adopt the more flexible approach (this draft), and
then work out the implementation and operational complexities that might be
introduced, than to adopt an approach which leaves us with few
extensibility options going forward.

Cheers,
r.

On Thu, Nov 3, 2016 at 10:48 AM Jeff Tantsura <[email-masked]>
wrote:

> The issue is well known, we have had first discussions on the topic during
> the time rLFA was going thru standardization and implementation.
> draft-ppsenak-ospf-te-link-attr-reuse addresses exactly the issue we have
> seen starting from the time TE seized to be the only application, however
> now, with the new extensions (7684) we have got much better and cleaner way.
>
> Cheers,
> Jeff
>
>
>     >> I do not support adoption of
> draft-ppsenak-ospf-te-link-attr-reuse-03
>     >>as a WG document.
>     >>
>     >> The draft-ppsenak-ospf-te-link-attr-reuse has highlighted a real
> issue
>     >>that needs to be addressed.
>     >> have instead relied on the presence of the TE Opaque LSA with a
> given
>     >>Link TLV to infer
>     >> that RSVP is enabled on a link.  This presents a problem when one
> wants
>     >>to use TE attributes carried
>     >> in the Link TLV of the TE Opaque LSA in an environment with both
> RSVP
>     >>and non-RSVP applications.   There
>     >> is currently no standardized way for a TE attribute to be
> advertised on
>     >>a link for use by a non-RSVP application
>     >> without causing existing implementations to infer that RSVP is
> enabled
>     >>on the link.
>     >>
>     >> attributes in either the Link TLV of TE Opaque LSA or the Extended
> Link
>     >>TLV of the Extended Link Opaque LSA.
>     >>
>     >> for both implementers and network operators when the same attribute
> can
>     >>be advertised in multiple places.
>     >> against existing software that only sends and receives TE
> attributes in
>     >>the TE Opaque LSA.
>     >>
>     >> A few months ago we published
> draft-hegde-isis-advertising-te-protocols
>     >> draft-hegde-ospf-advertising-te-protocols-00 proposes a
> straightforward
>     >>solution to the problem described above.
>     >> It defines a new TE-protocol sub-TLV to be carried in the Link TLV
> of
>     >>the TE Opaque LSA to indicate which
>     >> It is not clear to me that this part of the draft addresses an
> existing
>     >>problem.  The text gives one example use
>     >> Overall, this draft has been useful in highlighting the existing
> lack
>     >>of a standardized mechanism to indicate
>     >> To: [email-masked];
> [email-masked]

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 3 Nov 2016 20:11:15 +0000

Folks –

I am adding the IS-IS WG to this thread because the issues discussed below apply equally to IS-IS.

There is currently one draft in IS-IS: https://www.ietf.org/id/draft-hegde-isis-advertising-te-protocols-01.txt which has the same shortcomings as its OSPF counterpart:  https://www.ietf.org/id/draft-hegde-ospf-advertising-te-protocols-00.txt

It is essential that the two IGPs provide equivalent functionality. We therefore need a draft in IS-IS that defines functionality equivalent to that defined in https://www.ietf.org/id/draft-ppsenak-ospf-te-link-attr-reuse-03.txt.

It is my intention to help write such a draft.

   Les

From: Rob Shakir [mailto:[email-masked]]
Sent: Thursday, November 03, 2016 11:47 AM
To: Jeff Tantsura; Peter Psenak (ppsenak); Chris Bowers; [email-masked]
Cc: [email-masked]
Subject: Re: [OSPF] WG Adoption Poll for draft-ppsenak-ospf-te-link-attr-reuse

To add my opinion to this thread. The issue of having multiple places in which one might advertise TE related information is one that I think there can be multiple takes on. Particularly, whilst I can see that there is an argument that duplication of such attributes might result in ambiguity in which is used, we must also consider what happens when the TE information for one protocol does not apply for others that are running within the same network. This is particularly important during the period where there is coexistence of multiple protocols on the device. In order to explicitly allow the operator to choose how resources might be partitioned on the network, then to me it seems like we need more than simply "is this link eligible to carry TE paths that are signalled via protocol X".

As well as resource partitioning (e.g., subsets of bandwidth being available per application for example), there appear to me to be potential use cases where the administrative groups across the protocols may differ, when a subset of links are eligible for a particular protocol's paths and not another's. Not being able to do this scoping makes the difficult problem of coexistence even more difficult, so having the flexibility to tag particular attributes for links based on application seems (generically) to be more useful than the simple ability of partitioning the network link-by-link that is proposed in draft-hegde-ospf-advertising-te-protocols-00.

Operationally - yes - if one specifies metrics in multiple places this might have some ambiguity, however, we have many years of experience of such a scenario - where TE metric might make RSVP-TE act differently in terms of path selection than the base IGP metric. Those networks that do not derive benefit from the additional attributes will simply not set them, or make their value exactly mirrored between the different protocols that they run. Those that do have benefit will have the flexibility to utilise them, but have to deal with the additional operational overhead that comes with it.

I would prefer that we adopt the more flexible approach (this draft), and then work out the implementation and operational complexities that might be introduced, than to adopt an approach which leaves us with few extensibility options going forward.

Cheers,
r.

On Thu, Nov 3, 2016 at 10:48 AM Jeff Tantsura <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Cheers,
Jeff

    On 11/3/16, 6:53 AM, "Peter Psenak (ppsenak)" <[email-masked]<mailto:[email-masked]>> wrote:

    >> From: OSPF [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Abhay Roy
    >> To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
    >> [email-masked]<mailto:[email-masked]>
    >> [email-masked]<mailto:[email-masked]>

    _______________________________________________
    OSPF mailing list
    [email-masked]<mailto:[email-masked]>
    https://www.ietf.org/mailman/listinfo/ospf

_______________________________________________
OSPF mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ospf

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 3 Nov 2016 14:32:23 -0700

It is my intention too.

Regards,
Jeff

> On Nov 3, 2016, at 13:11, Les Ginsberg (ginsberg) <[email-masked]> wrote:
> 
> Folks –
>  
> On Thu, Nov 3, 2016 at 10:48 AM Jeff Tantsura <[email-masked]> wrote:
> Hi,
>

---

From: Shraddha Hegde <[email-masked]>
Date: Fri, 4 Nov 2016 05:01:52 +0000

OSPF WG,

draft-ppsenak-ospf-te-link-attr-reuse  describes a problem statement that is relevant for non-RSVP applications that
need to look into the TE attributes. 
I do not support the adoption of this draft as the solution described in the draft has below problems.

1. The solution proposes to move/duplicate the TE attributes in multiple containers within OSPF.
     Having multiple places to hold the same attributes leads to complexity in terms of 
        >  Having to look at both containers.
       >  Having to provide config interfaces for the operator to define which container to advertise the attributes and
           Operational complexity having to manage these configurations
       >  Inter-op issues due to inconsistency in implementations
       > Backward compatibility has to be maintained, so the looking-up multiple LSAs for the TE attributes does not go away
          By implementing draft-ppsenak-ospf-te-link-attr-reuse
       >  From experience, it is seen that older devices which cannot be upgraded, exist in the network for a very long time
            Which means the TE attributes need to be advertised in both TE LSA and Extended LINK LSA forever.

2.  Section 5 of the draft describes " Advertisement of Application Specific Values" and provides example of SRLG values that are specific to applications.
      The existing SRLG definition is generic enough to solve the said problem described in the draft by assigning different SRLG values to a link
      corresponding to each application and having the application look for values that are specific to that application. 
       The extended TE metric  vales are specific to links and it is not clear in what scenario and use-case it would make sense to advertise
        Per-application specific values for the attributes described in section 5.
       Without clear use-case and scenarios, there is always a risk of producing implementations that are not inter-operable.

Rgds
Shraddha

-----Original Message-----
From: OSPF [mailto:[email-masked]] On Behalf Of Abhay Roy
Sent: Wednesday, October 26, 2016 10:58 AM
To: [email-masked]; [email-masked]
Subject: [OSPF] WG Adoption Poll for draft-ppsenak-ospf-te-link-attr-reuse

Dear WG,

Regards,
-Abhay

---

From: <[email-masked]>
Date: Fri, 4 Nov 2016 15:48:32 +0000

Hi all,

> It is essential that the two IGPs provide equivalent functionality.
+1

> We therefore need a draft in IS-IS that defines functionality equivalent to that defined in https://www.ietf.org/id/draft-ppsenak-ospf-te-link-attr-reuse-03.txt.

Another consequence could be a need for the ospf WG to wait for the ISIS wg to have the equivalent document published, presented and discussed, before making a decision. Otherwise, I’m not sure how we could unsure the same decision in both wg.

Regards,
--Bruno

From: OSPF [mailto:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Thursday, November 03, 2016 9:11 PM
To: Rob Shakir; Jeff Tantsura; Peter Psenak (ppsenak); Chris Bowers; [email-masked]; [email-masked] list ([email-masked])
Cc: [email-masked]
Subject: Re: [OSPF] WG Adoption Poll for draft-ppsenak-ospf-te-link-attr-reuse

Folks –

   Les

From: Rob Shakir [mailto:[email-masked]]
Sent: Thursday, November 03, 2016 11:47 AM
To: Jeff Tantsura; Peter Psenak (ppsenak); Chris Bowers; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [OSPF] WG Adoption Poll for draft-ppsenak-ospf-te-link-attr-reuse

Cheers,
r.

Cheers,
Jeff

_________________________________________________________________________________________________________________________

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.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 5 Nov 2016 16:17:42 +0000

Speaking as WG participant:

Hi Shraddha, 

On 11/4/16, 1:01 AM, "OSPF on behalf of Shraddha Hegde"
<[email-masked] on behalf of [email-masked]> wrote:

>OSPF WG,
>
>
>draft-ppsenak-ospf-te-link-attr-reuse  describes a problem statement that
>is relevant for non-RSVP applications that
>       >  Having to provide config interfaces for the operator to define
>which container to advertise the attributes and

At least we agree on the basic principle that fewer LSAs is better.
However, what you are proposing will force OSPF routers for non-TE
applications to advertise and access the attributes in 3 OSPFv2 LSAs
(Router-LSA, TE Opaque LSA, Prefix/Link Attribute LSA) rather than 2
(Router-LSA, Prefix/Link Attribute LSA). With OSPFv3 Extended LSAs, we
have the potential to get to a single Extended-Router-LSA for all the
attributes. 

>       > Backward compatibility has to be maintained, so the looking-up
>multiple LSAs for the TE attributes does not go away
>       >  From experience, it is seen that older devices which cannot be
>upgraded, exist in the network for a very long time

I have sincere empathy for your backward compatibility problem. However,
it appears that yours is the only implementation with this problem and
many others have the problem of including OSPF links with TE LSAs in the
RSVP TE topology. I know you have attempted to solve this issue for
everyone with 
https://www.ietf.org/id/draft-hegde-ospf-advertising-te-protocols-00.txt.
However, the outcome would be that we have more LSAs to advertise and
correlate than with the OSPF Prefix/Link Attribute approach and we both
agree that fewer LSAs are better.

What is the extent of the backward compatibility problem, is it beyond the
SRLG TLV standardized for Generalized Multi-Protocol Label Switching
(GMPLS) in RFC 4203?

>
>2.  Section 5 of the draft describes " Advertisement of Application
>Specific Values" and provides example of SRLG values that are specific to
>applications.
>      The existing SRLG definition is generic enough to solve the said
>problem described in the draft by assigning different SRLG values to a
>link
>      corresponding to each application and having the application look
>for values that are specific to that application.

Again, this requires more LSAs. I thought we agreed that fewer are better.

Thanks,
Acee 

> 
>       The extended TE metric  vales are specific to links and it is not
>clear in what scenario and use-case it would make sense to advertise
>       Without clear use-case and scenarios, there is always a risk of
>producing implementations that are not inter-operable.

>WG for adoption of this document as a WG Draft. Please send your opinions
>/ concerns.
>

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 7 Nov 2016 00:40:14 +0000

I have read this draft and think it's useful. Therefore, I support the WG adoption of this draft.

Xiaohu

> -----邮件原件-----
> 发件人: OSPF [mailto:[email-masked]] 代表 Abhay Roy
> 发送时间: 2016年10月26日 13:28
> 收件人: [email-masked]; [email-masked]
> 主题: [OSPF] WG Adoption Poll for draft-ppsenak-ospf-te-link-attr-reuse
> 
> Dear WG,
> 
> Authors of draft-ppsenak-ospf-te-link-attr-reuse would like to poll the WG for
> adoption of this document as a WG Draft. Please send your opinions / concerns.
> 
> Authors, we need your explicit response on this thread to capture your answer
> on if you are aware of any IPR related to this draft.
> 
> Regards,
> -Abhay
>

---

From: Huaimo Chen <[email-masked]>
Date: Tue, 8 Nov 2016 00:04:11 +0000

I read the draft and support its adoption.

Best Regards,
Huaimo