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

Alia (and everyone) –

Let’s focus on the relevant questions.

1)Disruption to existing deployments

draft-ppsenak-ospf-te-link-attr-reuse is non-disruptive i.e. legacy systems are not impacted

draft-hegde-ospf-advertising-te-protocols is disruptive – all legacy routers have to have additional configuration in order to avoid misinterpreting non RSVP-TE advertisements as if they are RSVP-TE related

So if the primary concern is impact on existing deployments we have a clear choice.

2)Support for per application advertisements

Only draft-ppsenak-ospf-te-link-attr-reuse supports this.

Again we have a clear choice.

3)The question has been raised as to use case for application specific attributes– here are a few:

·         Using TE metric/bandwidth to influence LFA selection.

·         Use different attributes for SR-TE vs RSVP-TE engineered paths.

·         Defining a separate set of SRLGs in support of rerouting around a non-local catastrophic event e.g. a natural disaster affecting all traffic through a particular geographic area.

Both drafts agree that supporting multiple applications utilizing link attributes is a problem which needs to be solved. However, only draft-ppsenak-ospf-te-link-attr-reuse provides support for both sharing common attributes without duplicate advertisements and advertising application specific attributes when necessary.

The proponents of draft-hegde-ospf-advertising-te-protocols would have us believe that there is no need for per application attributes – but as we have examples of when it is necessary – and the recognition that all future use cases cannot be imagined now (just as the original TE support never anticipated multiple applications) this isn’t a credible position.

The more apt question to ask is why we would want to constrain multiple application support when we have the opportunity to define a more flexible framework which also provides efficient encoding whenever possible. Given that we have agreed to support multiple applications I think the onus should be on why we should NOT provide per application value support rather than why we should.

   Les

From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Alia Atlas
Sent: Thursday, March 30, 2017 12:20 PM
To: Robert Raszuk
Cc: OSPF List
Subject: Re: [OSPF] draft-ppsenak-ospf-te-link-attr-reuse

Robert,

Take a read through RFC 7282.  Consensus calls aren't about majority rules.
It is about hearing technical objections and understanding and responding to them.
It is quite quite clear that there are technical objections to either solution.

Regards,
Alia

On Thu, Mar 30, 2017 at 3:15 PM, Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>> wrote:
Hi,

Based on the discussion so far I see that:

A) producing use case document will only delay things further as each use case presented will be questioned as possible already today via MTR, MI, building new separate network etc ...

B) WG members in majority support adoption of draft-ppsenak-ospf-te-link-attr-reuse. Can we get at least sense in the room who is in support of which draft ?

Thx,
R.

_______________________________________________
OSPF mailing list
OSPF@ietf.org<mailto:OSPF@ietf.org>
https://www.ietf.org/mailman/listinfo/ospf