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