Hi Julien, On 11/10/15, 11:51 AM, "Julien Meuric" <[email protected]> wrote:
>Hi Acee, > >I think we do not need to agree on the philosophical question whether >defining detour path by packet header instead of signaling states brings >the feature out of TE... I would define TE as those applications that use the topology in the TE topology (which is advertised in the TE LSAs). I think the IETF definition is clear on what these are as they are under the auspices of the TEAS WG. > >Anyway we agree that consolidating information from 3 separates LSA is >not the most efficient processing. My point is that this slight >improvement does not balance the risk of inconsistent >advertisements/configuration that the current I-D does not (even try to) >prevent. Improvement?? The usage of the TE LSAs for non-TE purposes was NEVER standardized or even recommended by any IETF document so this is a choice that we have now as opposed to any improvement. Also note that there is already a precedence set here to have a separate SRLG as we currently have both an OSPF metric and an OSPF TE metric. Thanks, Acee > >Regards, > >Julien > > >Nov. 07, 2015 - [email protected]: >> 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
