[Lsr] "OSPFv3 Extensions for SRv6" - draft-li-ospf-ospfv3-srv6-extensions-07 Questions/Comments

["Acee Lindem (acee)" <[e-mail]>]

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

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


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

Thanks,
Acee