One more query guys 😊 draft-bashandy-isis-srv6-extensions-05.txt says: Section 3. Advertising Supported Algorithms SRv6 capable router indicates supported algorithm(s) by advertising the SR Algorithm sub TLV as defined in [I-D.ietf-isis-segment-routing-extensions].
https://tools.ietf.org/pdf/draft-ietf-isis-segment-routing-extensions-22.pdf: "The SR-Algorithm sub-TLV is optional, it MAY only appear a single time inside the Router Capability TLV" So we have only one SR-algorithm sub-TLV for SRV6 as well as for SR ? If we specify an algorithm in SR-Algorithm sub-TLV, it means that algorithm is supported for both SR as well as for SRV6 ? Selectively we cannot specify supported algorithm for SR,SRV6. Juniper Internal -----Original Message----- From: Peter Psenak <[email protected]> Sent: Sunday, March 24, 2019 2:43 PM To: Rajesh M <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected] Cc: Ron Bonica <[email protected]>; SPRING WG <[email protected]>; [email protected] Subject: Re: draft-bashandy-isis-srv6-extensions-05.txt On 24/03/2019 05:50 , Rajesh M wrote: > Thanks peter for response.one query > > As per draft > "Each locator is a covering prefix for all SIDs provisioned on that node > which have the matching topology/algorithm" > > So this means one locator per Topology/Algorithm ? Locator is scoped per algo and topology. You can have multiple Locators for the same algo/topo pair. thanks, Peter > > > My opinion is we should have multiple locator per topology/algorithm > (One Main locator and rest N Anycast locator based upon requirements. N can > be zero,1,2...etc) Any cast flag should be set on Anycast locator. Main > locator should be used as Node SID (I mean SIDS under Main locator). > > Thanks > Rajesh > > > > > > > > -----Original Message----- > From: Peter Psenak <[email protected]> > Sent: Wednesday, March 13, 2019 6:13 PM > To: Rajesh M <[email protected]>; [email protected]; > [email protected]; [email protected]; > [email protected] > Cc: Ron Bonica <[email protected]>; SPRING WG <[email protected]>; > [email protected] > Subject: Re: draft-bashandy-isis-srv6-extensions-05.txt > > Hi Rajesh, > > > On 13/03/2019 07:02 , Rajesh M wrote: >> 1) >> >> SRv6 Endpoint Function: 2 octets. As defined in >> [I-D.filsfils-spring-srv6-network-programming] >> >> Legal function values for this sub-TLV are defined in Section 7. >> >> >> >> This should be Section 8 I think, section 8 contains Advertising >> Endpoint Behaviors. >> >> Al reference to section 7 , we must change to section 8 (4 places) >> > > fair enough, will fix that in the next version. > >> >> >> 2) >> >> >> >> SRv6 Endpoint Function already mentions Endpoint Function Types. >> >> >> >> SIDusually will be a combination of Locator:Function:ARGS. >> >> >> >> Since SID already contains Function, why there is a need for >> additional >> SRv6 Endpoint Function field ? Am I missing something. > > > SRv6 Endpoint Function represents the behavior, which comes from > "SRv6 Endpoint Behaviors Registry". That value is not present in the 128 bits > SID value, which is locally assigned by the advertising node. > > thanks, > Peter > > > > > >> >> >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> | Flags | SRv6 Endpoint Function | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> | SID (128 bits) . . . | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> | SID (cont . . .) | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> | SID (cont . . .) | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> | SID (cont . . .) | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> > > . > _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
