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

[<[e-mail]>]

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:[e-mail]]
> Sent: Friday, January 15, 2016 7:01 PM
> To: DECRAENE Bruno IMT/OLN
> Cc: [e-mail]; BESS; [e-mail]
> 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.