Re: [dtn] BPbis rules for future extension blocks

[Magnus Westerlund <[e-mail]>]

Hi,

Scott, thanks for the text proposal. I am still thinking that the last 
paragraph of your proposals do raise the question if there is need to define a 
"MUST NOT be removed" flag for the block control flags. WG please think this 
over. I understand that there might not be any intermediate usage of this 
flag, but adding it later might be far from trivial.

Cheers

Magnus

> -----Original Message-----
> From: Burleigh, Scott C (US 312B)
> <scott.c.burleigh=[e-mail]>
> Sent: den 20 november 2020 17:01
> To: Magnus Westerlund <[e-mail]>; [e-mail]
> Subject: RE: BPbis rules for future extension blocks
>
> Thanks, Magnus.  As a starting point for this discussion, here is the text 
> that I
> would propose to use in place of the current first paragraph of section 4.3:
>
> <start>
> "Extension blocks" are all blocks other than the primary and payload blocks.
> Three types of extension blocks are defined below.  All implementations of
> the Bundle Protocol specification (the present document) MUST include
> procedures for recognizing, parsing, and acting on, but not necessarily
> producing, these types of extension blocks.
>
> The specifications for additional types of extension blocks must indicate
> whether or not BP implementations conforming to those specifications must
> recognize, parse, act on, and/or produce block of those types.  As not all
> nodes will necessarily instantiate BP implementations that conform to those
> additional specifications, it is possible for a node to receive a bundle 
> that
> includes extension blocks that the node cannot process. The values of the
> block processing control flags indicate the action to be taken by the bundle
> protocol agent when this is the case.
>
> No mandated procedure in this specification is unconditionally dependent on
> the absence or presence of any extension block.  Therefore any bundle
> protocol agent MAY insert or remove any extension block in any bundle,
> subject to all mandates in the Bundle Protocol specification and all 
> extension
> block specifications to which the node's BP implementation conforms.  Note
> that removal of an extension block will probably disable one or more
> elements of bundle processing that were intended by the BPA that inserted
> that block.  In particular, note that removal of an extension block that is 
> one
> of the targets of a BPsec security block may render the bundle unverifiable.
> <end>
>
> Scott
>
> -----Original Message-----
> From: dtn <[e-mail]> On Behalf Of Magnus Westerlund
> Sent: Friday, November 20, 2020 6:56 AM
> To: [e-mail]
> Subject: [EXTERNAL] [dtn] BPbis rules for future extension blocks
>
> Hi WG,
>
> So in the discussion of BPv7 Extension in todays meeting some people did
> draw some parallels to IPv6 Extension headers. Ben Kaduk reminded me that
> there is one important aspect of that discussion that can hint at an issue. 
> If
> you are following 6man and/or Spring WG you would know about the big
> discussion related to addition and removal of some IPv6 extension headers
> by anything other than the endpoints that IPv6 Segment routing proposal has
> caused.
>
> So the existing Extension headers are all being changed interally and at 
> least
> "received from" will be added by a forwarder which isn't the originating
> endpoint.  So the question to the WG and especially the authors. Is it 
> really
> clear that Extension bundle blocks MAY be added by any node? Which nodes
> MAY remove a Extension bundle block? What controls if a Extension Bundle
> Block can be removed by an intermediate node. I do note taht the Block
> Processing Control Flags do not have a flag for "MUST NOT be removed, even
> if not understood".
>
> I would encourage the WG to think if there need to be any clarification of 
> this
> now. If we are missing a control flag I think it is easier to add it now. 
> Also to
> clarify what the general rules are for Extension Blocks so that this 
> discussion
> don't show up a bit down the line here.
>
> Cheers
>
> Magnus
>