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

2016-04-05 Thread Eric C Rosen

On 4/4/2016 5:28 PM, bruno.decra...@orange.com wrote:

My issue is how do we prove that_nobody_  is using it? Proving the negative is 
hard, and silence is not part of the proof. To prove the negative, we would 
need explicit statement from everyone, which looks impossible.


I think you're exaggerating a little ;-)  I'm having trouble believing 
that you are unable to determine whether the 3107 "multiple labels" 
feature is in use in any of your company's deployments.


I think a more serious concern is how to avoid tickling the "day 1" bugs 
that may exist.  There may be implementations, supporting only a single 
label, that fail to set the S bit.  There may be implementations, 
supporting only a single label, that fail to check the S bit.  These 
"day 1" bugs will never have caused a problem, because the multiple 
labels feature has not been used.  We should endeavor to ensure that 
these"day 1" bugs do not cause a problem in the future if newer 
implementations begin to use the multiple labels feature.


Right now, we're arguing about which of the following two strategies is 
more likely to cause a problem:


1. In the first strategy, 3107bis requires the S bit to be set when 
there is a single label.  This will allow 3107bis to interoperate with 
3107 implementations of "multiple labels", but it will not allow 3107bis 
to interoperate with (buggy) 3107 implementations that send a single 
label, but don't set the S bit.


2. In the second strategy, 3107bis assumes, in the absence of the 
Capability, that there is only a single label, and doesn't bother to 
check the S bit.  This will allow 3107bis to interoperate with (buggy) 
implementations that send a single label but fail to set the S bit; it 
will not allow 3107bis to interoperate with (non-buggy) 3107 
implementations of multiple labels.


My argument is that the second strategy is better because it will be 
less disruptive.  This is based on my belief that the "day 1" bugs do 
exist, and that the "multiple labels" feature has yet to be deployed.


Your argument seems to be that the first strategy is better because (a)  
it only causes disruption if the 3107 implementation has a bug, in which 
case the bug can be fixed, and (b) if the second strategy is used, a 
3107-compliant implementation of multiple labels will fail to 
interoperate with a 3107bis-compliant implementation of multiple labels, 
and both implementors will claim compliance.


I think your argument is reasonable, the question is really just which 
strategy will cause less disruption.


Do other members of the WGs have opinions about this?









___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess


[bess] HEADS UP - discussion on draf-rosen-mpls-rfc3107bis in the mpls wg meeting in BA

2016-04-05 Thread Loa Andersson

Working Groups,

Please note that there will be a discussion on

draf-rosen-mpls-rfc3107bis

in the MPLS wg meeting, Wednesday morning. Currently the discussion is
planned to start at 11.25am, though the time may be subject to change.

/Loa
--


Loa Anderssonemail: l...@mail01.huawei.com
Senior MPLS Expert  l...@pi.nu
Huawei Technologies (consultant) phone: +46 739 81 21 64

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess


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

2016-04-05 Thread Eric C Rosen

On 4/5/2016 8:05 AM, Robert Raszuk wrote:
Wouldn't it be more flexible to simply define new attribute to carry  > the stack within any SAFI as an opaque to BGP data ? That way one 

can > easily use it in unicast SAFI or even in FlowSpec.

That can be done with the Tunnel Encapsulation attribute.  Look at, for 
example, at draft-previdi-idr-segment-routing-te-policy (though I think 
that document still needs quite a bit of work).



If as it turns out if the primary motivation for 3107bis is to  > distribute 
label stack for segment routing


3107bis fixes a number of problems in 3107, and it also specifies how to 
use the "multiple labels" feature without tickling known bugs in 
existing deployments.   One could argue about whether this is the best 
tool for various segment routing applications, but that's outside the 
scope of the draft.  And there are use cases that have nothing to do 
with segment routing; see, e.g., the discussion of context labels in 
section 4.









___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess


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

2016-04-05 Thread Robert Raszuk
Eric,

If as it turns out if the primary motivation for 3107bis is to distribute
label stack for segment routing that I do not think per destination prefix
is a sufficient granularity.

How with 3107(bis) you can match on the src of the packets ?

How you can match on the more granular information to steer packets
differently depending on the application ?

Wouldn't it be more flexible to simply define new attribute to carry the
stack within any SAFI as an opaque to BGP data ? That way one can easily
use it in unicast SAFI or even in FlowSpec.

Thx,
R.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess