Subject: [OSPF] WG adoption poll for draft-ppsenak-ospf-te-link-attr-reuse

From: Abhay Roy <[email-masked]>
Date: Mon, 3 Jul 2017 11:37:26 -0700

We would like to kick-off a poll for WG adoption of the following document (per Authors request):

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

Please let us know if you support or have concerns with OSPF WG adopting this work.

Regards,
-Abhay

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 03 Jul 2017 12:23:23 -0700

support as co-author 
 
Cheers,
Jeff

On 7/3/17, 11:37, "OSPF on behalf of Abhay Roy" <[email-masked] on behalf of [email-masked]> wrote:

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

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Tue, 4 Jul 2017 03:29:36 +0000

Support the adoption

-----Original Message-----
From: OSPF [mailto:[email-masked]] On Behalf Of Abhay Roy (akr)
Sent: 04 July 2017 00:07
To: [email-masked]
Subject: [OSPF] WG adoption poll for draft-ppsenak-ospf-te-link-attr-reuse

Regards,
-Abhay

---

From: Peter Psenak <[email-masked]>
Date: Tue, 04 Jul 2017 10:38:30 +0200

Support as co-author.

thanks,
Peter

On 03/07/17 20:37 , Abhay Roy wrote:
> .

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 5 Jul 2017 15:05:55 +0000

Support as co-author.

   Les

> Sent: Monday, July 03, 2017 11:37 AM
> To: [email-masked]

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 6 Jul 2017 22:10:00 +0000

Support as co-author. More to come…
Acee

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 7 Jul 2017 17:22:03 +0000

OSPF Evolution and the role of
draft-ppsenak-ospf-te-link-attr-reuse

The document draft-ppsenak-ospf-te-link-attr-reuse-05.txt not-only
provides flexible and compact mechanisms and encodings for advertising
link attributes for single or multiple applications. It is also part of
the wider goal of transforming OSPF to a TLV-based protocol that is every
bit as extendable as the other IGPs while affording the distinct advantage
of optimally partitioning the advertised information into multiple LSAs of
different types. 

This draft represents the last piece of our vision to achieve this
outcome. For OSPFv2, we have the base LSAs that cannot be extended in a
backward compatible fashion. Additionally, we have RFC 7770 (OSPF Router
Information Advertisement) and RFC 7684 (OSPF Prefix/Link Attributes). The
former has been extended to support distribution of non-OSPF information
in addition to OSPF Router-level protocol information. The extended OSPF
Prefix/Link LSAs are being used to support segment routing and other
technologies. They are now part of the OSPF base and will be advertised in
many OSPF domains. The major implementations have the capability to
correlate the base LSAs and the OSPF Prefix/Link LSAs for segment routing.
This correlation requires handling lots of chicken and egg complexities
that have all been overcome.

It has been suggested that since the OSPF TE LSAs (RFC 3630) contain some
generally useful link attributes, this be the only means by which this
information is advertised in OSPF routing domains. This will be both
unwieldy and inefficient due to the advertisement, processing, and storage
of the TE LSAs in networks not utilizing RSVP-based TE.  There is also the
added complexity with this approach as you have not only the chicken and
the egg, but the chicken, egg, and the rooster to correlate.

For OSPFv3 and OSPFv3 Extended LSAs
(draft-ietf-ospf-ospfv3-lsa-extend-14.txt), we have made the difficult
choice to extend the base RFC 5340 LSAs (OSPF for IPv6) in a
non-compatible fashion. After an initial delay, we have implementations of
the OSPFv3 Extended LSAs draft and will soon be advancing it. With the
OSPFv3 extended LSAs, we are finally at the point where all the
information (other than RSVP TE information) for a given prefix or link is
advertised in a single LSA rather than multiple LSAs. Would those who
argue for making OSPFv2 TE LSAs generally applicable also want to require
the advertisement of RFC 5329 (OSPFv3 Traffic Engineering) LSAs?  If so,
we would miss a tremendous opportunity.

Thanks,
Acee

---

From: Keyur Patel <[email-masked]>
Date: Fri, 7 Jul 2017 17:56:56 +0000

Support.

Regards,
Keyur

On 7/3/17, 11:37 AM, "OSPF on behalf of Abhay Roy" <[email-masked] on behalf of [email-masked]> wrote:

    
    
    Regards,
    -Abhay

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Fri, 7 Jul 2017 18:20:44 +0000

Support the adoption.

- Naiming

> On Jul 7, 2017, at 10:22 AM, Acee Lindem (acee) <[email-masked]> wrote:
>

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 07 Jul 2017 11:26:59 -0700

+10 to Acee’s comments
OSPF community would greatly benefit from the draft being adopted and implemented (stated as co-author)
 
Cheers,
Jeff

On 7/7/17, 10:22, "OSPF on behalf of Acee Lindem (acee)" <[email-masked] on behalf of [email-masked]> wrote:

    

    Thanks,
    Acee

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 7 Jul 2017 20:33:19 +0200

I support adoption of this proposal.

Thx,
Robert.

---

From: Yingzhen Qu <[email-masked]>
Date: Fri, 7 Jul 2017 21:29:29 +0000

Support the adoption of this draft.

Thanks,
Yingzhen

-----Original Message-----
From: OSPF [mailto:[email-masked]] On Behalf Of Jeff Tantsura
Sent: Friday, July 07, 2017 11:27 AM
To: Acee Lindem (acee) <[email-masked]>; Abhay Roy (akr) <[email-masked]>; [email-masked]
Subject: Re: [OSPF] WG adoption poll for draft-ppsenak-ospf-te-link-attr-reuse

+10 to Acee’s comments
 
Cheers,
Jeff

    

    

    Thanks,
    Acee

---

From: Huaimo Chen <[email-masked]>
Date: Mon, 10 Jul 2017 01:44:31 +0000

Support.

Best Regards,
Huaimo
-----Original Message-----
From: OSPF [mailto:[email-masked]] On Behalf Of Jeff Tantsura
Sent: Friday, July 07, 2017 11:27 AM
To: Acee Lindem (acee) <[email-masked]>; Abhay Roy (akr) <[email-masked]>; [email-masked]
Subject: Re: [OSPF] WG adoption poll for draft-ppsenak-ospf-te-link-attr-reuse

+10 to Acee’s comments
 
Cheers,
Jeff

    

    

    Thanks,
    Acee

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 10 Jul 2017 09:50:11 +0000

I have read this draft and support the WG adoption.

Xiaohu

> -----邮件原件-----
> 发件人: OSPF [mailto:[email-masked]] 代表 Abhay Roy
> 发送时间: 2017年7月4日 2:37
> 收件人: [email-masked]
> 主题: [OSPF] WG adoption poll for draft-ppsenak-ospf-te-link-attr-reuse
>

---

From: Shraddha Hegde <[email-masked]>
Date: Mon, 17 Jul 2017 04:31:33 +0000

OSPF WG,

There has been a long debate on this draft, probably the most discussed in
OSPF WG.  The major contention point with this draft has been around 

1. Definition of TE and Non-TE applications.
     The draft still uses the terminology of TE and non-TE applications without defining
	 the meaning of what is considered TE and what is non-TE.
2. There are implementations that make use of TE LSAs for the purpose of implementing
    [I-D.ietf-rtgwg-lfa-manageability] and
   [I-D.psarkar-rtgwg-rlfa-node-protection]. Normative language is required to make sure
   application such as RSVP and LFA do not suddenly become invalid because one vendor chooses to
   implement this draft and stops advertising link attributes in TE LSAs.
   
   The backward compatibility section specifies
   "When an OSPF routing domain includes routers using link attributes
   from TE Opaque LSAs for Non-RSVP TE applications such as LFA, OSPF
   routers in that domain should continue to advertise such TE Opaque
   LSAs."
   
   In order to make sure operators do not end up seeing inter-op issues due to 
   different vendors implementing the draft at different times a normative
   language such as below MUST be used.
   
   "Routers in the OSPF Domain MUST continue to advertise TE Opaque LSAs, when there are 
   applications that make use of TE Opaque LSAs.In the interest of backward compatibility,
   implementations MUST implement appropriate knobs to facilitate advertisement of link attributes in
   TE LSAs. Implementations MUST also support processing link attributes advertised in TE-LSAs. A separate IETF draft
   MAY be wriiten in future when the deployments are mature enough to move completely to the advertisements
   defined in this draft"

3.  The encodings for the recent addition "Application Specific Values" has scope for improvement. Having seperate
    Masks for standard and user defined applications does not seem necessary. 
	
4. Acee's reference to different OSPF LSAs and comparing them to Chicken, egg and the
   Rooster describes the problem aptly in one sentence.
   Chicken and egg problem is age old in OSPF and all implementations have handled it very well.

   Handling rooster wouldn't have been as difficult but with this draft, chicken, egg and the rooster have moved from 
   vendor's backyard to operator's front yard.
   Operator's have to co-ordinate which vendor advertises what attributes in which LSA and which node/link
   in the network should have which knobs turned on. 

   Deployment consideration section needs to consider various cases of upgrade process.
   There is definitely need for text describing how the advertisements would look like if RSVP, LFA-manageability
   and SR-TE are deployed together.

   These comments on the draft are an effort to make sure existing IETF standardized applications
   would not break when new enhancements are introduced.    

Rgds
Shraddha

-----Original Message-----
From: OSPF [mailto:[email-masked]] On Behalf Of Xuxiaohu
Sent: Monday, July 10, 2017 3:20 PM
To: Abhay Roy <[email-masked]>; [email-masked]
Subject: [OSPF] 答复: WG adoption poll for draft-ppsenak-ospf-te-link-attr-reuse

Xiaohu

---

From: Peter Psenak <[email-masked]>
Date: Mon, 17 Jul 2017 09:04:10 +0200

Hi Shraddha,

thanks for your comments. I believe all of them can be addressed by
editorial changes and I'll be more then happy to work with you on those.

More importantly, it looks to me you are not objecting the problem
statement and the direction that the draft is taking to address it. Is
my understanding correct?

thanks,
Peter