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

From: Robert Raszuk <[email-masked]>
Date: Thu, 30 Mar 2017 14:15:27 -0500

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.

---

From: "Ahmed Bashandy (bashandy)" <[email-masked]>
Date: Thu, 30 Mar 2017 19:17:08 +0000

I am in the room and I certainly support the draft.

Ahmed

From: OSPF [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Thursday, March 30, 2017 12:15 PM
To: [email-masked]
Subject: [OSPF] draft-ppsenak-ospf-te-link-attr-reuse

Hi,

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.

---

From: Alia Atlas <[email-masked]>
Date: Thu, 30 Mar 2017 15:19:53 -0400

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

> B) WG members in majority support adoption of draft-ppsenak-ospf-te-link-attr-reuse.
> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf
>
>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 30 Mar 2017 14:26:57 -0500

Seems like we have different understanding on rough consensus .. but let's
leave that one aside.

What are technical objections to draft-ppsenak-ospf-te-link-attr-reuse ?

I have not heard even single one so far.

Stefan's suggestion for indirection rather the bitfield is clearly not a
technical objection but good debate when draft becomes a WG document ?

Cheers,
R.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 31 Mar 2017 04:36:45 +0000

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:[email-masked]] 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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Thx,
R.

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

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 30 Mar 2017 23:56:50 -0500

Hi all,

There is also one more significant observation to be stated. When we
introduce new metrics applicable only to one application (say SR) and
completely foreign to RSVP-TE indicating clearly the application they are
to be used by is very helpful.

Otherwise requirement of sync of support by all applications for any newly
introduced metric or link parameter/color is either an operational obstacle
or unnecessary load on legacy apps.

Last let's also do not forget about the case of BGP-LS where controllers
dealing with RSVP-TE (PCE) maybe quite decoupled from SR oracles.

With per application marker it is quite easy to feed such controller with
only necessary information. And here by "necessary" I am not worrying as
much about RAM additional parameters would take if sent as one bundle, but
about the opposite need of isolation and speed up delivery of only ms data
related link delayed to one financial traffic stream controller.  If I
always will end up bundling it with all other junk the end application
performance will suffer.

Same for unicast vs multicast link parameters or attributes.

Cheers,
R.

PS, As to the point raised by Stefan I think I would have a proposal that
the easiest would be to have domain scope and domain specific bits such
that without building indirection you can locally specify which bit
corresponds to which application you like. And this also works if you need
to have different attributes for different RSVP-TE instances or SR
controllers co-existing still in the same topology.

On Thu, Mar 30, 2017 at 11:36 PM, Les Ginsberg (ginsberg) <
[email-masked]> wrote:

> 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
>
>
>
> ·         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:[email-masked]] *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,
>
>
>