On 28/03/2019 11:09 , Rajesh M wrote:
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 ?
yes.
If we specify an algorithm in SR-Algorithm sub-TLV, it means that algorithm is
supported for both SR as well as for SRV6 ?
yes, algo support is not data-plane specific.
Selectively we cannot specify supported algorithm for SR,SRV6.
no.
If you need a data-plane specific algo, you can define an algo that
would only include nodes from a specific data-plane.
thanks,
Peter
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
