Subject: [mpls] draft-rosen-idr-rfc3107bis-00

From: Eric C Rosen <[email-masked]>
Date: Wed, 13 Jan 2016 13:11:10 -0500

Folks,

Pardon the cross-post, but I think this may be of interest to all three 
of the IDR, MPLS, and BESS WGs.

I've posted draft-rosen-idr-rfc3107bis-00 ("Using BGP to Bind MPLS 
Labels to Address Prefixes"), which is intended of course to obsolete 
RFC 3107 ("Carrying Label Information in BGP").  (While I put "idr" in 
the name of the draft, it's not completely obvious which WG should own 
this draft (assuming it progresses)).

The purpose of this draft is the following:

- It fixes a number of errors in RFC3107.  It attempts to do so in a way 
that is compatible with existing implementations.

- It removes the material about "Advertising Multiple Routes to a 
Destination".  This is a feature that was never implemented as 
specified, and the text about it just causes confusion.  The 
functionality that this feature was intended to provide can now be 
better provided by using add-paths; this is discussed in the draft.

- It is explicit about its applicability to SAFI 128 as well as to SAFI 4.

- It clarifies the procedures for withdrawing and replacing label bindings.

- It discusses the relationship between SAFI-1 routes and SAFI-4 routes, 
which is very unclear in RFC3107.  Different implementations have 
treated the SAFI-1/SAFI-4 interactions differently, and the draft 
discusses these differences.  However, as the draft is not intended to 
favor any one implementation over another, it can't do much more than 
point out some of the differences among implementations.

- RFC 3107 provides an encoding that allows BGP to assign multiple 
labels (i.e., a label stack) to a given prefix.  However, it provides no 
semantics for this, and this feature has been only rarely implemented.  
In fact, it is believed that some implementations will not parse the 
Updates correctly if they encode multiple labels in the NLRI.  Therefore 
the draft only allows a label stack to be assigned to a given prefix if 
a new Capability has been exchanged.  It also discusses the semantics of 
assigning a label stack, and gives some examples of how this might be used.

I hope that those of you who are interested in this topic will provide 
your comments.  I've tried to make the draft compatible with existing 
implementations and deployments, so if anyone sees anything that 
negatively impacts an existing implementation, please comment on that.

I also removed most of the text that explains why it is a good idea to 
use BGP to distribute label bindings.  That text was important in the 
'90s, but now seems rather out of date.  However, I would welcome 
comments on whether an updated "motivation/positioning" section should 
be added.

Thanks,

Eric

---

From: <[email-masked]>
Date: Thu, 14 Jan 2016 15:18:33 +0000

Hi Eric,

Thanks for the draft. I read it and it looks good and useful to me.
I have mostly 1 comment:

> - 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 don't really expect that we'll agree on it, but I had to make the comment nonetheless. ;-)
That being said,

The proposed capability is a good idea to improve interoperability. Thanks.

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.

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.

Alternatively, the capability could be extended to carry two meanings: I support rfc3107bis, I support multiple labels. This would allow a rfc3107bis speaker to refuse the BGP connection with RFC 3107 speakers. But this is much less convenient.

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).
- 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.
- 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.
- 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)

Thanks again for the draft,
Regards,
-- Bruno

> From: BESS [mailto:[email-masked]] On Behalf Of Eric C Rosen
> Subject: [bess] draft-rosen-idr-rfc3107bis-00
> 
> Folks,
> 
> _______________________________________________
> BESS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bess

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Loa Andersson <[email-masked]>
Date: Fri, 15 Jan 2016 14:49:42 +0800

Eric,

In this particular case I think "cross-posting" is necessary.

One small reflection for what it is worth.

If there is no strong reason to put this in one working group or
another, there is probably no strong reason to change the home of a
draft either.

/Loa

On 2016-01-14 02:11, Eric C Rosen wrote:
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Eric C Rosen <[email-masked]>
Date: Fri, 15 Jan 2016 13:01:05 -0500

Bruno,

Thanks for reviewing the draft!
> 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…
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 multipl…
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.
> 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.
> - 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…
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 signi…
This is mentioned in the "Data Plane" section, but I think you're right, it should be mentioned in section 2.3 as well.

> "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…
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>.
> (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

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Tue, 26 Jan 2016 07:47:11 +0000

Hi Eric, 

Thanks for writing this draft, it provides useful clarifications and updates for RFC 3107. 

After reading the draft, I have some comments:

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.

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. 

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.

Best regards,
Jie

> -----Original Message-----
> Sent: Thursday, January 14, 2016 2:11 AM
> To: [email-masked]; BESS <[email-masked]>; [email-masked]
> Pardon the cross-post, but I think this may be of interest to all three of
> the IDR, MPLS, and BESS WGs.
> 
> I've posted draft-rosen-idr-rfc3107bis-00 ("Using BGP to Bind MPLS Labels
> to Address Prefixes"), which is intended of course to obsolete RFC 3107
> ("Carrying Label Information in BGP").  (While I put "idr" in the name of
> the draft, it's not completely obvious which WG should own this draft
> (assuming it progresses)).
> 
> Destination".  This is a feature that was never implemented as specified,
> and the text about it just causes confusion.  The functionality that this
> feature was intended to provide can now be better provided by using
> add-paths; this is discussed in the draft.
> 
> treated the SAFI-1/SAFI-4 interactions differently, and the draft discusses
> these differences.  However, as the draft is not intended to favor any one
> implementation over another, it can't do much more than point out some
> of the differences among implementations.
> 
> (i.e., a label stack) to a given prefix.  However, it provides no semantics
> for this, and this feature has been only rarely implemented.
> the draft only allows a label stack to be assigned to a given prefix if a new
> Capability has been exchanged.  It also discusses the semantics of
> I hope that those of you who are interested in this topic will provide your
> comments.  I've tried to make the draft compatible with existing
> I also removed most of the text that explains why it is a good idea to use
> BGP to distribute label bindings.  That text was important in the '90s, but
> now seems rather out of date.  However, I would welcome comments on
> whether an updated "motivation/positioning" section should be added.
> 
> Thanks,
> 
> Eric
>

---

From: Eric C Rosen <[email-masked]>
Date: Fri, 29 Jan 2016 10:22:23 -0500

> 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 no…
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 l…
Excellent point.  I'll add something about this, with a reference to 
section 3j of RFC 7606.
> 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.