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 10:24, [e-mail] wrote:
> Hi Peter,
> 
> Thanks for the answer.
> Please see inline.
> 
>> From: Peter Psenak [mailto:[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.
> 
> 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.

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


> 
> Thanks for the discussion,
> --Bruno
> 
>> 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.
>>>
> 
> 
> _________________________________________________________________________________________________________________________
> 
> 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.
> 
> 
>