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

[Chris Bowers <[e-mail]>]

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



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  or Ic) neither Node-SID nor Anycast-SID.

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.



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]> 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]>> 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]>
> >     https://www.ietf.org/mailman/listinfo/lsr
> >
>
>