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

[Peter Psenak <[e-mail]>]

Hi Julien,

please see inline:

On 11/13/15 17:47 , [e-mail] wrote:
> Hi Peter,
>
> See [JM] below.
>
>
> Nov. 12, 2015 - [e-mail]:
>> 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 - [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
>>>>
>>> .
>>>
>>
>
> _________________________________________________________________________________________________________________________
>
>
> 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.
>
> .
>