Auto insertion of RSVP ERO based on learned TE topology through IGP

[SouravSinhaRoy]

Explicit Route Object (ERO) creation in RSVP-TE in a way that is closer to solutions employed in existing production routers to emulate the scenario more realistically. The test port must learn the TE topology from the connected IGP (OSPF, ISIS). The test port must then calculate the explicit path to egress based on IGP supplied constraints, destination IP and available bandwidth and auto-create explicit ERO for tunnels between ingress and egress.

[apratimmukherjee]

Discussion on adding new attributes in ero object of RSVP-TE tunnel :

Currently the ERO object in a RSVP tunnel has following attributes:
prepend_neighbor_ip -> Default : dont_prepend ; optional
prefix_length -> applicable only if prepend_neighbor_ip is 'prepend' : optional
array of subjobjects with type / hop_type and as_number or ipv4_address + prefix_length , applicability depending on type.

With auto mode, we need to at minimum add a choice whether ero is manual ( default : where user provides contents of ERO ) or new auto mode where ERO is calculated based on IGP TE learned information ( auto : non-default mode )
i.e. if choice = manual (default) , existing fields should continue to behave as earlier.
prepend_neighbor_ip -> Default : don_prepend ; optional
prefix_length -> applicable only if prepend_neighbor_ip is 'prepend'
array of subjobjects with type / hop_type and as_number or ipv4_address + prefix_length , applicability depending on type.
if choice = auto ( user specifies as non-default )
All the above fields prepend_neighbor_ip , prefix_length and subobjects are no longer applicable
Few 'auto' attributes additional control attributes planned to be added later with more specific user controls
e.g. tie-break criterion ( max-bandwidth / min-bandwith /random )

Design choices

  A) Handle via documentation and behavior : 
        prepend_neighbor_ip , prefix_length and subobjects -> Add documentation that these fields are applicable only if choice = 'manual' 
        Advantage : Backward compatible.
        ero.choice = 'manual/auto'
        ero.prepend_neighbor_ip , ero.prefix_length and ero.subobjects  -> Stays as is and documentation added to indicate applicability only for manual mode.
        ero.auto.tie_break (future) and other fields added for addition control of ERO in auto mode. 
        ero.auto.other_attrib (future)

  B) Group  current attributes inside a 'manual' -> Breaks backward compability . Little more obvious which parameters are for which mode. 
        ero.choice = 'manual/auto'
        ero.manual.prepend_neighbor_ip
        ero.manual.prefix_length
        ero.manual.subobjects  
        ero.auto.tie_break ( future) 
        ero.auto.other_attrib (future)

  C) Keeping both existing attributes and add new attributes to provide deprecation.
        ero.choice = 'manual/auto'
        ero.manual.prepend_neighbor_ip
        ero.manual.prefix_length
        ero.manual.subobjects  
        ero.prepend_neighbor_ip  ( deprecated) 
        ero.ero.prefix_length (deprecated) 
        ero.subobjects  (deprecated) 
        ero.auto.tie_break ( future) 
        ero.auto.other_attrib (future)
        Only if ero.manual optional object is missing and mode is set to manual then only the deprecated elements 
        ero.prepend_neighbor_ip  , ero.prefix_length  and ero.subobjects  will be used to create the manual ERO.
        Remove the three deprecated attributes in future OTG version after couple of sprints after initial release with new OTG with auto mode support for ERO.         

As of now, the PR reflects option A) .