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

From: Julien Meuric <[email-masked]>
Date: Thu, 5 Nov 2015 09:12:03 +0100

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 - [email-masked]:
> 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.

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.

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.

Cheers,

Julien

---

From: Julien Meuric <[email-masked]>
Date: Thu, 5 Nov 2015 09:20:48 +0100

Hi again,

One more point below:

Oct. 22, 2015 - Peter Psenak:
>> The TE Opaque LSA would be, presumably, required if SPRING is supported
>> which has no implications on whether RSVP-TE is enabled.
>
> SPRING does not use TE Opaque LSA.

[JM] Just a quote from draft-ietf-spring-segment-routing:
"The list of segments can be specified explicitly or implicitly via a 
set of abstract constraints (latency, affinity, SRLG, ...). In the 
latter case, a constraint-based path computation is used to determine 
the list of segments associated with the tunnel. The computation can be 
local or delegated to a PCE server."
Though, in the Routing area, "constraint-based path computation" and 
"affinity, SRLG" usually rely on TE/GMPLS opaque LSAs, you may advocate 
this is only implicit... However, when it comes to PCE, the references 
to RFC 3630 and 4203 extensions are explicit.

Regards,

Julien

---

From: Peter Psenak <[email-masked]>
Date: Thu, 05 Nov 2015 09:33:45 +0100

Julien,

On 11/5/15 09:20 , Julien Meuric wrote:
> this is only implicit...

that is fine. If you want to do traffic engineering, you should use TE 
Opaque LSAs.

We are talking about link attributes that are NOT used for TE at all. 
For example SRLG to be used for LFA. In that case you do NOT want to do 
any TE.

Peter

> However, when it comes to PCE, the references
> .

---

From: Peter Psenak <[email-masked]>
Date: Thu, 05 Nov 2015 09:40:00 +0100

Hi Julien,

> two places would multiply configuration discrepancies.

above is incorrect.
Nobody is proposing to configure things like SRLG on multiple places.
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.

> I cannot agree more on these.

have you read the "disadvantage" section as well?

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

thanks,
Peter

>
> Cheers,
>
> Julien
>
> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf
> .
>

---

From: Julien Meuric <[email-masked]>
Date: Thu, 5 Nov 2015 11:03:36 +0100

Hello Peter,

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

> pulls it from the same place, form the TE Opaque LSA and asks IGP to
[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.

> have you read the "disadvantage" section as well?
[JM] Of course not, since Shraddha already solved them in his original 
e-mail. :-)

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

> Peter
[JM] You're welcome,

Julien

---

From: Peter Psenak <[email-masked]>
Date: Thu, 05 Nov 2015 13:26:12 +0100

Julien,

> would be identical. If they are different..."

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

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

> [JM] Of course not, since Shraddha already solved them in his original

I'm afraid she did not.

> state advertisements. Please, point me to the section from RFC 3630 it

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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 7 Nov 2015 14:57:56 +0000

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

---

From: Julien Meuric <[email-masked]>
Date: Tue, 10 Nov 2015 17:51:39 +0100

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.

Regards,

Julien

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 11 Nov 2015 22:57:36 +0000

Hi Julien, 

>defining detour path by packet header instead of signaling states brings

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.

>advertisements/configuration that the current I-D does not (even try to)

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

---

From: Peter Psenak <[email-masked]>
Date: Thu, 12 Nov 2015 12:45:05 +0100

Julien,

> advertisements/configuration that the current I-D does not (even try to)

let me disagree. Current I-D clearly states what TE Opaque LSAs are used 
for.

The risk is when you do what you propose to do as it breaks the existing 
TE - 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.

regards,
Peter

---

From: <[email-masked]>
Date: Fri, 13 Nov 2015 17:47:58 +0100

Hi Peter,

See [JM] below.

> let me disagree. Current I-D clearly states what TE Opaque LSAs are used

[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)

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

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.

Enjoy the week-end,

Julien

>>>> state advertisements. Please, point me to the section from RFC 3630 it

_________________________________________________________________________________________________________________________

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.

---

From: Peter Psenak <[email-masked]>
Date: Fri, 13 Nov 2015 18:24:44 +0100

Hi Julien,

please see inline:

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

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

> statement of TE LSA parameters beyond MPLS-TE" may be a way to address

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

> 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,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 13 Nov 2015 19:54:13 +0000

Furthermore, I don’t see how you’d interpret this as Jeff being against
advertising SRLG in a more efficient and standard manner for IP
applications. He was simply acknowledging the fact that there is
proprietary usage of the GMPLS TE extensions beyond GMPLS.

Thanks,
Acee 

On 11/13/15, 12:24 PM, "Peter Psenak (ppsenak)" <[email-masked]> wrote:

>>>>> advertising these attributes is segment routing TI-LFA. In addition
>>>>>to
>>>>> all
>>>>>>>>> I'm familiar with at least 2 implementations which have this
>>>>>>>>>issue,
>>>>>>>>> this draft solves real problem.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Jeff
>>>>>>>>
>>>>>> 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"
>>_________________________________________________________________________
>>________________________________________________
>>
>>

---

From: Jeff Tantsura <[email-masked]>
Date: Sat, 14 Nov 2015 02:00:19 +0000

Hi,

I’m being quoted all over, so my response :)
There’s a real issue, and it is getting worse, since RFC7471 is getting implemented and widely used for IP applications.
I’d really prefer not to enable TE in order to be able to use this, rather useful information.

Furthermore - I don’t think there’s an issue with synchronization and consistency between TED and LSDB, they have got/might have different consumers and need not be consistent.
Hope this clarifies my position.

Cheers,
Jeff