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

["Acee Lindem (acee)" <[e-mail]>]

Hi Julien, 

On 11/10/15, 11:51 AM, "Julien Meuric" <[e-mail]> 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 - [e-mail]:
>> 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"
>> <[e-mail] on behalf of [e-mail]> wrote:
>>
>>> Hello Peter,
>>>
>>> Nov. 05, 2015 - [e-mail]:
>>>> 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 - [e-mail]:
>>>>>> 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
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/ospf
>>>>> .
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> OSPF mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ospf
>>