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
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
