Subject: [babel] Rtgdir early review of draft-ietf-babel-source-specific-01

From: Joel Halpern <[email-masked]>
Date: Sat, 04 Nov 2017 14:19:58 -0700

Reviewer: Joel Halpern
Review result: Not Ready

This is a routing directorate early review.  It is intended to assist the
working group and the routing ADs in processing the advancing document.

This document is nearly ready for publication as a Proposed Standard RFC.

Isses:
Major: N/A

Moderate:
Please address the issues reported by id-nits.  Specifically, repair the
abstract and add an explicit reference to RFC 2119

Please add an informative reference to draft-ietf-rtgwg-dst-src-routing
indicating the the routing policy described here aligns with the ongoing work
in the routing area for how to handle source specific routes.  This could be
added in section 4.

The base Babel (bis) specification does not talk about the handling of
duplicate sub-TLVs.  Are multiple source-specific sub-TLVs allowed on a given
destination prefix advertisement?  Please indicate what the intended /
permitted handling is in the text.

Minor:
As far as I can tell, the behavior described in section 3.1 for 0/0 source
addresses and their relationship to routes without source addresses is correct
and matches draft-ietf-rtgwg-dst-src-routing.  However, the wording is
sufficiently different as to cause this reader to wonder about it.  If
practical consider additional wording to make the alignment clear.  This would
seem to apply to 3.2 as well.  The most obvious fix is to say that a Babel node
supporting this extensions treats all advertisements received without a source
specific prefix as if they had the 0/0 source prefix?  (The text in section 5.2
says this.  I would like to see it in section 3.1)

---

From: Matthieu Boutier <[email-masked]>
Date: Wed, 8 Nov 2017 16:04:35 +0100

Hi,

Thank's a lot for this early review.

> Please address the issues reported by id-nits.

Please accept my apologizes about these nits.

> destination prefix advertisement?

I believe it is clear that a Babel node MUST NOT send two Source Prefix sub-TLVs
in one TLV.  But If a received TLV has two Source Prefix sub-TLVs, I hesitate:
does a node SHOULD or MUST ignore the whole TLV?

Does the list have an opinion?

Matthieu

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Thu, 09 Nov 2017 09:18:55 +0900

> Does the list have an opinion?

Off the top of my head: Ignore the whole thing; better to fail
(preferably loudly) than carry on with ambiguous semantics.

-Toke

---

From: David Schinazi <[email-masked]>
Date: Wed, 08 Nov 2017 16:44:48 -0800

$.02

Personally, if I receive something that the spec says you MUST NOT do I get upset at the packet.
Maybe I ignore the whole TLV, maybe the whole packet, maybe I summon the wrath of the Gods of the Internet.
If you expect that someone someday could find a use case for sending two sub-TLVs,
then I'd recommend explicitly saying MUST NOT send and on receive MUST drop TLV but not packet.
If you don't expect this to ever be useful, no need to specify it.

David

> On Nov 8, 2017, at 16:18, Toke Høiland-Jørgensen <[email-masked]> wrote:
> 
> Matthieu Boutier <[email-masked] <mailto:[email-masked]>> writes:
> 
>> Hi,
>> 
> _______________________________________________
> babel mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/babel <https://www.ietf.org/mailman/listinfo/babel>

---

From: Denis Ovsienko <[email-masked]>
Date: Thu, 09 Nov 2017 11:45:22 +0000

---- On Wed, 08 Nov 2017 15:04:35 +0000 Matthieu Boutier  wrote ---- 
>Does the list have an opinion? 

Hello Matthieu.

As far as protocol encoding semantics could go, more than one source prefix sub-TLV per one destination prefix TLV could mean the destination is the same in every resulting source-destination pair -- a simple form of compression. Do you think this compression gain isn't worth the complexity overhead or you just didn't consider this possibility before?

-- 

    Denis Ovsienko

---

From: Matthieu Boutier <[email-masked]>
Date: Thu, 9 Nov 2017 14:48:18 +0100

> maybe I summon the wrath of the Gods of the Internet.

Hey! What's the protocol for that? :p

> If you don't expect this to ever be useful, no need to specify it.

Looks good for me, does something like the following make sense?  Should we
recommend something?

    A node does not expect to receive any TLV with two Source Prefix sub-TLVs or
    more.  Whenever that occurs, the behaviour is undefined: an implementation
    may drop the whole packet, the whole TLV or consider only just one of the
    sub-TLVs (this can be the case if the implementation does not check if
    multiple sub-TLVs are sent).

Toke, would you like to see: "It is recommended to ignore the whole packet".
(lower case "recommended")

Matthieu

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 9 Nov 2017 08:54:12 -0500

Being a little bit picky here:

Could you also add a sentence in section 7.1 stating explicitly that 
only one source specific prefix is permitted in a TLV?  I realize this 
is implied by the use of "a source prefix" in section 5.1.  I think it 
would help to be explicit.

If the sending side restriction is made explicit, then the text you 
propose for the receiving side is acceptable, although I would 
personally prefer that it used an upper case SHOULD for ignoring the 
whole TLV.  This preference is driven by a desire for robustness and 
predictability in interoperation.

Yours,
Joel

On 11/9/17 8:48 AM, Matthieu Boutier wrote:
> [email-masked]
> https://www.ietf.org/mailman/listinfo/babel
>

---

From: Denis Ovsienko <[email-masked]>
Date: Thu, 09 Nov 2017 17:02:21 +0000

---- On Thu, 09 Nov 2017 13:45:32 +0000 Matthieu Boutier  wrote ---- 
>Hello Denis, 
> 
>> more than one source prefix sub-TLV per one destination prefix TLV could mean the destination is the same in every resulting source-destination pair -- a simple form of compression. 
> 
>I see three reasons to avoid this (random order): 
> 
> - I believe that Babel takes care to not overload its protocol: there should 
> not be two way to express the same thing. 
> 
> - Having such working compression would be extremely rare since it would be 
> impossible if the two routes (having the same destination) have the same 
> metric and other properties. 
> 
> - The compression mechanism already compress the destination prefix in a 
> very more flexible way. 

Thanks for the response.

So, the (Interval, Seqno, Metric) triplet makes such compression useless and simplicity is a valid argument. I accept those points.

With this in mind I was going to suggest that when the protocol instance expects 0 or 1 Source Prefix sub-TLVs in a TLV but encounters more than 1, that makes the TLV malformed, therefore the TLV must be ignored. But do you think the following text in 6126-bis Section 4.6.9 deserves additional attention?

   An Update TLV advertises or retracts a route.  As an optimisation, it
   can optionally have the side effect of establishing a new implied
   router-id and a new default prefix.

In this sense, if the instance skips a malformed Update TLV that was intended to establish the implied values, would it be right to skip subsequent TLVs because those depend on the implied values? Does this stand for both the basic protocol and the source-specific extension?

There is a straightforward statement about unknown TLV types in the base protocol specification:

   TLVs with an unknown type value MUST be silently ignored.

Perhaps it would be useful to have a fail-safe statement about known (but malformed) TLV types handling in general (not just Update).

And a closely related point: given a series of properly formed Update TLVs, if one TLV wants to establish the implied values but the protocol instance considers the update unfeasible, does it still modify the implied values?

-- 
    Denis Ovsienko

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 09 Nov 2017 23:40:42 +0100

> As far as protocol encoding semantics could go, more than one source
> prefix sub-TLV per one destination prefix TLV could mean the destination
> is the same in every resulting source-destination pair -- a simple form
> of compression.

Smart idea, but for the sake of simplicity I'd prefer we go with Joel's
suggestion.  (SHOULD silently drop.)

> In this sense, if the instance skips a malformed Update TLV that was
> intended to establish the implied values, would it be right to skip
> subsequent TLVs because those depend on the implied values? Does this
> stand for both the basic protocol and the source-specific extension?

Please see 6126bis Section 4.5.  I think that an Update with multiple
source-specific sub-TLVs should behave just like an Update with an unknown
mandatory sub-TLV: it should establish the parser state, and only then be
dropped.  In other words, checking for duplicate sub-TLVs should happen
after parsing, not during parsing.

> Perhaps it would be useful to have a fail-safe statement about known
> (but malformed) TLV types handling in general (not just Update).

Yes, that makes sense.  I'm waiting for Susan's review before I make any
updates to the text.

> And a closely related point: given a series of properly formed Update
> TLVs, if one TLV wants to establish the implied values but the protocol
> instance considers the update unfeasible, does it still modify the
> implied values?

Yes.  Unfeasible updates are parsed and processed normally, they are
avoided much later (Sections 3.5 and 3.6.)

-- Juliusz

---

From: Matthieu Boutier <[email-masked]>
Date: Tue, 21 Nov 2017 09:16:36 +0100

> Being a little bit picky here:

All improvements are welcome!  Thanks for the advices and explanations.

> Could you also add a sentence in section 7.1 stating explicitly that only one source specific prefix is permitted in a TLV?

I also rewrite the introduction of 7 to precise the behaviour when multiple or malformed sub-TLV are received.

Thanks for the feedback.  This is pushed on the git (https://github.com/jech/babel-drafts).

Matthieu