Hi Acee,

Please check inline below.

From: Acee Lindem (acee) <a...@cisco.com>
Sent: 18 November 2019 08:42
To: Ketan Talaulikar (ketant) <ket...@cisco.com>; 
Cc: lsr@ietf.org
Subject: Re: "OSPFv3 Extensions for SRv6" - 
draft-li-ospf-ospfv3-srv6-extensions-07 Questions/Comments

Hi Ketan,

From: "Ketan Talaulikar (ketant)" <ket...@cisco.com<mailto:ket...@cisco.com>>
Date: Monday, November 18, 2019 at 7:24 AM
To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>, 
Cc: "lsr@ietf.org<mailto:lsr@ietf.org>" <lsr@ietf.org<mailto:lsr@ietf.org>>
Subject: RE: "OSPFv3 Extensions for SRv6" - 
draft-li-ospf-ospfv3-srv6-extensions-07 Questions/Comments

Hi Acee,

Thanks for your review and comments. Please check inline below.

From: Acee Lindem (acee) <a...@cisco.com<mailto:a...@cisco.com>>
Sent: 18 November 2019 06:18
Cc: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: "OSPFv3 Extensions for SRv6" - draft-li-ospf-ospfv3-srv6-extensions-07 

Hi Authors,
I know you have asked for adoption and I have some comments on the draft. I 
think these need to be addressed or at least answered prior to any LSR adoption 
call. In my opinion, this document is not ready.

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

Note that in ISIS, the SRv6 Locators are introduced as a new top-level TLV 
along side the Prefix Reachability TLV. So what we propose in OSPFv3 is 
consistent with that model.

Ok – I thought one advantage of SRv6 is that you simply route through routers 
that don’t support SRv6? If you don’t program the locator in these, how does 
this work?
[KT2] This is definitely the advantage and we leverage it for the default SPT. 
For the non-default FlexAlgorithms we want to ensure that only the SRv6 capable 
routers participating in that algo program forwarding entries for it.

2.     Why do always advertise 128 bit values even when you don’t need it? You 
should only advertise the part of the Locator or SID required dependent on the 
LOC:FUNCTION split (padded to a 4 octet boundary). I would expect the SIDs the 
are Sub-TLVs of the Locator TLV would have that locator in the high-order bit…
[KT] I believe the Locator being a prefix can be advertised only up to the LOC 
part – similar to how it’s done for IS-IS. The SID is being advertised as a 
128-bit value (IPv6 address and not subnet/prefix) and hence we’ve tried to be 
consistent with the same in OSPFv3 as well.

I guess an advantage of this 128-bit format is that it makes the value easier 
to consume? However, with this full expansion, you also need to check that the 
Locator is consistent with the top-level TLV.
[KT2] Yes, and we have this text in Sec 7 that says so

   SRv6 End SID MUST be a subnet of the associated Locator.  SRv6 End
   SIDs which are NOT a subnet of the associated locator MUST be



3.     Similarly, what is the purpose of the SRv6 SID Structure Sub-TLV? 
ietf-spring-srv6-network-programming defines the locator to the first N bits 
and the function to the remaining 128-N bits so I don’t see the need for this 
TLV. At the very least, there should be text defining how it is used.
[KT] This is consistent with 

Also, some editorial comments to make the text consistent with other OSPF 

1.     There is a mixture of US English and UK English of preferred spellings. 
Please use the US English as the is the style of IETF documents. For example, 
lose the extra “u” in “behavior”.

2.     OSPF doesn’t define sub-sub-TLVs, sub-sub-sub-TLVs, or any other 
alliterative TLVs.  This is an IS-IS artifact. Any TLV that is not a top-level 
TLV is a Sub-TLV and can be defined at any level of nesting. The GMPLS optical 
encodings in OSPF are very heavily nested.

3.     Sub-TLV is capitalized, not “sub-TLVs”.
[KT] Mea culpa … we’ll fix all of these in the next update.


Lsr mailing list

Reply via email to