[Idr] [draft-ietf-idr-rfc7752bis] Question on explicit withdrawal of BGP-LS NLRI

[Nandan Saha <[e-mail]>]

Hi folks,

 I'm trying to understand what the following text is actually mandating:
>>>>
 When adding, removing or modifying a TLV/sub-TLV from a Link-State
 NLRI, the BGP-LS Producer MUST withdraw the old NLRI by including it
in the MP_UNREACH_NLRI.  Not doing so can result in duplicate and in-
consistent link-state objects hanging around in the BGP-LS table
<<<<

Is it simply about ensuring that the previous incarnation of the NLRI
is withdrawn
  (or)
is it also mandating some ordering requirements between when the old
incarnation is withdrawn and the new one advertised.

For example, if there's a link nlri say NLRI1 = {
 local node descriptor {
   asn = 100
   igp router ID = 1111.1111.1111
 }
 remote node descriptor {
   asn = 100
   igp router ID = 2222.2222.2222
 }
 link descriptor {
   ipv4 Intf address = 1.1.1.1
   ipv4 neighbor address = 1.1.1.2
}
}

Which say subsequently changes such that NLR12 = {
 local node descriptor {
   asn = 100
   igp router ID = 1111.1111.1111
 }
 remote node descriptor {
   asn = 100
   igp router ID = 2222.2222.2222
 }
 link descriptor {
   ipv4 Intf address = 4.4.4.4
   ipv4 neighbor address = 4.4.4.5
 }
}

Note that the interface address changed above in NLRI2

In this case, is it sufficient to ensure that a MP_REACH_NLRI is sent
with NLRI1 and an MP_UNREACH_NLRI is sent with NLRI1 in _any_ order or
is that text mandating something stricter?
Do both MP_REACH_NLRI=NLRI2 and MP_UNREACH_NLRI=NLRI1 need to be sent
in the same UPDATE message or the MP_UNREACH_NLRI has to be sent
before the MP_REACH_NLRI if sent in different UPDATE messages?

Thanks,
Nandan