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

[Robert Raszuk <[e-mail]>]

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) <
[e-mail]> wrote:

> 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:[e-mail]] *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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ospf
>
>
>