Hi Shraddha,

please see inline:

On 12/16/14 18:31 , Shraddha Hegde wrote:
Rob,

Pls see inline..

-----Original Message-----
From: [email protected] [mailto:[email protected]]
Sent: Tuesday, December 16, 2014 10:11 PM
To: Shraddha Hegde; [email protected]; 
[email protected]
Cc: [email protected]
Subject: Re: draft-ietf-ospf-segment-routing-extensions-03

Shraddha,

Is it really up to the neighbor to specify what was previously a bundle?

<Shraddha>  The graceful restart in OSPF as per RFC  3623 works by learning  
the LSAs from neighbor after the restating router comes up and builds the LSA 
database based on the learnt           LSAs.
                  The neighbor relays back the LSA generated by the restarting 
router. The Extended link LSA contains the adj-sid Label TLV which
                            Has the "s bit" set indicating the label is a set 
label. If there are multiple such set labels associated with a link, its difficult to 
associate which label was allocated for which bundle.

                           If there is a some kind of identifier for the 
bundle, the label can be easily associated.

I don't think adding additional info to be distributed by the protocol is the right way to address the local data persistence across restart/switch over. If you need to make sure that the LSA contains the same data prior and after GR, you can checkpoint them and restore from checkpoint after GR.



It is surely the local configuration of the node that determines what the 
bundle is in the first place, and this is persistent over a graceful-restart of 
the session?

<Shraddha> Yes, IMO local configuration decides which links belong to the 
bundle. This configuration is persistent over graceful restart.
                           You MAY want to bundle all the parallel links 
between two nodes into a bundle, in which case the existing protocol operations 
work fine.
                            But I think protocol should provide flexibility to 
make multiple bundles, able to assign a link to multiple bundles (if so 
desired) and recovering the label across restart.

sure. If you need to make sure that same label is used prior and post GR, you do not need protocol help for that.

thanks,
Peter


Thanks,
r.

[16/12/2014 16:34, "Shraddha Hegde" <[email protected]>]

Peter,

An extended link LSA can contain multiple adj-sid labels with "s bit" set.
During graceful restart , when self generated LSAs are learnt from
neighbors, A handle is required to associate the set label with the
bundle.

I think a group-id field along with set label would serve the purpose.

Rgds
Shraddha
-----Original Message-----
From: Peter Psenak [mailto:[email protected]]
Sent: Sunday, December 14, 2014 4:08 PM
To: Shraddha Hegde;
[email protected]
Cc: OSPF WG List
Subject: Re: draft-ietf-ospf-segment-routing-extensions-03

Shraddha,

the idea is that you can assign the same Adj-SID to multiple links.
That way you can create multiple sets as you need.

thanks,
Peter


On 12/13/14 19:19 , Shraddha Hegde wrote:
Authors,

          When there are multiple parallel links between two nodes, it
is useful to

Group them into different bundles and use each bundle for load-balancing
   for different traffic flows.

What we have in adjacency sid is just a flag to indicate that the
label is a "set label" by setting a flag

In adj-sid TLV. It serves the purpose when all the parallel links
are in one bundle but not sufficient when

There can be different bundles and different labels for each of them.

An identifier for the group, probably "group-id" is needed to
associate the label with the interface group.

Any thoughts on this?

Rgds

Shraddha



.


_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf

Reply via email to