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

[Peter Psenak]

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

On 17/07/17 06:31 , Shraddha Hegde wrote:
> 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:ospf-boun...@ietf.org] On Behalf Of Xuxiaohu
> Sent: Monday, July 10, 2017 3:20 PM
> To: Abhay Roy ; ospf@ietf.org
> 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:ospf-boun...@ietf.org] 代表 Abhay Roy
>> 发送时间: 2017年7月4日 2:37
>> 收件人: ospf@ietf.org
>> 主题: [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
>> OSPF@ietf.org
>> https://www.ietf.org/mailman/listinfo/ospf
> ___
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf
> ___
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf
> 

___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

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

[Shraddha Hegde]

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:ospf-boun...@ietf.org] On Behalf Of Xuxiaohu
Sent: Monday, July 10, 2017 3:20 PM
To: Abhay Roy ; ospf@ietf.org
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:ospf-boun...@ietf.org] 代表 Abhay Roy
> 发送时间: 2017年7月4日 2:37
> 收件人: ospf@ietf.org
> 主题: [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
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf
___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf
___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf