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

[Shraddha Hegde <[e-mail]>]

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:[e-mail]] On Behalf Of Xuxiaohu
Sent: Monday, July 10, 2017 3:20 PM
To: Abhay Roy <[e-mail]>; [e-mail]
Subject: [OSPF] 答复: WG adoption poll for draft-ppsenak-ospf-te-link-attr-reuse

I have read this draft and support the WG adoption.

Xiaohu

> -----邮件原件-----
> 发件人: OSPF [mailto:[e-mail]] 代表 Abhay Roy
> 发送时间: 2017年7月4日 2:37
> 收件人: [e-mail]
> 主题: [OSPF] WG adoption poll for draft-ppsenak-ospf-te-link-attr-reuse
> 
> 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
> 
> _______________________________________________
> OSPF mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ospf
_______________________________________________
OSPF mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ospf