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

[Chris Bowers <[e-mail]>]

 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.

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

Thanks,
Chris

On Tue, Feb 4, 2020 at 2:44 AM Peter Psenak <[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]> 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]>> 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]>>> 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]>>
> >      > https://www.ietf.org/mailman/listinfo/lsr
> >      >
> >
>
>