Subject: [spring] draft-bashandy-isis-srv6-extensions-05.txt

From: Rajesh M <[email-masked]>
Date: Wed, 13 Mar 2019 06:02:23 +0000

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)

2)

SRv6 Endpoint Function already mentions Endpoint Function Types.

SID usually 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.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | SRv6 Endpoint Function |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (128 bits) . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (cont . . .) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (cont . . .) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (cont . . .) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

---

From: Peter Psenak <[email-masked]>
Date: Wed, 13 Mar 2019 13:42:43 +0100

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]
>

fair enough, will fix that in the next version.

> 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

---

From: Rajesh M <[email-masked]>
Date: Sun, 24 Mar 2019 04:50:55 +0000

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 ?

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-masked]> 
Sent: Wednesday, March 13, 2019 6:13 PM
To: Rajesh M <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: Ron Bonica <[email-masked]>; SPRING WG <[email-masked]>; [email-masked]
Subject: Re: draft-bashandy-isis-srv6-extensions-05.txt

Hi Rajesh,

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

---

From: Peter Psenak <[email-masked]>
Date: Sun, 24 Mar 2019 10:13:25 +0100

> 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

> .

---

From: Rajesh M <[email-masked]>
Date: Thu, 28 Mar 2019 10:09:13 +0000

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-masked]> 
Sent: Sunday, March 24, 2019 2:43 PM
To: Rajesh M <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: Ron Bonica <[email-masked]>; SPRING WG <[email-masked]>; [email-masked]
Subject: Re: draft-bashandy-isis-srv6-extensions-05.txt

> 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
>
>
>
>
>
>
>
> To: Rajesh M <[email-masked]>; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]

---

From: Peter Psenak <[email-masked]>
Date: Thu, 28 Mar 2019 12:00:48 +0100

> 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