Re: [Lsr] Last Call: <draft-ietf-lsr-isis-srv6-extensions-14.txt> (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard

Hi Gunter,

Prefix Attribute Flags Sub-TLV has been defined as an optional Sub-TLV. 
The problem you describe is not specific to Locator TLV, same applies to 
regular IPv4/v6 prefixes (forget SR MPLS for a while) - if the Prefix 
Attribute Flags TLV is not included, one can not tell whether the prefix 
has been propagated (L1->L2) or generated as a result of the local 
interface attached on the originator. Same applies to redistribution and 
R-flag for IPv4 prefix TLVs.

SRv6 Locator TLV has been defined a while back and the Prefix Attribute 
Flags Sub-TLV has always been an optional Sub-TLV of it. I'm not sure we 
can start to mandate the Prefix Attribute Flags TLV at this point.

Technically I agree with you and if everybody agrees, I'm fine to 
enforce the presence of the Prefix Attribute Flags TLV in the Locator TLV.

thanks,
Peter

On 03/05/2021 10:45, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:
> Hi Peter, All,
> 
> Could we update to "draft-ietf-lsr-isis-srv6-extensions" that the prefix-attribute tlv is mandatory when a locator is redistributed?
> 
> Why?
> *When calculating a LFA for an SRv6 End.SID we better know if the locator has been redistributed or not for a correct operation.
> 
> Reasoning:
> * A locator has the D bit. This one is set when we redistribute from L2 to L1.
> ** So this end-sid will not be used as we know that it is redistributed.
> 
> * In the other direction (L1-L2), we only know that a locator is redistributed from L1 to L2 if the prefix-attribute sub-tlv is advertised.
> ** This means if the operator does not configure advertisement of the prefix-attribute tlv, ISIS could potentially use an end-sid which does not terminate on the expected  node.
> 
> * Compared to sr-mpls, a prefix-sid has the R flag indicating it is redistributed.
> * We don't have that for locator end-sids.
> 
> Relevant snip from " draft-ietf-lsr-isis-srv6-extensions"
> 
> 7.1.  SRv6 Locator TLV Format
> 
>     The SRv6 Locator TLV has the following format:
> 
>         0                   1                   2                   3
>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |   Type        |     Length    |R|R|R|R|    MT ID              |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>        Type: 27
> 
>          Length: variable.
> 
>          R bits: reserved for future use. They MUST be
>          set to zero on transmission and MUST be ignored on receipt.
> 
>          MT ID: Multitopology Identifier as defined in [RFC5120].
>          Note that the value 0 is legal.
> 
>     Followed by one or more locator entries of the form:
> 
>         0                   1                   2                   3
>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                          Metric                               |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |   Flags       |  Algorithm    |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |  Loc Size     | Locator (variable)...
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |  Sub-TLV-len  |         Sub-TLVs (variable) . . .             |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
>          Metric: 4 octets. As described in [RFC5305].
> 
>          Flags: 1 octet. The following flags are defined
> 
>            0
>            0 1 2 3 4 5 6 7
>           +-+-+-+-+-+-+-+-+
>           |D|    Reserved |
>           +-+-+-+-+-+-+-+-+
> 
>           where:
>             D-flag: Same as described in section 4.1. of [RFC5305].
> 
> 
> G/
> 
> -----Original Message-----
> From: Lsr <lsr-bounces@ietf.org> On Behalf Of The IESG
> Sent: Thursday, April 22, 2021 10:14 PM
> To: IETF-Announce <ietf-announce@ietf.org>
> Cc: lsr@ietf.org; lsr-chairs@ietf.org; chopps@chopps.org; draft-ietf-lsr-isis-srv6-extensions@ietf.org; aretana.ietf@gmail.com
> Subject: [Lsr] Last Call: <draft-ietf-lsr-isis-srv6-extensions-14.txt> (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard
> 
> 
> The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'IS-IS Extension to Support Segment Routing over IPv6 Dataplane'
>    <draft-ietf-lsr-isis-srv6-extensions-14.txt> as Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2021-05-07. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>     The Segment Routing (SR) allows for a flexible definition of end-to-
>     end paths by encoding paths as sequences of topological sub-paths,
>     called "segments".  Segment routing architecture can be implemented
>     over an MPLS data plane as well as an IPv6 data plane.  This document
>     describes the IS-IS extensions required to support Segment Routing
>     over an IPv6 data plane.
> 
>     This documents updates RFC 7370 by modifying an existing registry.
> 
> 
> 
> 
> 
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/
> 
> 
> The following IPR Declarations may be related to this I-D:
> 
>     https://datatracker.ietf.org/ipr/3796/
>     https://datatracker.ietf.org/ipr/4486/
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
> 
> 