Hi Ketan,
On 14/09/2021 11:24, Ketan Talaulikar (ketant) wrote:
Hi Dirk,
Your point is related to my original concern/interpretation for why we
introduced a new LSA type for SRv6 Locator than use the existing
Extended Prefix LSA types. This goes back to the original intention of
the WG and authors of RFC8362.
If one can never generate the E-*-Prefix LSAs (e.g.
E-Inter-Area-Prefix-LSA) without the presence/inclusion of their
corresponding “base” prefix-reachability TLVs (e.g. Inter-Area-Prefix
TLV), then these extended LSAs cannot be used for advertisement of SRv6
Locators in OSPFv3. This is because, for FlexAlgo we need the ability to
advertise only the SRv6 Locators without the “base” prefix reachability.
I was made to understand, however, that the text in RFC8362 was only in
the context of base OSPFv3 SPF and it was not intended to make the
“base” prefix reachability TLVs mandatory in the extended LSAs. Hence
the proposal for this change.
Would like to know the WG and RFC8362 authors views on this aspect.
Regd the NU bit, that applies for when Prefix SID mapping for an
individual prefix is advertised by the SRMS by using the Prefix-SID
sub-TLV inside the Intra/Inter/External Prefix TLVs. I was talking about
the advertisement of ranges using the OSPFv3 Extended Prefix Range TLVs
– there is no NU bit in the picture here AFAIK. I am referring to the
text in https://datatracker.ietf.org/doc/html/rfc8666#section-8.1
Are you saying that implementations today are advertising say
Intra-Area-Prefix TLV with NU bit set along with an OSPFv3 Extended
Prefix Range TLV in the same E-Intra-Area-Prefix LSA for advertisement
of SRMS ranges? If so, this was not very clear to me from RFC8666.
I see no reason to send Intra-Area-Prefix TLV with NU bit set along with
an OSPFv3 Extended Prefix Range TLV. The text in rfc8666 says "An SR
Mapping Server MUST use the OSPFv3 Extended Prefix Range TLVs when
advertising SIDs for prefixes.". That should be sufficient.
thanks,
Peter
Thanks,
Ketan
*From:*Goethals, Dirk (Nokia - BE/Antwerp) <[email protected]>
*Sent:* 14 September 2021 14:15
*To:* Ketan Talaulikar (ketant) <[email protected]>; Ketan Talaulikar
(ketant) <[email protected]>; [email protected]
*Subject:* RE: Proposed changes for OSPFv3 SRv6 encoding
Hi Ketan,
I’m not sure I understand your reply correctly.
The same paragraph also mentions:
If the Inter-Area-Prefix TLV is not included in the E-Inter-Area-Prefix-LSA,
it is treated as malformed as described in Section 5
<https://datatracker.ietf.org/doc/html/rfc8362#section-5>.
w.r.t OSPFv3 Extended Prefix Range TLV
I’ve been told that the NU-bit
(https://datatracker.ietf.org/doc/html/rfc5340#appendix-A.4.1.1)
is used to exclude it from unicast.
I’m I missing something?
Thx,
Dirk
*From:*Ketan Talaulikar (ketant) <[email protected]
<mailto:[email protected]>>
*Sent:* Tuesday, September 14, 2021 9:56 AM
*To:* Goethals, Dirk (Nokia - BE/Antwerp) <[email protected]
<mailto:[email protected]>>; Ketan Talaulikar (ketant)
<[email protected]
<mailto:[email protected]>>; [email protected]
<mailto:[email protected]>
*Subject:* RE: Proposed changes for OSPFv3 SRv6 encoding
Hi Dirk,
There was a misunderstanding of Acee's comment and its context on my
part. More specifically my misunderstanding on what RFC8362 text
intended to say.
E.g. https://datatracker.ietf.org/doc/html/rfc8362#section-4.3 says the
following
In order to retain
compatibility and semantics with the current OSPFv3 specification,
each Inter-Area-Prefix LSA MUST contain a single Inter-Area-Prefix
TLV.
I read this as Inter-Area-Prefix TLV must be present in an OSPFv3
E-Inter-Area-Prefix LSA and other TLVs may be added optionally. However,
this does not seem to be the correct interpretation since we already
have introduced the OSPFv3 Extended Prefix Range TLV in
https://datatracker.ietf.org/doc/html/rfc8666#section-5 that is a
top-level TLV and may be used for a prefix without its corresponding
Inter-Area-Prefix TLV.
So we can introduce the SRv6 Locator TLV similar to the Prefix Range TLV
into the existing Prefix LSAs as indicated by Acee and there would not
be an issue.
Thanks,
Ketan
-----Original Message-----
From: Lsr <[email protected] <mailto:[email protected]>> On Behalf
Of Goethals, Dirk (Nokia - BE/Antwerp)
Sent: 14 September 2021 12:58
To: Ketan Talaulikar (ketant) <[email protected]
<mailto:[email protected]>>; [email protected]
<mailto:[email protected]>
Subject: Re: [Lsr] Proposed changes for OSPFv3 SRv6 encoding
Hi Ketan,
I'm not against this suggested change.
I noticed however, that Acee suggested this a while back and at that
time you mentioned an issue when flex-algo locators where advertised
this way, see snip below. Can you elaborate on why this is no longer an
issue?
Thx,
Dirk
<snip>
[Acee]
Why do you define a separate SRv6 Locator LSA to advertise SRv6
reachability? One of the primary benefits of RFC8362 is to advertise all
the information associated with a prefix in one LSA. Now you have
negated that benefit by putting this information in a separate LSA.
[KT] We need to define a new LSA since this is not an extension for the
normal prefix reachability. For doing FlexAlgo with SRv6, the locators
are used for reachability computation within the FlexAlgo. If these were
advertised as normal prefix reachability then routers which are not part
of the FlexAlgo or even routers not supporting SRv6 would program them.
We've tried to explain this in
https://tools.ietf.org/html/draft-li-ospf-ospfv3-srv6-extensions-07#section-5.
-----Original Message-----
From: Lsr <[email protected] <mailto:[email protected]>> On Behalf
Of Ketan Talaulikar (ketant)
Sent: Monday, September 13, 2021 6:29 PM
To: [email protected] <mailto:[email protected]>
Subject: [Lsr] Proposed changes for OSPFv3 SRv6 encoding
Hello All,
Some feedback has been received with suggestions to change the encoding
currently proposed in the draft - more specifically related to
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-srv6-extensions-02#section-6
The proposal is to do away with the need for introduction of a new LSA
for SRv6 Locator and instead advertise the SRv6 Locator as a new
top-level TLV within all the extended Prefix LSAs introduced in RFC8362.
The advantage is simpler processing for the scenarios where the prefix
is advertised as both a normal prefix reachability as well as SRv6
Locator. It also results in avoiding the handling of a new LSA type in
OSPFv3.
I would like to poll the WG to check if there are any existing
implementations of the draft in the current form (even though codepoints
have not yet been allocated). Also, if there is any objection to
introducing this change.
Thanks,
Ketan
_______________________________________________
Lsr mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
