-----Original Message----- From: Peter Psenak [mailto:ppse...@cisco.com] Sent: Wednesday, December 17, 2014 1:23 PM To: Shraddha Hegde; rob.sha...@bt.com; draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org Cc: ospf@ietf.org; isis...@ietf.org Subject: Re: draft-ietf-ospf-segment-routing-extensions-03
Shraddha, added ISIS WG alias, as this is not specific to OSPF. Please see inline: On 12/17/14 06:43 , Shraddha Hegde wrote: > Peter, > > > Please see inline: > > -----Original Message----- > From: Peter Psenak [mailto:ppse...@cisco.com] > Sent: Tuesday, December 16, 2014 11:36 PM > To: Shraddha Hegde; rob.sha...@bt.com; > draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org > Cc: ospf@ietf.org > Subject: Re: draft-ietf-ospf-segment-routing-extensions-03 > > Hi Shraddha, > > please see inline: > > On 12/16/14 18:31 , Shraddha Hegde wrote: >> Rob, >> >> Pls see inline.. >> >> -----Original Message----- >> From: rob.sha...@bt.com [mailto:rob.sha...@bt.com] >> Sent: Tuesday, December 16, 2014 10:11 PM >> To: Shraddha Hegde; ppse...@cisco.com; >> draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org >> Cc: ospf@ietf.org >> 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. > > <Shraddha>I think if the protocol extensions are flexible enough, no > checkpointing would be required and everything can be recovered from the > information learnt from neighbor. > > It is not only about "graceful restart", I find the > information to associate set label to a bundle missing. Think of an > application which has to look up the LSA database and build > An explicitly routed label stack using bundled > labels. If there are multiple adj-sid with "s bit set"originated by a node, > it's not easy to make a choice which set label to use! > Since there is no information about which label > corresponds to which bundle. Let's imagine you have 4 links (l1, l2, l3, l4) between R1 and R2. You split these to two sets on R1: S1(l1,l2) S1(l3,l4) On R1, for links in S1 you advertise Adj-SID 10 and for link in S2 you advertise Adj-SID 20. Any router looking at advertisement from R1 can clearly see the two sets. Am I missing something? <Shraddha> Lets say set S1 has some characteristic "X" and set S2 has characteristic "Y". Lets say we want to build explicit routed label stack which says " give me load balancing path using links with characteristic X". Lets say there is another set of nodes R3 and R4 and similar S1 and S2 bundles on them and R3 advertising label 30 and 40 for S1 and S2 Respectively. Labels are local to the nodes and we cannot use labels to identify what characteristic or set they stand for. .To satisfy the constraint whether to use label 10 Or 20 on R1 and whether to use 30 or 40 is a problem. The application which is trying to build the label stack cannot identify which label to use from R1 and R3 because there are sets and labels but which label Represents which set is missing. If there is an identifier for the set and this identifier comes with label it can be done easily. thanks, Peter > > I find the adj-sid set a very interesting and very > useful feature but find the OSPF/ISIS protocol extensions not flexible enough > to accommodate all the different ways > An operator may want to deploy bundles. > > >> >> 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" <shrad...@juniper.net>] >> >>> 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:ppse...@cisco.com] >>> Sent: Sunday, December 14, 2014 4:08 PM >>> To: Shraddha Hegde; >>> draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org >>> 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 OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
