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

Julien,

On 11/5/15 11:03 , Julien Meuric 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..."

above talks about the LSA content, not about the configuration.

>
>> 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.

I would think that that would always be identical, if advertised in both 
LSAs. But from the protocol encoding perspective, we can not prevent 
values being different - e.g. transition case where config of SRLG on 
remote node changes and two LSAs arrive asynchronously.

>
>>
>>>
>>> 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. :-)

I'm afraid she did not.

>
>>>
>>> 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".

RFC3630:

    "The extensions provide a way of describing the traffic engineering
    topology (including bandwidth and administrative constraints) and
    distributing this information within a given OSPF area.  This
    topology does not necessarily match the regular routed topology,"

If you want to advertise SRLG for a link (to be used for LFA), but you 
do not want to make the link part of the traffic engineering topology, 
how do you do that?

regards,
Peter

>
>>
>> thanks,
>> Peter
>>
> [JM] You're welcome,
>
> Julien
>
>>>
>>> Cheers,
>>>
>>> Julien
>>>
>>> _______________________________________________
>>> OSPF mailing list
>>> OSPF@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ospf
>>> .
>>>
>>
> .
>