Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

[Chris Bowers <[e-mail]>]

 All,

I'm forwarding this question and subsequent response to the list because it
looks like I accidentally sent it only to Peter before.

Chris

On Sat, Feb 8, 2020 at 3:25 AM Peter Psenak <[e-mail]> wrote:

> Hi Chris,
>
> On 07/02/2020 23:15, Chris Bowers wrote:
> > Peter,
> >
> > Thanks for the clarification.
> >
> > Can you also clarify how a receiver should interpret a locator
> > advertisement that doesn't have a corresponding RFC7794 advertisement?
> >
> > Modifying the example below,  suppose I receive a locator advertisement
> > from router R7 with locator = 7777::/64 and End-SID 7777::1, but R7
> > doesn't originate an RFC7794 advertisement for 7777::/64.  Can I
> > conclude that 7777::/64 is not Anycast, so it can be used as a Node-SID
> > when constructing TE paths as discussed below ?
>
> yes. That's the only reasonable choice.
>
> Implementation may also check if the same locator is not advertised by
> some other node in addition. But I would not mandate that in the spec.
>
> thanks,
> Peter
> >
> > Thanks,
> > Chris
> >
> > On Wed, Feb 5, 2020 at 5:28 AM Peter Psenak <[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> >     Hi Chris,
> >
> >     On 04/02/2020 23:17, Chris Bowers wrote:
> >      > Peter,
> >      >
> >      > Suppose I receive a locator advertisement from router R7 with
> >      > locator = 7777::/64 and End-SID 7777::1.  I would like to be able
> >     to use
> >      > End-SID 7777::1 as
> >      > a Node-SID when constructing traffic engineered paths.  That is,
> >     I want
> >      > to know that
> >      > the person or system that configured R7 believes that 7777::/64
> >      > is NOT owned by more than one router within the same routing
> domain.
> >
> >     ##PP
> >     sure, if the A-bit is not set, you should be fine to pick the SID
> >     from a
> >     locator. Please see below why.
> >
> >      >
> >      > Since we are going with Interpretation I) below, a prefix can be
> >     (a) a
> >      > Node Prefix, (b) an Anycast Prefix,
> >      > or (c) neither of them.
> >
> >     ##PP
> >     above is correct in general.
> >
> >     However, given that locator is non-/128, N-bit does not apply per
> >     RFC7794. So for a locator you only have (b) or (c) and you would only
> >     want to avoid (b) for what you want to do above.
> >
> >
> >      > If I receive an RFC7794 advertisement from R7
> >      > for 7777::/64 with N=0, A=0,
> >      > I can only conclude that 7777::/64 is either (a) a Node Prefix or
> >     (c)
> >      > neither a Node Prefix nor an
> >      > Anycast Prefix. Using the N-flag for a non-/128 would allow us to
> >      > unambiguously indicate that
> >      > 7777::/64 is a Node Prefix, so we can use the associated End-SID
> >     7777::1
> >      > in a manner
> >      > consistent with the knowledge that 7777::/64 is NOT owned by more
> >     than
> >      > one router
> >      > within the same routing domain.
> >      >
> >      > One other small point relates to the statement below that
> >     "locators are
> >      > never /128".
> >      > I don't think it would be very useful to configure a /128
> >     locator, since
> >      > it only has
> >      > space for one SRv6 SID.   However, the current text of
> >      > draft-ietf-lsr-isis-srv6-extensions explicitly
> >      > allows the Loc-Size to be 1-128.
> >
> >     ##PP
> >     agree, but I don't believe we need to put any special text to state
> the
> >     above, it's obvious.
> >
> >     thanks,
> >     Peter
> >      >
> >      > Thanks,
> >      > Chris
> >      >
> >      > On Tue, Feb 4, 2020 at 2:44 AM Peter Psenak <[e-mail]
> >     <mailto:[e-mail]>
> >      > <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
> >      >
> >      >     Hi Chris,
> >      >
> >      >     On 03/02/2020 14:39, Peter Psenak wrote:
> >      >      >> I think a reasonable solution would be to remove the
> >     restriction
> >      >      >>
> >      >      >> on the N-flag to allow it to be used for non-/128
> >      >     prefixes/locators.  This
> >      >      >>
> >      >      >> would allow the three possible prefix-SIDs states to be
> >     easily
> >      >     represented.
> >      >      > ##PP
> >      >      > right, that could be a possibility, which would allow SRv6
> >     locator to
> >      >      > have the "node" property, as locators are never /128.
> >      >
> >      >     do you have a use case, where the locator would need a N-flag?
> >      >
> >      >     I can not really think of any, so unless we have one, we
> >     better not
> >      >     define an N-flag for a non-/128 locator prefix.
> >      >
> >      >     thanks,
> >      >     Peter
> >      >
> >      > On Mon, Feb 3, 2020 at 7:39 AM Peter Psenak <[e-mail]
> >     <mailto:[e-mail]>
> >      > <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
> >      >
> >      >     Hi Chris,
> >      >
> >      >     adding to what Les has said.
> >      >     Please see inline (##PP)
> >      >
> >      >     On 31/01/2020 21:10, Chris Bowers wrote:
> >      >      > Peter and Les,
> >      >      >
> >      >      > It seems to me that for the Node Flag in RFC7794 and the
> >     proposed
> >      >      > Anycast Flag
> >      >      >
> >      >      > in draft-ietf-lsr-isis-srv6-extensions-04, we are
> ultimately
> >      >     concerned with
> >      >      >
> >      >      > how to identify IGP-Node Segments and IGP-Anycast
> Segments, as
> >      >     defined
> >      >      > in RFC8402,
> >      >      >
> >      >      > the Segment Routing Architecture document.
> >      >      >
> >      >      > If this is the case, then the following text from RFC8402
> >     is very
> >      >     relevant.
> >      >      >
> >      >      > ============
> >      >      >
> >      >      > 3.2.  IGP-Node Segment (Node-SID)
> >      >      >
> >      >      >     An IGP Node-SID MUST NOT be associated with a prefix
> >     that is
> >      >     owned by
> >      >      >
> >      >      >     more than one router within the same routing domain..
> >      >      >
> >      >      > 3.3.  IGP-Anycast Segment (Anycast-SID)
> >      >      >
> >      >      >     ....
> >      >      >
> >      >      >     An IGP-Anycast segment MUST NOT reference a particular
> >     node.
> >      >      >
> >      >      >     .....
> >      >      >
> >      >      > ============
> >      >      >
> >      >      > This text can be interpreted in two different ways.
> >      >      >
> >      >      > Interpretation I)
> >      >      >
> >      >      > A prefix-SID can have the following three possible states.
> >      >      >
> >      >      > Ia) Node-SID
> >      >      >
> >      >      > Ib) Anycast-SID
> >      >      >
> >      >      > Ic) neither Node-SID nor Anycast-SID
> >      >
> >      >     ##PP
> >      >     Prefix can either be Node Prefix, Anycast Prefix or neither
> >     of them.
> >      >
> >      >
> >      >      >
> >      >      > Interpretation II)
> >      >      >
> >      >      > A prefix-SID can have the following two possible states.
> >      >      >
> >      >      > IIa) Node-SID
> >      >      >
> >      >      > IIb) Anycast-SID
> >      >      >
> >      >      > If Interpretation I) is correct, then I think that the
> current
> >      >     encodings in
> >      >      >
> >      >      > draft-ietf-lsr-isis-srv6-extensions-04 do not allow us
> >      >      >
> >      >      > to unambiguously identify a Node-SID for a non-/128
> >      >      >
> >      >      > prefix/locator.  For example, the End-SIDs within a /64
> >     locator
> >      >     with the
> >      >      > A-flag set could
> >      >      >
> >      >      > either be Ia) a Node-SID
> >      >
> >      >     ##PP
> >      >     rfc7794 does not allow the N-flag to be set for non-/128
> >     prefix, so
> >      >     above is not possible for /64 locator at the moment.
> >      >
> >      >     If the A-flag is set, it is an anycast locator.
> >      >
> >      >
> >      >
> >      >      >or Ic) neither Node-SID nor Anycast-SID.
> >      >
> >      >     ##PP
> >      >     if the A-flag was not set for /64 locator, above would be
> >     correct, but
> >      >     given that the A-flag is set, it is clearly just Anycast
> locator.
> >      >
> >      >      >
> >      >      > I think a reasonable solution would be to remove the
> >     restriction
> >      >      >
> >      >      > on the N-flag to allow it to be used for non-/128
> >      >     prefixes/locators.  This
> >      >      >
> >      >      > would allow the three possible prefix-SIDs states to be
> easily
> >      >     represented.
> >      >
> >      >     ##PP
> >      >     right, that could be a possibility, which would allow SRv6
> >     locator to
> >      >     have the "node" property, as locators are never /128.
> >      >
> >      >     thanks,
> >      >     Peter
> >      >
> >      >
> >      >      >
> >      >      > If Interpretation II) is correct, then I think that the
> >     current
> >      >      > encodings in
> >      >      >
> >      >      > draft-ietf-lsr-isis-srv6-extensions-04 need clarification
> with
> >      >     respect to
> >      >      >
> >      >      > how to interpret a /128 prefix/locator advertisement with
> N=0,
> >      >     A=0.. We
> >      >      >
> >      >      > have to decide between interpreting the End-SIDs within
> >     the locator
> >      >      >
> >      >      > as either Node-SIDs or Anycast-SIDs, since there is no
> >     third option.
> >      >      >
> >      >      > I think that interpreting the End-SIDs as Anycast-SIDs in
> the
> >      >     N=0, A=0
> >      >      >
> >      >      > case is preferable because it preserves backwards
> >     compatibility.
> >      >      >
> >      >      >
> >      >      > Thanks,
> >      >      >
> >      >      > Chris
> >      >      >
> >      >      >
> >      >      >
> >      >      > On Thu, Jan 30, 2020 at 4:02 AM Peter Psenak
> >     <[e-mail] <mailto:[e-mail]>
> >      >     <mailto:[e-mail] <mailto:[e-mail]>>
> >      >      > <mailto:[e-mail] <mailto:[e-mail]>
> >     <mailto:[e-mail] <mailto:[e-mail]>>>> wrote:
> >      >      >
> >      >      >     Hi Chris,
> >      >      >
> >      >      >     please see inline (##PP)
> >      >      >
> >      >      >     On 29/01/2020 17:25, Chris Bowers wrote:
> >      >      >      > I would like to proposed the following text to make
> >     section 6
> >      >      >     more clear.
> >      >      >      >
> >      >      >      > Thanks,
> >      >      >      > Chris
> >      >      >      >
> >      >      >      > ====================
> >      >      >      >
> >      >      >      >   (existing text)
> >      >      >      >
> >      >      >      >
> >      >      >      > 6.  Advertising Anycast Property
> >      >      >      >
> >      >      >      >     Both prefixes and SRv6 Locators may be
> >     configured as
> >      >     anycast
> >      >      >     and as
> >      >      >      >
> >      >      >      >     such the same value can be advertised by
> multiple
> >      >     routers.  It is
> >      >      >      >
> >      >      >      >     useful for other routers to know that the
> >      >     advertisement is for an
> >      >      >      >
> >      >      >      >     anycast identifier.
> >      >      >      >
> >      >      >      >     A new flag in "Bit Values for Prefix Attribute
> >     Flags
> >      >     Sub-TLV"
> >      >      >      >
> >      >      >      >     registry [RFC7794] is defined to advertise the
> >     anycast
> >      >     property:
> >      >      >      >
> >      >      >      >         Bit #: 4 (Suggested - to be assigned by
> IANA)
> >      >      >      >
> >      >      >      >         Name: Anycast Flag (A-flag)
> >      >      >      >
> >      >      >      >         When the prefix/SRv6 locator is configured
> >     as anycast,
> >      >      >     the A-flag
> >      >      >      >
> >      >      >      >         SHOULD be set. Otherwise, this flag MUST be
> >     clear.
> >      >      >      >
> >      >      >      >     The A-flag MUST be preserved when leaked
> >     between levels.
> >      >      >      >
> >      >      >      >     The A-flag and the N-flag MUST NOT both be set.
> >      >      >      >
> >      >      >      > ==== start insert new text =======
> >      >      >      >
> >      >      >      >
> >      >      >      > Certain use cases require prefixes/locators that
> >     uniquely
> >      >     belong
> >      >      >     to a node.
> >      >      >      >
> >      >      >      > Since prefixes/locators which are not /128 should
> >     not have
> >      >     the N
> >      >      >     bit set,
> >      >      >      >
> >      >      >      > this node local uniqueness is decided based on A
> >     bit for
> >      >     non-/128
> >      >      >     prefixes.
> >      >      >
> >      >      >     ##PP
> >      >      >     above does not seem correct. Above seems to imply that
> for
> >      >     non-/128
> >      >      >     prefix, A-bit is replacement of N-bit.
> >      >      >
> >      >      >     A-bit applies to both /128 and non-/128 prefixes
> equally.
> >      >      >
> >      >      >     Current draft clearly states what to do when both N a
> >     A bits
> >      >     are set.
> >      >      >
> >      >      >
> >      >      >
> >      >      >      >
> >      >      >      >     When a prefix/locator iscategorized as anycast,
> it
> >      >     does not
> >      >      >     uniquely
> >      >      >      > belong
> >      >      >      >
> >      >      >      >     to a node and cannot be used for such use
> >     cases.  The
> >      >     rules
> >      >      >     below
> >      >      >      > specify
> >      >      >      >
> >      >      >      >     how to determine whether or not a
> >     prefix/locator should be
> >      >      >     treated
> >      >      >      > as anycast
> >      >      >      >
> >      >      >      >     in various situations.
> >      >      >      >
> >      >      >      >
> >      >      >      >     [RFC7794] contains the following restriction on
> the
> >      >      >     interpretation of the N-flag.
> >      >      >      >
> >      >      >      >     "If the flag is set and the prefix length is
> NOT a
> >      >     host prefix
> >      >      >      >
> >      >      >      >      (/32 for IPV4, /128 forIPv6), then the flag
> >     MUST be
> >      >     ignored."
> >      >      >      >
> >      >      >      >     The current document does NOT modify this
> >     restriction
> >      >     on the
> >      >      >     interpretation of
> >      >      >      >
> >      >      >      >     the N-flag imposed by [RFC7794].
> >      >      >
> >      >      >     ##PP
> >      >      >     I don't think above text is needed. And I don't think
> >     above is
> >      >      >     completely correct, as we define a new case in which
> >     the N-bit
> >      >      >     should be
> >      >      >     ignored (when A-bit is set).
> >      >      >
> >      >      >
> >      >      >      >
> >      >      >      >     For a prefix/SRv6 Locator advertisement with a
> /128
> >      >      >     prefix/locator,
> >      >      >      >
> >      >      >      >     if both N-flag and A-flag are set, the receiving
> >      >     router MUST
> >      >      >     treat the
> >      >      >      >
> >      >      >      >     prefix advertisement as anycast.
> >      >      >
> >      >      >     ##PP
> >      >      >     we have following text in the draft already:
> >      >      >
> >      >      >     "If both N-flag and A-flag are set in the prefix/SRv6
> >     Locator
> >      >      >          advertisement, the receiving routers MUST ignore
> the
> >      >     N-flag."
> >      >      >
> >      >      >
> >      >      >
> >      >      >      >
> >      >      >      >     For a prefix/SRv6 Locator advertisement with a
> /128
> >      >      >     prefix/locator,
> >      >      >      >
> >      >      >      >     if the N-flag and A-flag are NOT set, the
> receiving
> >      >     routers
> >      >      >      >
> >      >      >      >     MUST treat the prefix advertisement as anycast..
> >      >      >
> >      >      >     ##PP
> >      >      >     I don't think above statement is correct. Why a node
> >     cannot
> >      >     advertise a
> >      >      >     /128 prefix which is not an anycast one and does not
> >     have a
> >      >     N-bit set?
> >      >      >
> >      >      >
> >      >      >
> >      >      >      > This rule ensures the
> >      >      >      >
> >      >      >      >     correct interpretation of a prefix advertisement
> >      >     originated by
> >      >      >      >
> >      >      >      >     a router that is not SRv6 capable and
> >     originates a legacy
> >      >      >      >
> >      >      >      >     Prefix Attribute Flags Sub-TLV based on
> >     [RFC7794] alone.
> >      >      >      >
> >      >      >      >     For a prefix/SRv6 Locator advertisement with a
> >      >     prefix/locator
> >      >      >     that
> >      >      >      >
> >      >      >      >     is NOT /128, the N-flag must be ignored, so the
> >      >     setting of the
> >      >      >      >
> >      >      >      >     A-flag determines the anycast treatment of the
> >     prefix
> >      >      >     advertisement.
> >      >      >
> >      >      >     ##PP
> >      >      >     A-flag does that regardless of the length of the
> prefix.
> >      >      >
> >      >      >
> >      >      >      >
> >      >      >      >     The Prefix Attribute Flags Sub-TLV can be
> >     carried in
> >      >     the SRv6
> >      >      >      > Locator TLV
> >      >      >      >
> >      >      >      >     as well as the Prefix Reachability TLVs.  When
> >     a router
> >      >      >     originates
> >      >      >      >
> >      >      >      >     both the Prefix Reachability TLV and the SRv6
> >     Locator
> >      >     TLV for
> >      >      >     a given
> >      >      >      >
> >      >      >      >     prefix, and the router is originating the
> >     Prefix Attribute
> >      >      >     Flags Sub-TLV
> >      >      >      >
> >      >      >      >     in one of the TLVs, the router SHOULD advertise
> >     identical
> >      >      >     versions of the
> >      >      >      >
> >      >      >      >     Prefix Attribute Flags Sub-TLV in both TLVs.
> >      >      >
> >      >      >     ##PP
> >      >      >     Above seems a good suggestion. Will add it.
> >      >      >
> >      >      >      >
> >      >      >      >
> >      >      >      >
> >      >      >      >     If a router receives one Prefix Attribute Flags
> >      >     Sub-TLV in the
> >      >      >      >
> >      >      >      >     Prefix Reachability TLV and another in the SRv6
> >      >     Locator TLV,
> >      >      >     the router should
> >      >      >      >
> >      >      >      >     use the prefix attribute flags received in the
> >     Prefix
> >      >      >     Reachability TLV.
> >      >      >
> >      >      >     ##PP
> >      >      >     above contradicts what you suggest in the previous
> >     paragraph,
> >      >     where you
> >      >      >     suggest we need to advertise with both prefix and
> locator,
> >      >     and here you
> >      >      >     suggest we ignore what we received in the locator.
> >      >      >
> >      >      >     Are you talking about the case where the content of
> >     the Prefix
> >      >      >     Attribute
> >      >      >     Flags Sub-TLV is different in prefix vs locator?
> >      >      >      >
> >      >      >      >
> >      >      >      >
> >      >      >      >     If a router receives a Prefix Attribute Flags
> >     Sub-TLV
> >      >     in the
> >      >      >      >
> >      >      >      >     Prefix Reachability TLV but not in the SRv6
> Locator
> >      >     TLV, the
> >      >      >     router should
> >      >      >      >
> >      >      >      >     use the prefix attribute flags received in the
> >     Prefix
> >      >      >     Reachability TLV.
> >      >      >
> >      >      >     ##PP
> >      >      >     do we really need this? If the originator does the
> right
> >      >     thing, then we
> >      >      >     don't have the problem. Cross referencing data between
> >      >     different TLVs
> >      >      >     complicates the implementations.
> >      >      >
> >      >      >
> >      >      >      >
> >      >      >      >
> >      >      >      >
> >      >      >      >     If a router receives a Prefix Attribute Flags
> >     Sub-TLV
> >      >     in the
> >      >      >      >
> >      >      >      >     SRv6 Locator TLV but not in the Prefix
> >     Reachability TLV,
> >      >      >      >
> >      >      >      >     the router should use the prefix attribute flags
> >      >     received in
> >      >      >     the SRv6 Locator TLV.
> >      >      >
> >      >      >     ##PP
> >      >      >     same as above.
> >      >      >
> >      >      >     thanks,
> >      >      >     Peter
> >      >      >
> >      >      >      >
> >      >      >      > ==== end insert new text =========
> >      >      >      >
> >      >      >      >     The same prefix/SRv6 Locator can be advertised
> >     by multiple
> >      >      >     routers.
> >      >      >      >
> >      >      >      >     If at least one of them sets the A-Flag in its
> >      >     advertisement, the
> >      >      >      >
> >      >      >      >     prefix/SRv6 Locator SHOULD be considered as
> >     anycast..
> >      >      >      >
> >      >      >      >
> >      >      >      >
> >      >      >      > ===================
> >      >      >      >
> >      >      >      >
> >      >      >      > On Tue, Jan 21, 2020 at 6:15 PM Christian Hopps
> >      >      >     <[e-mail] <mailto:[e-mail]>
> >     <mailto:[e-mail] <mailto:[e-mail]>>
> >      >     <mailto:[e-mail] <mailto:[e-mail]>
> >     <mailto:[e-mail] <mailto:[e-mail]>>>
> >      >      >      > <mailto:[e-mail]
> >     <mailto:[e-mail]> <mailto:[e-mail]
> >     <mailto:[e-mail]>>
> >      >     <mailto:[e-mail] <mailto:[e-mail]>
> >     <mailto:[e-mail] <mailto:[e-mail]>>>>> wrote:
> >      >      >      >
> >      >      >      >     This begins a 2 week WG Last Call, ending after
> >     Feb 4,
> >      >     2020, for
> >      >      >      >     draft-ietf-lsr-isis-srv6-extensions
> >      >      >      >
> >      >      >      >
> >      >      >
> >      >
> >     https://datatracker.ietf.
> .org/doc/draft-ietf-lsr-isis-srv6-extensions/
> >      >      >      >
> >      >      >
> >      >
> >       <
> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/>
> >      >      >      >
> >      >      >      >     Authors please indicate if you aware of any
> >     other IPR
> >      >     beyond
> >      >      >     what is
> >      >      >      >     posted:
> >      >      >      >
> >      >      >      > https://datatracker.ietf.org/ipr/3796/
> >      >      >      >
> >      >      >      >     Thanks,
> >      >      >      >     Chris & Acee.
> >      >      >      >     _______________________________________________
> >      >      >      >     Lsr mailing list
> >      >      >      > [e-mail] <mailto:[e-mail]>
> >     <mailto:[e-mail] <mailto:[e-mail]>> <mailto:[e-mail]
> >     <mailto:[e-mail]>
> >      >     <mailto:[e-mail] <mailto:[e-mail]>>>
> >     <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail]
> >     <mailto:[e-mail]>>
> >      >      >     <mailto:[e-mail] <mailto:[e-mail]>
> >     <mailto:[e-mail] <mailto:[e-mail]>>>>
> >      >      >      > https://www.ietf.org/mailman/listinfo/lsr
> >      >      >      >
> >      >      >
> >      >
> >
>
>