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

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

Bruno,

Thanks for reviewing the draft!
>> - RFC 3107 provides an encoding that allows BGP to assign multiple labels
> Upfront, the current issue is that implementations, which claim compliance with RFC 3107, are just non-compliant. So the draft is proposing to change the specification to make such implementations compliant, while another option would be to fix implementation (to be compliant with the RFC they claim to support).
I think the best approach is to try to write 3107bis in such a way that 
the existing deployed implementations are compliant to it.
> The main issue I have, is that this draft is not backward compatible with RFC 3107 (as a RFC 3107 speaker will never notice that its peer has not send the new capability, and may still send multiple labels). Plus in case of error due to this incompatibility, the error handling behavior is likely to be "BGP session shutdown" (as the NLRI "cannot" be correctly parsed) which is disruptive. Plus the implementation A not supporting multiple labels, will claim that the implementation B supporting multiple labels is "not compliant" with rfc3107bis, while I would rather argue that this is implementation A which is not compliant with RFC 3107.
Luckily, the existing deployed implementations, as far as I know, do not 
support multiple labels.   If a new implementation were to send multiple 
labels to an old implementation, we would likely experience the 
disruptive behavior you describe.  3107bis tries to prevent this 
disruption.
>
> I'd propose one change:
> - Capability means: I don't support receiving multiple labels, hence you SHOULD not send that to me.
> - Even if the capability is not advertised by both peers, and hence a single label is expected, all implementations MUST check that the "S" bit (in this first label) is set to 1. If the bit is cleared, the Prefix MUST be identified as per RFC 3107/this document and treated as withdraw as defined in RFC 7606.
>
> This means more work for rfc3107bis speakers, but we can't ask existing speakers to do the job. Especially since they were compliant with RFC 3107.
If only a single label is expected, there is no real reason to check the 
S bit.  I'm not sure that all existing implementations actually set the 
S bit, so requiring new implementations to check for it would just 
introduce a possible backwards compatibility problem.
> Plus very minor comments
> - From an editorial standpoint, I'd personally favor removing §2.2 and saying in 2.3(or elsewhere) that if the capability is not exchanged, a single label may be encoded. (IMHO duplicating the text is less easy to read and more error prone. And I believe this would be enough to address your point).
I went back and forth on this issue, and I'd welcome more opinions on 
this from the WG.

You are right that it is generally a bad practice to have so much 
duplicated text in a specification, but I thought the intention would be 
clearer if the encoding for multiple labels were described separately 
from the encoding for single labels.

> - In Figure 2 (§2.3), 2 labels are indicated. Do you think there is a need to indicate which one is the first (Label 1) and which one is the k th (Label k). Indeed, the order of the labels is significant when the router will need to push them in the dataplane. Or a sentence could be added to make this explicit.
This is mentioned in the "Data Plane" section, but I think you're right, it should be mentioned in section 2.3 as well.

> - In §4, there is a possible case which is not described:
> S1 receives L11, L12,... L1k
> S1 sends      L21, L12,... L1k
> S1 programs in the data plane: L21 swap L11
> Compared to sending a single label (L21), S1 avoids having to push k labels in its dataplane, which it may be incapable of.
> - In §4
> "While this may be useful in certain scenarios, it may provide unintended results in other scenarios." I fail to see when this can be useful as N1 or downstream LSR will receive packets with labels there are not aware of (L22...L2k). Out of curiosity, I'm be curious to know the useful scenario that you have in mind.
Actually, I was thinking of the case you just described above, but I wanted to formulate it in a more general way.  For all we know, <L22,...L2k> may be domain-wide unique labels ;-), or S1 may have some other way of knowing L21 will get the packet to a node that will be able to understand  <L22,...L2k>.
> - in §5 " It is possible that a BGP speaker will receive both a SAFI-1 route
>     for prefix P and a SAFI-4 route for prefix P.  The significance of
>     this is a matter of local policy."
> For 6PE (rfc4798), may be this should not be a local policy but be specified as a priori SAFI-1 and SAFI-4 prefix should be comparable. Ideally rfc4798 could have specified this but I haven't check if it's done. Alternatively §5 could reference this case.
> (Same point for propagation between SAFI-1 and SAFI-4)
In 3107bis, I just tried to capture the fact that different implementations handle this differently.  If a particular application needs to mandate a particular behavior, that should be part of the spec for that application.

Eric