Subject: 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

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Mon, 3 May 2021 08:45:41 +0000

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 <[email-masked]> On Behalf Of The IESG
Sent: Thursday, April 22, 2021 10:14 PM
To: IETF-Announce <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
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 [email-masked] mailing lists by 2021-05-07. Exceptionally, comments may be sent to [email-masked] 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
[email-masked]
https://www.ietf.org/mailman/listinfo/lsr

---

From: Peter Psenak <[email-masked]>
Date: Mon, 3 May 2021 11:17:56 +0200

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

---

From: Alvaro Retana <[email-masked]>
Date: Fri, 7 May 2021 06:52:39 -0700

> enforce the presence of the Prefix Attribute Flags TLV in the Locator TLV.

So...what does everyone else think?

We need to close on this point before the IESG evaluates the document.  I'm
requesting it to be put on the May/20 telechat, which means that we should
have a resolution and updated draft by the end of next week.

Thanks!

Alvaro.

On May 3, 2021 at 5:17:58 AM, Peter Psenak ([email-masked]) wrote:

Hi Gunter,

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.
> * 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.

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 7 May 2021 13:59:42 +0000

Hi Peter,

I agree that the support for the Prefix Attribute Flags TLV is required in the Locator TLV.

Thanks,
Ketan

From: Lsr <[email-masked]> On Behalf Of Alvaro Retana
Sent: 07 May 2021 19:23
To: Peter Psenak (ppsenak) <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]>
Subject: 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

We need to close on this point before the IESG evaluates the document.  I'm requesting it to be put on the May/20 telechat, which means that we should have a resolution and updated draft by the end of next week.

Thanks!

Alvaro.

On May 3, 2021 at 5:17:58 AM, Peter Psenak ([email-masked]<mailto:[email-masked]>) wrote:
Hi Gunter,

thanks,
Peter

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 7 May 2021 16:52:21 +0000

As has been mentioned in this thread, the need for the prefix-attributes sub-TLV to correctly process leaked advertisements is not unique to the Locator TLV. The reason prefix-attributes TLV was created was to address the same gap with IP/IPv6 reachability advertisements.
And I think by now implementations (certainly ones that support newer functionality like SRv6) should have added support for prefix-attributes sub-TLV .

In the case of the Locator TLV  – since this is new functionality – we have the option of mandating prefix-attributes sub-TLV – something we could not do with IP/IPv6 Reachability since that has been deployed for many years.

But,  please recognize two consequences of the MUST option:

1)Implementations may have to deal w  backwards compatibility w early deployments of SRv6. This would only be an issue if there are implementations that currently do NOT send prefix-attributes sub-TLV w Locator TLV.
Are there any such implementations??

2)In the case where the deployment is a single level, it could be argued that prefix-attributes sub-TLV isn’t needed.
I personally would NOT make such an argument, but we should understand that MUST applies to this case as well.

If everyone is OK with these consequences (personally I am OK) then I think it is fine to go with MUST.

   Les

From: Lsr <[email-masked]> On Behalf Of Ketan Talaulikar (ketant)
Sent: Friday, May 07, 2021 7:00 AM
To: Alvaro Retana <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]>
Subject: 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 Peter,

Thanks,
Ketan

From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of Alvaro Retana
Sent: 07 May 2021 19:23
To: Peter Psenak (ppsenak) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]<mailto:[email-masked]>>
Subject: 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

Thanks!

Alvaro.

thanks,
Peter

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 7 May 2021 17:06:22 +0000

Speaking as WG contributor:

From: Lsr <[email-masked]> on behalf of "Les Ginsberg (ginsberg)" <ginsberg=[email-masked]>
Date: Friday, May 7, 2021 at 12:53 PM
To: "Ketan Talaulikar (ketant)" <ketant=[email-masked]>, Alvaro Retana <[email-masked]>, "Peter Psenak (ppsenak)" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: Christian Hopps <[email-masked]>, "[email-masked]" <[email-masked]>, Gunter Van de Velde <[email-masked]>
Subject: 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

I’m fine with these consequences. Better to fix this now and not use the SRv6 Prefix non-deterministically.

Thanks,
Acee

   Les

Hi Peter,

Thanks,
Ketan

Thanks!

Alvaro.

thanks,
Peter

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 7 May 2021 10:20:39 -0700

+1

Cheers,
Jeff

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Tue, 11 May 2021 06:29:56 +0000

Hi Les,

Thanks for mentioning the compatibility issue. The prefix-attributes sub-TLV is not supported in the existing implementation of SRv6 ISIS in Huawei device.
So maybe we should be more cautious before deciding to change it from optional to mandatory.

Best
Xuesong

From: Lsr [mailto:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Saturday, May 8, 2021 12:52 AM
To: Ketan Talaulikar (ketant) <ketant=[email-masked]>; Alvaro Retana <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]>
Subject: 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

   Les

From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of Ketan Talaulikar (ketant)
Sent: Friday, May 07, 2021 7:00 AM
To: Alvaro Retana <[email-masked]<mailto:[email-masked]>>; Peter Psenak (ppsenak) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]<mailto:[email-masked]>>
Subject: 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 Peter,

Thanks,
Ketan

Thanks!

Alvaro.

thanks,
Peter

---

From: Shraddha Hegde <[email-masked]>
Date: Tue, 11 May 2021 15:21:10 +0000

Juniper has an  implementation of SRv6 that does not support Prefix attributes sub-tlv in locator TLV.
We would prefer not to change the optional sub-TLV to MUST.

Rgds
Shraddha

Juniper Business Use Only
From: Lsr <[email-masked]> On Behalf Of Alvaro Retana
Sent: Friday, May 7, 2021 7:23 PM
To: Peter Psenak <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]>
Subject: 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

[External Email. Be cautious of content]

Thanks!

Alvaro.

thanks,
Peter

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 11 May 2021 22:29:27 +0000

Shraddha/ Xuesong -

Since Prefix Attributes sub-TLV is required for correct operation when a Locator is leaked, would it be safe to assume that your implementations either do not leak Locators or you advise your customers not to deploy this feature with multiple levels?

The problem with allowing the sub-TLV to be optional is that if the sub-TLV is omitted you cannot tell whether the Locator has been leaked - so you don't know whether you have a problem or not.

The safest thing to do is require prefix-attributes sub-TLV always - then you can guarantee that if the prefix is leaked the necessary information will be present.
Anything else leaves us vulnerable.

We all appreciate interoperability considerations, but frankly this is a gap that needs to be closed to support correct operation.

   Les

From: Lsr <[email-masked]> On Behalf Of Shraddha Hegde
Sent: Tuesday, May 11, 2021 8:21 AM
To: Alvaro Retana <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]>
Subject: 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

Rgds
Shraddha

To: Peter Psenak <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Thanks!

Alvaro.

thanks,
Peter

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Wed, 12 May 2021 07:16:21 +0000

Hi Les,

Prefix Attributes sub-TLV is necessary when locator is leaked.
So we are not against Prefix Attribute sub-TLV implementation. We just propose to keep it optional ("should" rather than "must") for interoperability.

Best
Xuesong

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Wednesday, May 12, 2021 6:29 AM
To: Shraddha Hegde <shraddha=[email-masked]>; Alvaro Retana <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>; [email-masked]; Gengxuesong (Geng Xuesong) <[email-masked]>
Cc: [email-masked]; [email-masked]; Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]>
Subject: 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

Shraddha/ Xuesong -

   Les

From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of Shraddha Hegde

Rgds
Shraddha

Thanks!

Alvaro.

thanks,
Peter

---

From: <[email-masked]>
Date: Wed, 12 May 2021 07:51:55 +0000

Hi Xuesong,

Clarification question: are you talking about interoperability (between two nodes) or compliancy (between an implementation and the RFC)?
If the former, could you please spell out the interop issue?

Thanks,
Best regards,
--Bruno

From: Lsr [mailto:[email-masked]] On Behalf Of Gengxuesong (Geng Xuesong)
Sent: Wednesday, May 12, 2021 9:16 AM
To: Les Ginsberg (ginsberg) <[email-masked]>; Shraddha Hegde <shraddha=[email-masked]>; Alvaro Retana <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]>
Subject: 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 Les,

Best
Xuesong

To: Shraddha Hegde <shraddha=[email-masked]<mailto:shraddha=[email-masked]>>; Alvaro Retana <[email-masked]<mailto:[email-masked]>>; Peter Psenak (ppsenak) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Gengxuesong (Geng Xuesong) <[email-masked]<mailto:[email-masked]>>

Shraddha/ Xuesong -

   Les

Rgds
Shraddha

Thanks!

Alvaro.

thanks,
Peter

> The SRv6 Locator TLV has the following format:

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Peter Psenak <[email-masked]>
Date: Wed, 12 May 2021 10:00:38 +0200

Hi Bruno,

On 12/05/2021 09:51, [email-masked] wrote:
> Hi Xuesong,
> 
> Clarification question: are you talking about interoperability (between 
> two nodes) or compliancy (between an implementation and the RFC)?

I'm afraid the two are related. If we mandate the Prefix Attribute
Sub-TLV inside the Locator TLV, we would have to say that the Locator 
TLV without the Prefix Attribute Sub-TLV MUST be ignored. As a result, 
implementations that do not send the Prefix Attribute Sub-TLV would not 
just be not compliant, but would also not interoperate with the ones 
that follow the specification.

thanks,
Peter

> *From:*Lsr [mailto:[email-masked]] *On Behalf Of *Gengxuesong 
> (Geng Xuesong)
> *Sent:* Wednesday, May 12, 2021 9:16 AM
> *To:* Les Ginsberg (ginsberg) <[email-masked]>; Shraddha Hegde 
> <shraddha=[email-masked]>; Alvaro Retana 
> <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>; 
> [email-masked]
> *Cc:* [email-masked]; [email-masked]; 
> Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]>
> *Subject:* 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 Les,
> 
> So we are not against Prefix Attribute sub-TLV implementation. We just 
> propose to keep it optional (“should” rather than “must”) for 
> interoperability.
> 
> Best
> 
> Xuesong
> 
> *From:*Les Ginsberg (ginsberg) [mailto:[email-masked]]
> *Sent:* Wednesday, May 12, 2021 6:29 AM
> *To:* Shraddha Hegde <shraddha=[email-masked] 
> <mailto:shraddha=[email-masked]>>; Alvaro Retana 
> <[email-masked] <mailto:[email-masked]>>; Peter Psenak 
> (ppsenak) <[email-masked] <mailto:[email-masked]>>; [email-masked] 
> <mailto:[email-masked]>; Gengxuesong (Geng Xuesong) 
> <[email-masked] <mailto:[email-masked]>>
> *Cc:* [email-masked] <mailto:[email-masked]>; 
> [email-masked] 
> <mailto:[email-masked]>; Van De Velde, 
> Gunter (Nokia - BE/Antwerp) <[email-masked] 
> <mailto:[email-masked]>>
> *Subject:* 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
> 
> Shraddha/ Xuesong –
> 
> Since Prefix Attributes sub-TLV is required for correct operation when a 
> Locator is leaked, would it be safe to assume that your implementations 
> either do not leak Locators or you advise your customers not to deploy 
> this feature with multiple levels?
> 
> The problem with allowing the sub-TLV to be optional is that if the 
> sub-TLV is omitted you cannot tell whether the Locator has been leaked – 
> so you don’t know whether you have a problem or not.
> 
> The safest thing to do is require prefix-attributes sub-TLV always – 
> then you can guarantee that if the prefix is leaked the necessary 
> information will be present.
> 
> We all appreciate interoperability considerations, but frankly this is a 
> gap that needs to be closed to support correct operation.
> 
>     Les
> 
> *From:*Lsr <[email-masked] <mailto:[email-masked]>> *On 
> Behalf Of *Shraddha Hegde
> *Sent:* Tuesday, May 11, 2021 8:21 AM
> *To:* Alvaro Retana <[email-masked] 
> <mailto:[email-masked]>>; Peter Psenak (ppsenak) 
> <[email-masked] <mailto:[email-masked]>>; [email-masked] 
> <mailto:[email-masked]>
> *Cc:* [email-masked] <mailto:[email-masked]>; 
> [email-masked] 
> <mailto:[email-masked]>; Van De Velde, 
> Gunter (Nokia - BE/Antwerp) <[email-masked] 
> <mailto:[email-masked]>>
> *Subject:* 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
> 
> *From:*Lsr <[email-masked] <mailto:[email-masked]>> *On 
> Behalf Of *Alvaro Retana
> *Sent:* Friday, May 7, 2021 7:23 PM
> *To:* Peter Psenak <[email-masked] <mailto:[email-masked]>>; 
> [email-masked] <mailto:[email-masked]>
> *Cc:* [email-masked] <mailto:[email-masked]>; 
> [email-masked] 
> <mailto:[email-masked]>; Van De Velde, 
> Gunter (Nokia - BE/Antwerp) <[email-masked] 
> <mailto:[email-masked]>>
> *Subject:* 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
> 
> *[External Email. Be cautious of content]*
> 
> We need to close on this point before the IESG evaluates the document.  
> I'm requesting it to be put on the May/20 telechat, which means that we 
> should have a resolution and updated draft by the end of next week.
> 
> Thanks!
> 
> Alvaro.
>

---

From: <[email-masked]>
Date: Wed, 12 May 2021 08:24:47 +0000

Hi Peter,

Thanks for the answer.
Please see inline.

> From: Peter Psenak [mailto:[email-masked]]
> 
> Hi Bruno,
> 
> 
> TLV without the Prefix Attribute Sub-TLV MUST be ignored. 

Mandating the advertisement is one thing (if it's useful, not to mention required, let's advertise it).
Then why would we have to say that the Locator TLV without the Prefix Attribute Sub-TLV MUST be ignored ? On the receiver side, a priori, current spec allows for both (presence & non-presence), no? That seem like an error handling situation that we can choose.

Thanks for the discussion,
--Bruno

> As a result,
> >     > 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:
> __________________________________________________________
> __________________________________________________________
> _____
> >
> > Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> > This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: Peter Psenak <[email-masked]>
Date: Wed, 12 May 2021 10:29:02 +0200

Hi Bruno,

> Then why would we have to say that the Locator TLV without the Prefix Attribute Sub-TLV MUST be ignored ? On the receiver side, a priori, current spec allows for both (presence & non-presence), no?…

if we mandate something we need to say what happens when the mandated 
data is not present - typically we ignore. If we don't ignore, then we 
are not really mandating it.

thanks,
Peter

---

From: <[email-masked]>
Date: Wed, 12 May 2021 08:43:53 +0000

Hi Peter,

> > Then why would we have to say that the Locator TLV without the Prefix
> Attribute Sub-TLV MUST be ignored ? On the receiver side, a priori, current
> spec allows for both (presence & non-presence), no? That seem like an error
> handling situation that we can choose.
> 
> data is not present 

Absolutely. I could not agree more.
I call this error handling.

>- typically we ignore. 
OK, but here we seem free to define "whatever" error handling we want since current version of the draft allows for both presence or non-presence.

Thanks,
--Bruno

> If we don't ignore, then we
> prefix-
> >>>      > * A locator has the D bit. This one is set when we redistribute from
> L2 to
> >> L1.
> >>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
> ce
> >> message par erreur, veuillez le signaler
> >>> Orange decline toute responsabilite si ce message a ete altere, deforme
> ou
> >> falsifie. Merci.
> >>>
> >>> If you have received this email in error, please notify the sender and
> delete
> >> this message and its attachments.
> >>> As emails may be altered, Orange is not liable for messages that have
> been
> >> modified, changed or falsified.
> >>> Thank you.
> >>>
> >
> >
> >

---

From: Peter Psenak <[email-masked]>
Date: Wed, 12 May 2021 10:49:56 +0200

Hi Bruno,

> OK, but here we seem free to define "whatever" error handling we want since current version of the draft allows for both presence or non-presence.

as I said, if we want to mandate the presence of the Prefix Attribute 
sub-TLV, we MUST ignore Locators without it. If we don't, then the MUST 
on the originator does not mean anything.

thanks,
Peter

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 12 May 2021 07:16:37 -0700

Peter:

Hi!

As Xuesong suggested earlier, could you/we live with “SHOULD send”?
The mitigating circumstance (recommend vs require) is precisely the
lack of support.  I think your original reply to Gunter about how it
could be hard to mandate the Flags TLV at this point is spot on.

Thanks!

Alvaro.

---

From: Shraddha Hegde <[email-masked]>
Date: Wed, 12 May 2021 15:08:48 +0000

Les,

I don't agree with mandating prefix attributes sub-TLV in locator TLV at this stage of publication
when there are multiple implementations that don't originate it.
There are usecases that can be deployed without prefix attributes sub-TLV.

I propose that we clarify the specific usecases that require prefix attributes sub-TLVs to be associated with locator TLV. For example, we should add the TI-LFA with leaked locators across multiple levels that Gunter pointed out,
and add a statement that prefix attributes sub-tlv SHOULD be originated in locator TLV
for this usecase to be supported.

Rgds
Shraddha

Juniper Business Use Only
From: Les Ginsberg (ginsberg) <ginsberg=[email-masked]>
Sent: Wednesday, May 12, 2021 3:59 AM
To: Shraddha Hegde <[email-masked]>; Alvaro Retana <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>; [email-masked]; Gengxuesong (Geng Xuesong) <[email-masked]>
Cc: [email-masked]; [email-masked]; Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]>
Subject: 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

Shraddha/ Xuesong -

   Les

Rgds
Shraddha

Thanks!

Alvaro.

thanks,
Peter

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 12 May 2021 15:33:19 +0000

Alvaro (and everyone) - 

I think we can do better than this.

Prefix-attributes sub-TLV is necessary when a prefix is leaked between levels - and more specifically when leaked upwards in the hierarchy.
(We have the "D" bit in the TLV itself when leaked downwards.)

While I would prefer that we simplify things and simply require the sub-TLV all the time, I think we can be more generous and still be functional.

1)Prefix-attributes SHOULD be included in Locator TLV
2)Prefix-attributes MUST be included when TLV is leaked upwards in the hierarchy
3)Prefix-attributes sub-TLV MUST be included when the advertisement is "redistributed" from another protocol

Note that because the sub-TLV is not mandatory, if #2 and #3 are NOT followed, receivers will be unable to determine the correct source of the advertisement and may do the "wrong thing". And the receivers will be unable to detect the violation.

Finally, RFC 7794 was published over 5 years ago.
Vendors make their own choices as to what protocol extensions they choose to support. But given the usefulness of the information in prefix-attributes sub-TLV I would encourage implementations which do not yet support the sub-TLV to add it.

   Les

> From: Alvaro Retana <[email-masked]>
> Sent: Wednesday, May 12, 2021 7:17 AM
> To: Gengxuesong (Geng Xuesong) <[email-masked]>; Peter
> Psenak (ppsenak) <[email-masked]>; [email-masked]
> Cc: Van De Velde, Gunter (Nokia - BE/Antwerp)
> <[email-masked]>; draft-ietf-lsr-isis-srv6-
> [email-masked]; Les Ginsberg (ginsberg) <[email-masked]>;
> Shraddha Hegde <shraddha=[email-masked]>; [email-masked];
> [email-masked]
> Subject: 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
> 
> Peter:
> 
> 
> Hi!
>

---

From: Peter Psenak <[email-masked]>
Date: Fri, 14 May 2021 18:32:32 +0200

Hi,

I'm fine with the below.

Do folks have any concerns with the below, or can I update the draft?

Please speak up if you disagree.

thanks,
Peter