Furthermore, I don’t see how you’d interpret this as Jeff being against advertising SRLG in a more efficient and standard manner for IP applications. He was simply acknowledging the fact that there is proprietary usage of the GMPLS TE extensions beyond GMPLS.
Thanks, Acee On 11/13/15, 12:24 PM, "Peter Psenak (ppsenak)" <[email protected]> wrote: >Hi Julien, > >please see inline: > >On 11/13/15 17:47 , [email protected] wrote: >> Hi Peter, >> >> See [JM] below. >> >> >> Nov. 12, 2015 - [email protected]: >>> Julien, >>> >>> On 11/10/15 17:51 , Julien Meuric 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... >>>> >>>> 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. >>> >>> let me disagree. Current I-D clearly states what TE Opaque LSAs are >>>used >>> for. >> >> [JM] I am happy to quote Jeff on this: "thanks to GMPLS IGP extensions >> as per RFC's 4203 & 5307 SRLG info is there, it is up to implementation >> how to use it." >> >>(https://mailarchive.ietf.org/arch/msg/rtgwg/yURBLVi2LqrEz33wKkauV0j9cmA) > >Jeff is a co-author of the ospf-te-link-attr-reuse, so I let him express >his opinion, but he has responded on the list already saying: > >"I'm familiar with at least 2 implementations which have this issue, >this draft solves real problem." > >> >>> >>> The risk is when you do what you propose to do as it breaks the >>>existing >>> TE >> >> [JM] This is different from Acee's point: "usage of the TE LSAs for >> non-TE purposes was NEVER standardized". It is not about breaking, it is >> about documenting use cases beyond the original one. >> >> - e.g. you advertise the link in TE Opaque LSA and some remote router >>> would try to establish a TE path via such link, even though the link is >>> not enabled for that. Result is that the signaling would keep failing >>>or >>> in worst case, when signaling is not involved, traffic will be dropped >>> when trying to use such link. >> >> [JM] Supposing I am an operator who is playful enough to manage a >> network area using a topology for TE traffic that does not match the >> IP/LDP topology (you may find this realistic, I do not). Then, a router >> ignoring that an SRLG-enabled link has no available bandwidth/a specific >> affinity/a non-PSC switching capability/etc. is misbehaving. > >well, that is not necessarily true, for example 0 bandwidth tunnels are >often used. RFC3630 does not mandate bandwidth, affinity or any other >link attributes in TE Opaque LSAs. Link Type and Link ID sub-TLVs are >mandatory, rest are optional. > >> >> Anyway, this moves beyond the issue at stake here. Acee states that some >> implementations need new definitions to go beyond the original use case. >> I would like to limit the number of fields opening the doors to >> operational inconsistencies. In these regards, an "applicability >> statement of TE LSA parameters beyond MPLS-TE" may be a way to address >> our concerns. > >I'm afraid we can not afford to change the RCF that has been published >12 years back. This would make it backward incompatible. > >> >> Enjoy the week-end, > >you too! > >thanks, >Peter > >> >> Julien >> >> >>> >>> >>> regards, >>> Peter >>> >>>> >>>> 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 >>>>> >>>> . >>>> >>> >> >> >>_________________________________________________________________________ >>________________________________________________ >> >> >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >> recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >> electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme >> ou falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged >> information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and >> delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have >> been modified, changed or falsified. >> Thank you. >> >> . >> > _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
