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

[[e-mail]]

Hi Peter,

> From: Peter Psenak [mailto:[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 

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


_________________________________________________________________________________________________________________________

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.