Subject: [babel] Redefining updates

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 03 Dec 2016 18:20:06 +0100

RFC 6126 Updates are not defined well.

RFC 6126 Section 4.4.9 says:

o  if the bit with value 80 hexadecimal is set, then this Update
   establishes a new default prefix for subsequent Update TLVs with a
   matching address family within the same packet;

This assumes that an implementation is able to match an AE with an address
family.  Not only does this complicate the definition of new AEs (which
must specify which family they belong to), but it's not entirely clear
what to do with AEs that don't map cleanly to an address family, such as
source-specific routes, MPLS or BIER.

I'm planning to make an incompatible change (but one that will not break
existing implementations): the implicit prefix established by flag 0x80
will be per-AE.  This makes the semantics easier to implement and easier
to understand, at a slight cost in compression efficiency.  It will not
break existing implementations (since AEs 1 and 2 are the only ones
carried in updates by existing implementations).

Comments?  While I'm at it, should I rename the "Prefix" field to
"Opaque", since future extensions might use it for carrying things other
than prefixes?

-- Juliusz

---

From: [email-masked]
Date: Mon, 5 Dec 2016 14:35:21 +0800

Hi Juliusz,

    Glad to see your modification consideration of the prefix section. 
I agree to the meaning extension of AE. And I think that the name 
changing may be not necessary. Because most of the info can be delivered 
by sub-TLVs of prefix. The content can be distinguished from the type of 
sub-TLVs or other ways.

Thanks,
Sandy

"babel" <[email-masked]> 写于 2016/12/04 01:20:06:

> _______________________________________________
> babel mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/babel
>

---

From: David Schinazi <[email-masked]>
Date: Sun, 04 Dec 2016 23:34:54 -0800

Juliusz,

I agree with this change. This was an area that tripped me up when first implementing.
The new proposal is simpler and more future-proof.

David

> On Dec 4, 2016, at 22:35, [email-masked] wrote:
> 
> 
> Hi Juliusz, 
>

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Mon, 05 Dec 2016 10:44:22 +0100

> The new proposal is simpler and more future-proof.

+1

-Toke