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 protected]> 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:[email protected]] *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 protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/ospf > > >
_______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
