Hi Julien, One such non-TE application where there is a clear advantage of advertising these attributes is segment routing TI-LFA. In addition to all the detriments of requiring advertisement of TE LSAs when TE is not enabled, one would need to consolidate information for a link from 3 separate LSAs (the base Router-LSA, the prefix-list attribute LSA for the adjacency SID, and the TE LSA). Clearly, it is better to advertise the applicable attributes in the Prefix/Link Attribute LSA and reduce this burden. You will note that this advantage isn’t apparent in IS-IS where everything is advertised in one monolithic LSP.
Thanks, Acee On 11/5/15, 7:03 PM, "OSPF on behalf of Julien Meuric" <[email protected] on behalf of [email protected]> wrote: >Hello Peter, > >Nov. 05, 2015 - [email protected]: >> Hi Julien, >> >> On 11/5/15 09:12 , Julien Meuric wrote: >>> Hi Jeff, >>> >>> Following the WG session yesterday, I'm glad to (lately) join the >>> thread. Please, see my comments below as [JM]. >>> >>> >>> Oct. 26, 2015 - [email protected]: >>>> Hi, >>>> No hats >>>> >>>> I'm familiar with at least 2 implementations which have this issue, >>>> this draft solves real problem. >>>> >>>> Regards, >>>> Jeff >>> >>> [JM] Then you may consider patching them to do parameter duplication on >>> the receiver side, not on the wire and/or the emitter configuration... >>> Do you imagine operational people tearing hair out while trying to >>>guess >>> if they need to configure SRLGs in here, there or both? All the more as >>> two places would multiply configuration discrepancies. >> >> above is incorrect. >> Nobody is proposing to configure things like SRLG on multiple places. >[JM] Actually you do in the I-D: "it is expected that the information >would be identical. If they are different..." > >> You configure it on a single place, as you do today. If IGP is enabled >> for global SRLG protection, IGP pulls the SRLGs and advertise them in >> the Extended Prefix LSA. If TE is enabled and want to use SRLGs, it >> pulls it from the same place, form the TE Opaque LSA and asks IGP to >> flood it. >[JM] This reads to me like "in case both types of LSAs are used, values >MUST be identical". This is very different from the loose text in your >I-D. > >> >>> >>> In the I-D, the beginning and the end of section 3.1 provide a good >>> summary: >>> - "One approach for advertising link attributes is to _continue_ to use >>> TE Opaque LSA" >>> - advantages: "no additional standardization requirement", "link >>> attributes are only advertised once". >>> I cannot agree more on these. >> >> have you read the "disadvantage" section as well? >[JM] Of course not, since Shraddha already solved them in his original >e-mail. :-) > >>> >>> In other words, some new use cases, not matching the original one, do >>> not justify to allocate new code points to the same information (cf. >>> IS-IS non-issue). In the IETF, uses cases aim at scoping protocol work, >>> they aren't made to limit protocol future uses. >> >> I;m afraid you are missing the point. >> TE Opaquer LSA are defined as LSAs that advertise TE topology that is >> disjoint from the IGP topology (RFC3630). We can NOT make the link part >> of the TE topology, just because we want to advertise SRLG or some other >> attribute that is used by IGP for LFA - that would break the RFC3630. >[JM] Indeed, I am missing the point where a link state protocol is >forbidden to access the link parameters it is distributing in its link >state advertisements. Please, point me to the section from RFC 3630 it >"breaks". > >> >> thanks, >> Peter >> >[JM] You're welcome, > >Julien > >>> >>> Cheers, >>> >>> Julien >>> >>> _______________________________________________ >>> 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
