Subject: [OSPF] Comment on draft-ppsenak-ospf-te-link-attr-reuse-01

From: Julien Meuric <[email-masked]>
Date: Tue, 16 Feb 2016 18:24:40 +0100

Hi Pete,

I believe the new text in the section 5 of the aforementioned I-D is a 
nice improvement for the specification (thank you Chris).

However, the current version still says "TE will use the information in 
the TE Opaque LSA and the non-TE applications will use the information 
in the OSPFv2 Extended Link Opaque LSA". Then remote LFA joins the 
party, and I wonder if it is a "TE application" or not. As "there is no 
IETF specification documenting" what would strictly fall under "TE 
application" or "non-TE application", and even no real need to define a 
strict boundary, I consider that sentence as over-specification and 
suggest to jusst drop it. That would let applications themselves look 
for that information where relevant/specified, whether they 
philosophically feel like being TE or not.

What is more, I really think that the current wording  is too loose in 
"it is expected that the information in these LSA [sic] would be 
identical". I do not see the drawback of having full alignment of values 
in case of duplication, but I see the operational risk of nightmare in 
case they are not. As a result, I suggest to rephrase into: "If the same 
link attribute is advertised in both LSAs, the information in these LSAs 
MUST be identical."

Cheers,

Julien

---

From: Peter Psenak <[email-masked]>
Date: Wed, 17 Feb 2016 11:25:18 +0100

Hi Julien,

On 2/16/16 18:24 , Julien Meuric wrote:
> party, and I wonder if it is a "TE application" or not.

clearly it is not.

> As "there is no
> suggest to jusst drop it.

LFA has nothing to do with TE, it's obvious.

And yes, we need a strict boundary between what is TE related and what 
is not. If we don't define it, then every implementation can choose what 
LSA to use, which would lead to the interoperability problems. The 
purpose of this draft is to define a single mechanism to advertise link 
attributes for non-TE applications.

> That would let applications themselves look

TE application MUST only look at the TE Opaque LSA - that is specified 
already.

Non-TE application SHOULD look at Extended Link LSA - that is what we 
want to specify in this draft.

> link attribute is advertised in both LSAs, the information in these LSAs

given the OSPF protocol operation above can not be guaranteed. LSAs 
arrive asynchronously and there can be intervals during which the 
consistency of the information between two different LSAs can not be 
guaranteed.

thanks,
Peter

> .

---

From: Julien Meuric <[email-masked]>
Date: Thu, 18 Feb 2016 16:47:57 +0100

Hi Peter,

>> party, and I wonder if it is a "TE application" or not.

[JM] OK

> LFA has nothing to do with TE, it's obvious.

[JM] I tend to agree on that, though not fully on the "obvious".

> attributes for non-TE applications.

[JM] Yes, each application specification should state where among OSPF 
LSAs it gets these link parameters from. But it does not require to 
split application space between TE and non-TE:
- applications per se should not be concerned about that split, this is 
protocol-related and should be addressed at the end of the specification 
chain (i.e., "this parameters is to be used for...", not "this use case 
falls into category X");
- this is OSPF-specific: when considering IS-IS, this is not an issue;
- the LFA example already contradicts the rule you suggest, tempering 
the backward compatibility text could avoid this situation.

> TE application MUST only look at the TE Opaque LSA - that is specified

[JM] I would be cautious on "only". E.g., RFC 7770 can be applicable, 
though not TE.

> want to specify in this draft.

[JM] I am still confused with this "TE/non-TE application" rough 
summary, but I think we could find an agreement by saying that opaque 
LSAs (including TE) are to be used by so-called "TE application", and 
that extended link LSA should be preferred by the others.

> consistency of the information between two different LSAs can not be

[JM] We fully agree on that. To make sure this is not creating an 
ambiguity, you may rephrase as:
"If the same link attribute is advertised in both LSAs, the information 
packed in these LSAs by advertising routers MUST be identical."

Thanks,

Julien

---

From: Peter Psenak <[email-masked]>
Date: Thu, 18 Feb 2016 23:36:24 +0100

Hi Julien,

please see inline :(##PP)

> [JM] Yes, each application specification should state where among OSPF

##PP
let me disagree. Applications do not decide which LSAs to use. It's the 
protocol extension that is made for an application and application needs 
to follow it. And for TE application it has been done by RFC3630.

> - this is OSPF-specific: when considering IS-IS, this is not an issue;

##PP
well, let's not get into that discussion here.

> the backward compatibility text could avoid this situation.

##PP
the text we added in the Backward Compatibility is not meant to 
standardized the non standard behavior by any means.

> [JM] I would be cautious on "only". E.g., RFC 7770 can be applicable,

##PP
I do not see what RFC 7770 has to do with link attributes. RFC7770 is 
about advertising optional router capabilities, which is completely 
orthogonal to this draft.

> that extended link LSA should be preferred by the others.

##PP
Extended Link LSA is an Opaque LSA as well. You need to specify which 
Opaque LSA is to be used by TE and which for the rest of apps.

> packed in these LSAs by advertising routers MUST be identical."

##PP
I'm still not sure we want to enforce that even on the router that 
generates these. Different apps may use different values of certain link 
attribute. Take an SRLG as an example. You may have SRLG values on the 
link used only by GMPLS/optical plane. These values have meaning only in 
the context of the GMPLS/optical. You do not want LFA to use these 
values, because their meaning is different and irrelevant for LFA, you 
may define a different set of values used by LFA.

In general, by mandating the same values in both LSAs we are creating an 
unnecessary limitation that I'm not convinced about.

thanks,
Peter

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 20 Feb 2016 00:44:40 +0000

Hi Julien, 

>packed in these LSAs by advertising routers MUST be identical."

Are we sure on this? Today we can have an OSPF metric that is independent
of the OSPF TE Metric - why wouldn’t we want the same flexibility with
SRLG? 

Thanks,
Acee

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

---

From: Julien Meuric <[email-masked]>
Date: Tue, 23 Feb 2016 10:08:41 +0100

Hi Acee,

> Hi Julien,

[snip]

> of the OSPF TE Metric - why wouldn’t we want the same flexibility with

[JM] From my perspective, I concur. Metrics are purely administrative 
parameters: it makes sense to allow operators to use different routing 
decision between SPF and TE. Conversely, SRLGs are supposed to abstract 
the underlying infrastructure to enable diverse routing: this gives a 
clear semantic on the SRLG link parameter. I do not see any value in 
using two different infrastructure descriptions, while I see some risk 
of operational mess in case one forget to update one of the parameter sets.
I also believe that if double SRLG capability had been an operator's 
requirement, we would have started from there and confronted that to 
both IGPs. This is a different motivation here.

Cheers,

Julien

> Acee
[snip]

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 23 Feb 2016 19:05:45 +0000

Hi Julien, 

>both IGPs. This is a different motivation here.

I agree that I don’t really see a requirement for separate TE and IP
SRLGs. However, I’m not sure this is something that the protocol. Perhaps
this falls into the category of “RECOMMENDED”.  We will discuss amongst
the authors once Peter returns from vacation.

Acee

---

From: Rob Shakir <[email-masked]>
Date: Fri, 26 Feb 2016 16:56:45 -0700

Hi Acee, Peter, Julien,

On 23 February, 2016 at 12:06:10 PM, Acee Lindem (acee) ([email-masked]) wrote:

##PP 
I tend to agree with Julien here, this sounds problematic from a management perspective. If I something that is a physical property of the link (which a SRLG is); and I run “TE” and “non-TE” applications on my network - i.e., a LFA and RSVP-TE tunnels, then I now need to maintain both the lists being identical, such that the extended link attribute SRLG classification matches the TE attribute’s values. This sounds complex (what happens when they get out of sync); with no huge up-side to duplicating them. Even if we do want to have one application work differently to another w.r.t SRLGs, then why would we not do this with the policy that is used when making a path placement decision, rather than by splitting them into different attributes?

IMHO, a nice solution here is that we have each set of information maintained in one place in the protocol; if this has historically been in the TE attribute, then I do not necessarily see a good reason to try and move it. Going forward, we should discuss for new extensions whether these attributes are solely useful for traffic engineering; or whether they are more general purpose, Metric gives us a good example here - the TE metric is *only* relevant to traffic engineering path placement, whereas the metric is relevant to LFA, standard IP applications, and can be relevant to TE. 

I would also rather see this than duplicating the same content of attributes across two different LSAs. This creates ambiguity as to which one was actually used by the consuming application on the network element for a particular protocol.

Best,

r.

---

From: Peter Psenak <[email-masked]>
Date: Mon, 29 Feb 2016 13:30:51 +0100

Hi Rob, Julien,

please see inline:

On 2/27/16 00:56 , Rob Shakir wrote:
> Hi Acee, Peter, Julien,
>
> On 23 February, 2016 at 12:06:10 PM, Acee Lindem (acee) ([email-masked]
> <mailto:[email-masked]>) wrote:
>
>> ##PP
> I tend to agree with Julien here, this sounds problematic from a
> management perspective. If I something that is a physical property of
> the link (which a SRLG is); and I run “TE” and “non-TE” applications on
> my network - i.e., a LFA and RSVP-TE tunnels, then I now need to
> maintain both the lists being identical, such that the extended link
> attribute SRLG classification matches the TE attribute’s values. This
> sounds complex (what happens when they get out of sync); with no huge
> up-side to duplicating them. Even if we do want to have one application
> work differently to another w.r.t SRLGs, then why would we not do this
> with the policy that is used when making a path placement decision,
> rather than by splitting them into different attributes?
>
> IMHO, a nice solution here is that we have each set of information
> maintained in one place in the protocol; if this has historically been
> in the TE attribute, then I do not necessarily see a good reason to try
> and move it. Going forward, we should discuss for new extensions whether
> these attributes are solely useful for traffic engineering; or whether
> they are more general purpose, Metric gives us a good example here - the
> TE metric is *only* relevant to traffic engineering path placement,
> whereas the metric is relevant to LFA, standard IP applications, and can
> be relevant to TE.
>
> I would also rather see this than duplicating the same content of
> attributes across two different LSAs. This creates ambiguity as to which
> one was actually used by the consuming application on the network
> element for a particular protocol.

In general, enforcing the same values to be carried for the same link 
attribute in two different LSAs may become a limitation in the future. 
We already have a precedence with IGP/TE metric. At the end we are 
talking about two independent LSAs/TLVs, we are just sharing the same 
TLV format.

In terms of SRLG, there are real deployments, where optical plane uses 
SRLGs that are associated with a larger areas like "city" or "district" 
that are used for disaster recovery purposes and such values would have 
not meaning in the context of the LFA - one would still want to use the 
LFA that is in such SRLG.

There should be no ambiguity really - information carried in TE Opaque 
LSA is used by TE/GMPLS application. What is carried in Extended Link 
LSA is used by other applications.

thanks,
Peter