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 Psenak <[e-mail]>]

Hi Bruno,


On 12/05/2021 09:51, [e-mail] 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

> 
> If the former, could you please spell out the interop issue?
> 
> Thanks,
> 
> Best regards,
> 
> --Bruno
> 
> *From:*Lsr [mailto:[e-mail]] *On Behalf Of *Gengxuesong 
> (Geng Xuesong)
> *Sent:* Wednesday, May 12, 2021 9:16 AM
> *To:* Les Ginsberg (ginsberg) <[e-mail]>; Shraddha Hegde 
> <shraddha=[e-mail]>; Alvaro Retana 
> <[e-mail]>; Peter Psenak (ppsenak) <[e-mail]>; 
> [e-mail]
> *Cc:* [e-mail]; [e-mail]; 
> Van De Velde, Gunter (Nokia - BE/Antwerp) <[e-mail]>
> *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,
> 
> 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:[e-mail]]
> *Sent:* Wednesday, May 12, 2021 6:29 AM
> *To:* Shraddha Hegde <shraddha=[e-mail] 
> <mailto:shraddha=[e-mail]>>; Alvaro Retana 
> <[e-mail] <mailto:[e-mail]>>; Peter Psenak 
> (ppsenak) <[e-mail] <mailto:[e-mail]>>; [e-mail] 
> <mailto:[e-mail]>; Gengxuesong (Geng Xuesong) 
> <[e-mail] <mailto:[e-mail]>>
> *Cc:* [e-mail] <mailto:[e-mail]>; 
> [e-mail] 
> <mailto:[e-mail]>; Van De Velde, 
> Gunter (Nokia - BE/Antwerp) <[e-mail] 
> <mailto:[e-mail]>>
> *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.
> 
> 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 <[e-mail] <mailto:[e-mail]>> *On 
> Behalf Of *Shraddha Hegde
> *Sent:* Tuesday, May 11, 2021 8:21 AM
> *To:* Alvaro Retana <[e-mail] 
> <mailto:[e-mail]>>; Peter Psenak (ppsenak) 
> <[e-mail] <mailto:[e-mail]>>; [e-mail] 
> <mailto:[e-mail]>
> *Cc:* [e-mail] <mailto:[e-mail]>; 
> [e-mail] 
> <mailto:[e-mail]>; Van De Velde, 
> Gunter (Nokia - BE/Antwerp) <[e-mail] 
> <mailto:[e-mail]>>
> *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
> 
> 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 <[e-mail] <mailto:[e-mail]>> *On 
> Behalf Of *Alvaro Retana
> *Sent:* Friday, May 7, 2021 7:23 PM
> *To:* Peter Psenak <[e-mail] <mailto:[e-mail]>>; 
> [e-mail] <mailto:[e-mail]>
> *Cc:* [e-mail] <mailto:[e-mail]>; 
> [e-mail] 
> <mailto:[e-mail]>; Van De Velde, 
> Gunter (Nokia - BE/Antwerp) <[e-mail] 
> <mailto:[e-mail]>>
> *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]*
> 
> On May 3, 2021 at 5:17:58 AM, Peter Psenak wrote:
> 
>> 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.
> 
> 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 ([e-mail] 
> <mailto:[e-mail]>) wrote:
> 
>     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/ 
>     > 
> 
> _________________________________________________________________________________________________________________________
> 
> 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.
>