Subject: Re: [mpls] [bess] draft-rosen-mpls-rfc3107bis

From: <[email-masked]>
Date: Thu, 24 Mar 2016 15:17:30 +0000

Hi Eric,

Thanks for your reply. Very much appreciated.

Sorry for the delay in responding, but I wanted more time to think about it. 

I'm fine with all your point, except one. Please see inline [Bruno].

> From: Eric C Rosen [mailto:[email-masked]]
> Sent: Friday, January 15, 2016 7:01 PM
> To: DECRAENE Bruno IMT/OLN
> Cc: [email-masked]; BESS; [email-masked]
> Subject: Re: [bess] draft-rosen-idr-rfc3107bis-00
> 
> 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.

[Bruno]
I understand that we have a different perspective on this. Nothing wrong, but please find below mine.

On my side, I think that the best approach is to have a 3107bis which is backward compatible with RFC3107.
I don't see why the IEFT would want to create a bis which is not compatible with the original RFC, especially since this incompatibility may be very disruptive in existing networks.

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

[Bruno]
I'm sorry, but I would need more facts on this. In particular which are the implementations that are known to be incapable of sending multiple labels, today and in the foreseeable future.
And even with such data, there is no guaranty as there may be implementation that we don't know about. Therefore, creating this incompatibility is risky. (Especially for network operator which are the ones which bare the risk)

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

1) again, I appreciate the work being done to handle the fact that some implementations are not compliant with RFC 3107.
2) I think you mean :s/old implementation/non compliant RFC 3107 implementation.      As of today "old implementation" are "existing implementations" and they are supposed to be compliant with RFC 3107.
3) "As far as I know" all the implementations claims to be compliant with RFC 3107, i.e. are expected to be able to receive multiple labels. And for the ones which we are using, they may have written this as part of a contractual agreement. So before considering making a 3107bis which is non backward compatible with RFC 3107, I would like to have the list of those implementations. In the absence of this, I assume that current implementations are indeed compliant with RFC 3107, just as they claim.

Thanks
-- Bruno

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

_________________________________________________________________________________________________________________________

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: Eric C Rosen <[email-masked]>
Date: Thu, 24 Mar 2016 14:14:09 -0400

On 3/24/2016 11:17 AM, [email-masked] wrote:
> I don't see why the IETF would want to create a bis which is not compatible with the original RFC,

It's typical in a bis draft to remove features that haven't been used.

> especially since this incompatibility may be very disruptive in existing networks.

My belief is that existing deployments don't use or support the multiple 
labels feature, and that any attempt to use it as specified in RFC3107 
will itself be disruptive to existing networks, because it will have 
interoperability issues and unpredictable results. Adding the "multiple 
labels" capability is a way to make the feature deployable without 
causing disruption.

> "As far as I know" all the implementations claim to be compliant with RFC 3107, i.e. are expected to be able to receive multiple labels.
I'm quite sure you have deployed  implementations, from several 
prominent vendors, that will not properly handle this case.

If you do have a deployed implementation that can receive multiple 
labels, what would you expect it to do with those labels?  RFC 3107 
doesn't say anything about what to do in this case, it just provides an 
encoding.

Have you ever tried to use the "multiple labels" feature?

---

From: <[email-masked]>
Date: Fri, 25 Mar 2016 11:25:58 +0000

> From: Eric C Rosen [mailto:[email-masked]] > Sent: Thursday, March 24, 2016 7:14 PM

- Not by making it non backward compatible with the current RFC, in a way which is very disruptive (BGP session shut and the session will stay down or keep cycling)
- On a side note, rfc3107bis does not remove the feature to advertise multiple labels. 

> labels feature,

Do you have data that support this? i.e. there are no deployments and no single implementation which advertise multiple labels? That sounds very hard to prove. Hence there will be a risk, and this risk is bared by network operators.
I don't see a reason why I would take that risk. 

> and that any attempt to use it as specified in RFC3107
> will itself be disruptive to existing networks,

IMHO RFC3107 is clear enough with respect to the encoding of multiple labels inside the BGP UPDATE. I fail to see which point would not be clear to someone.
But this is a theoretical discussion since so far, AFAIK, no major implementation has stated that they would not be able to understand NLRI received with multiple labels, and hence would shutdown the BGP session.

So I'm waiting for those hypothetical implementations to declare themselves. Then we'll see if they are compliant with RFC 3107 or if this is rather an implementation issue.

> because it will have
> interoperability issues and unpredictable results.

Any non-compliant implementation may create interoperability issues and unpredictable results.
>From an IETF standpoint, the question is whether a RFC 3107 implementation would create interoperability issues, up to shutting down the BGP session.

> Adding the "multiple

I agree with this point.
(although one could also discuss this, at it seems a way to accommodate non-compliant implementation)

> > "As far as I know" all the implementations claim to be compliant with RFC
> 3107, i.e. are expected to be able to receive multiple labels.

I'm waiting for this/these implementation(s) to make a public statement in this thread / IETF WGs. Then we can discuss whether the issue comes from RFCF3107 or from the implementation.
If none make a public statement, we should assume that all implementations are capable of receiving multiple labels, as per RFC 3107. And hence there is no need to make a 3107bis which is non backward compatible with RFC 3107.

> labels, what would you expect it to do with those labels? 

A priori, the sender said "For FEC X, uses this label stack", so any behavior compliant with this information e.g. what is described in your bis draft https://tools.ietf.org/html/draft-rosen-idr-rfc3107bis-00#section-4

> RFC 3107

RFC3107 describes the BGP encoding, aka "bits on the wire".
It does describe how to send and receive multiple labels from a BGP standpoint. This does not involve shutting down the BGP session when multiple labels are received.
 
> Have you ever tried to use the "multiple labels" feature?

If you mean by following RFC 3107, I'm not seeing why the BGP session would need to be shutdown.
If you mean that some non-compliant implementation do not work, well let's fix them.

And I don't see how making a rfc3107bis non backward compatible with RFC 3107 would improve the situation.