Hi Peter, Thanks - in-line- Deborah
-----Original Message----- From: Peter Psenak <[email protected]> Sent: Thursday, June 11, 2020 7:00 AM To: BRUNGARD, DEBORAH A <[email protected]>; The IESG <[email protected]> Cc: [email protected]; [email protected]; [email protected]; Acee Lindem <[email protected]>; Yingzhen Qu <[email protected]>; [email protected] Subject: Re: Deborah Brungard's Discuss on draft-ietf-ospf-te-link-attr-reuse-14: (with DISCUSS and COMMENT) Hi Deborah, thanks for your comments, please see inline (##P): > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > As Warren noted, the draft is very difficult to read. > > This doesn't parse: > "As soon as the router that is an RSVP-TE head-end sees the link attribute > being > advertised for that link, it assumes RSVP-TE is enabled on that link, > even though it is not. If such RSVP-TE head-end router tries to > setup an RSVP-TE path via that link it will result in the path setup > failure." > It seems there is the assumption the link is congruent with the signaling > (maybe some implementations do but not per spec). Maybe this is needed by some > implementations, but the draft seems to make it a "general problem". ##PP It is a general problem. RSVP-TE and IGP topologies do not need to be congruent. All major vendors' implementation derive the link participation in the RSVP-TE topology from the presence of the RSVP-TE link attributes. So this is one of the two problems this draft solves. ##DB That's too bad - sad. But as you say it is an implementation problem - that's my concern on having these sentences in this document - we will be giving visibility to it as if it is a "BCP". I think this needs to be prefaced as "Some implementations". As I said, I find this confusing and detracts from the (hopefully) main aim of the document. I'll redo my Discuss to add this qualifier as I do think we need to accurately say this is an implementation problem. ##PP how is RFC8426 relevant in the context of this draft? ##DB Advertising bandwidth per an application will not solve the "big problem" - dark bandwidth accounting. While not part of the advertisement, as we already have an RFC on it, it would be helpful to our user community to point to it. thanks, Peter > > > > > _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
