Thanks for reviewing the draft!
On 1/26/2016 2:47 AM, Dongjie (Jimmy) wrote:
1. For NLRI encoding with single label, this draft says that "the S bit MUST be set
to one on transmission". IMO RFC 3107 does not mandate this, and as you said some
existing implementations may not set the S bit. To ensure backward compatibility, maybe
the requirement on setting the S bit can be relaxed.
RFC3107 does allow the NLRI to contain multiple labels, but the only way
you can tell how many labels there are is by looking for the S bit. So
I think the setting of the S bit really is required by RFC 3107, even
though the RFC doesn't make that very clear.
I believe that some implementations check for the S bit and some do
not. I also believe that most implementations set the S bit, but I'm
not sure if all do. Thus I think the strategy of "set the S bit on
transmission but ignore it on reception" is most likely to result in
multi-vendor interoperability.
This does mean that an old implementation that doesn't set the S bit
would be non-compliant with 3107bis. However, it would interoperate
with compliant implementations, and that's what really matters.
I didn't want to say "SHOULD set the S bit", because that leaves it open
for new implementations to leave the S bit unset, and that might result
in interoperability problems with older implementations that do check
for the S bit.
2. For NLRI encoding with multiple labels, I guess the beginning of the prefix
field is identified based on the S bit of the last label. If a malformed NLRI
is received, in which the S bit of the last label is not set, then the prefix
cannot be recognized, and the treat-as-withdraw error handling is not
applicable. This may be worth mentioned in the draft.
Excellent point. I'll add something about this, with a reference to
section 3j of RFC 7606.
3. Section 2.5 describes implicit withdrawn and load balancing in detail. One
possible issue here is it seems that the same next hop is required for the
routes in Update U1 and U2. While section 9 of RFC 4271 specifies:
"...if the NLRI of the new route is identical to the one the route currently has
stored in the Adj-RIB-In, then the new route SHALL replace the older route in the
Adj-RIB-In, thus implicitly withdrawing the older route from service."
Thus same next hop is not required for implicit withdrawn. This also applies to
the load balancing case with Add_Path, in which the 2 paths used for load
balancing may have different next hops.
Section 2.5 is intended to address only the case where the next hop
doesn't change. When the next hop does change, the procedures from RFC
4271 apply as usual. I'll try to make this clear.
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
