Re: [OSPF] Regarding draft-ppsenak-ospf-te-link-attr-reuse-00

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"
<ospf-bounces@ietf.org on behalf of julien.meuric@orange.com> wrote:

>Hello Peter,
>
>Nov. 05, 2015 - ppsenak@cisco.com:
>> 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 - jeff.tantsura@ericsson.com:
>>>> 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
>>> OSPF@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ospf
>>> .
>>>
>>
>
>_______________________________________________
>OSPF mailing list
>OSPF@ietf.org
>https://www.ietf.org/mailman/listinfo/ospf