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

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