Re: [mpls] [bess] draft-rosen-idr-rfc3107bis-00

[Eric C Rosen <[e-mail]>]

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.