Thanks Peter. With algo-0 SRv6, then after the draft is updated, it will be allowed that the attribute flags are none-identical between locator-tlv (27) and TLV236/237? Is that understanding correct?
G/ -----Original Message----- From: Peter Psenak <[email protected]> Sent: Wednesday, February 24, 2021 16:39 To: Van De Velde, Gunter (Nokia - BE/Antwerp) <[email protected]>; [email protected] Cc: [email protected] Subject: Re: Clarification on inconsistency between RFC7794 and draft-ietf-lsr-isis-srv6-extensions Hi Gunter, On 24/02/2021 07:24, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote: > Hi Peter, All, > > I’m am trying to clarify a potential inconsistency between RFC7794 and > draft-ietf-lsr-isis-srv6-extensions. > > draft-ietf-lsr-isis-srv6-extensions says that we should advertise > identical prefix-attribute tlv for the ipv6 reachability tlv and for > the locator tlv. yes, for algo 0 only. > > RFC7794 document says that we should not set the X flag in case of > ipv6 routes because the ipv6 reachability tlv already has an external > indication. > > Can you advise. > > 1. draft-ietf-lsr-isis-srv6-extensions > > 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 For locator TLV, the is X-flag obtained from Prefix Attribute Flags Sub-TLV, unlike the TLVs 236 and 237. I will add the text to clarify that difference. thanks, Peter > > both TLVs. > > 2. RFC7794 > > Prefix Attribute Flags > > Type: 4 > > Length: Number of octets of the Value field. > > Value: > > (Length * 8) bits. > > 0 1 2 3 4 5 6 7... > > +-+-+-+-+-+-+-+-+... > > |X|R|N| ... > > +-+-+-+-+-+-+-+-+... > > Bits are defined/sent starting with Bit 0 defined below. > Additional > > bit definitions that may be defined in the future SHOULD be > assigned > > in ascending bit order so as to minimize the number of bits that > will > > need to be transmitted. > > Undefined bits MUST be transmitted as 0 and MUST be ignored on > > receipt. > > Bits that are NOT transmitted MUST be treated as if they are set > to 0 > > on receipt. > > X-Flag: External Prefix Flag (Bit 0) > > Set if the prefix has been redistributed from another protocol. > > This includes the case where multiple virtual routers are > > supported and the source of the redistributed prefix is another > > IS-IS instance. > > The flag MUST be preserved when leaked between levels. > > In TLVs 236 and 237, this flag SHOULD always be sent as 0and MUST > > be ignored on receipt. This is because there is an existing X > > flag defined in the fixed format of these TLVs as specified in > > [RFC5308 <https://tools.ietf.org/html/rfc5308>] and [RFC5120 > <https://tools.ietf.org/html/rfc5120>]. > > G/ > _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
