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

[Eric C Rosen]

On 4/1/2016 4:23 PM, Robert Raszuk wrote:

Hi Eric,

I have read your proposed draft as well as watched this thread with a 
bit of an interest.


To me the best compromise - which is to agree with Bruno's points as 
well as address your intentions is simply to request new SAFI for 
3107bis.


I don't think that makes any sense at all.  The whole point is to ensure 
that 3107bis interoperates with 3107 for those features that are already 
deployed and are already multi-vendor interoperable.




From the draft you are really not updating 3107 base spec but 
obsoleting it which to me looks like a bad idea.


That is the nature of a "bis" draft.



You are even requesting to remove IANA reference to original spec.


That is the nature of a "bis" draft.

How would IANA know when is it safe to do that .. meaning when all 
implementations will not suddenly support and all deployments will 
enable 3107bis ?


I don't understand the issue you are raising.  I don't see any issue of 
"safety".




New SAFI requires a new capability which you are asking for anyway.


I don't understand the point you are making here.



As far as implementations please keep in mind very important point 
that some implementations treat SAFI 1 & 4 in single table and some in 
separate tables.


Yes, and these implementation differences have consequences that are 
discussed in the draft.


That when mixed with 3107bis may just explode if not in new set of 
bugs then with operational nightmare.


I don't understand the issue you are raising here.

While we are at this it would be much cleaner to mandate in the new 
spec to have 3107bis always to use separate tables as compared with 
from SAFI 1.


Two goals of this draft are (a) to document the consequences of the 
implementation differences, and (b) to avoid invalidating any particular 
implementation.  Obviously these goals would not be met if the spec 
mandated a particular implementation method.


As we all know 3107(bis) tries to add NNI to MPLS. However it must be 
very well stated that this is only one deployment option for 
interdomain encapsulation. I would very much like to see a section 
indicating that IPv6 or/and IPv4 be used as an alternative encap for 
those applications which require it and when needed provide local 
bindings between intradomain MPLS and interdomain IP.


This is entirely out of scope.








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

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

[Robert Raszuk]

Hi AC,

I am much less concern if we must be stuck to 3107 till retirement.

I think it would be much smoother on many levels to leave 3107 as is and
propose better solution for interdomain label exchange with BGP in new RFC.

With time we can obsolete 3107.

Such model has been done in the past and worked pretty well AFAIK.

Best,
r.



On Fri, Apr 1, 2016 at 11:29 PM, Acee Lindem (acee)  wrote:

> Hi Robert,
>
> I think this would defeat the purpose of clarifying RFC 3101 multi-label
> behavior in a BIS draft. Let’s see if we can reach consensus first.
>
> Thanks,
> Acee
>
> From: Idr  on behalf of Robert Raszuk <
> rob...@raszuk.net>
> Date: Friday, April 1, 2016 at 4:23 PM
> To: Eric C Rosen 
> Cc: Bruno Decraene , "m...@ietf.org" <
> m...@ietf.org>, BESS , IDR List 
> Subject: Re: [Idr] [bess] draft-rosen-mpls-rfc3107bis
>
> Hi Eric,
>
> I have read your proposed draft as well as watched this thread with a bit
> of an interest.
>
> To me the best compromise - which is to agree with Bruno's points as well
> as address your intentions is simply to request new SAFI for 3107bis.
>
> From the draft you are really not updating 3107 base spec but obsoleting
> it which to me looks like a bad idea.
>
> You are even requesting to remove IANA reference to original spec. How
> would IANA know when is it safe to do that .. meaning when all
> implementations will not suddenly support and all deployments will enable
> 3107bis ?
>
> New SAFI requires a new capability which you are asking for anyway.
>
> As far as implementations please keep in mind very important point that
> some implementations treat SAFI 1 & 4 in single table and some in separate
> tables. That when mixed with 3107bis may just explode if not in new set of
> bugs then with operational nightmare. While we are at this it would be much
> cleaner to mandate in the new spec to have 3107bis always to use separate
> tables as compared with from SAFI 1.
>
> Thx,
> Robert.
>
> PS.
>
> As we all know 3107(bis) tries to add NNI to MPLS. However it must be very
> well stated that this is only one deployment option for interdomain
> encapsulation. I would very much like to see a section indicating that IPv6
> or/and IPv4 be used as an alternative encap for those applications which
> require it and when needed provide local bindings between intradomain MPLS
> and interdomain IP.
>
>
> On Fri, Apr 1, 2016 at 6:44 PM, Eric C Rosen  wrote:
>
>> On 3/25/2016 7:25 AM, bruno.decra...@orange.com wrote:
>>
>>> I'm quite sure you have deployed  implementations, from several
 prominent vendors, that will not properly handle this case.

>>> 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.
>>>
>> I strongly disagree with this.  We should not ignore the facts just
>> because you don't like the way the facts were gathered.
>>
>> A better approach would be to have operators state whether they have any
>> deployments in which the "multiple labels" feature is used in a
>> multi-vendor environment.  It is very useful when working on a "bis" draft
>> to determine which features have been proven to work in a multi-vendor
>> environment and which have not.
>>
>> 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.
>>>
>>
>> There are deployed 3107 implementations which always assume that the NLRI
>> contains a single label.  If you tried to interwork these with 3107
>> implementations that send multiple labels , you will experience the kind of
>> disruption.  3107bis tries to allow the use of multiple labels while
>> preventing this sort of disruption from occurring.
>>
>> If you mean that some non-compliant implementation do not work, well
>>> let's fix them.
>>>
>>
>> The situation is that there is a commonly deployed "bug" in old
>> implementations, but it is not seen because the bug is in a feature that no
>> one has been using.  If new implementations use that feature, the bug will
>> be seen, and network disruption will occur. One could say "fix all the old
>> implementations", but it seems wiser to have new implementations avoid
>> tickling the bug.   The Capability is not proposed  for the purpose of
>> helping the vendors, it's there to help the operators.
>>
>> I'm not sure why you think there would be BGP session drops due to
>> 3107bis; if a 3107 implementation sends multiple labels to a 3107bis
>> implementation, I think the 3107bis implementation would do
>> "treat-as-withdraw" rather than "drop the session".
>>
>> Perhaps a reasonable approach for 3107bis would be the follow

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

[Acee Lindem (acee)]

Hi Robert,

I think this would defeat the purpose of clarifying RFC 3101 multi-label 
behavior in a BIS draft. Let’s see if we can reach consensus first.

Thanks,
Acee

From: Idr mailto:idr-boun...@ietf.org>> on behalf of 
Robert Raszuk mailto:rob...@raszuk.net>>
Date: Friday, April 1, 2016 at 4:23 PM
To: Eric C Rosen mailto:ero...@juniper.net>>
Cc: Bruno Decraene 
mailto:bruno.decra...@orange.com>>, 
"m...@ietf.org" mailto:m...@ietf.org>>, 
BESS mailto:bess@ietf.org>>, IDR List 
mailto:i...@ietf.org>>
Subject: Re: [Idr] [bess] draft-rosen-mpls-rfc3107bis

Hi Eric,

I have read your proposed draft as well as watched this thread with a bit of an 
interest.

To me the best compromise - which is to agree with Bruno's points as well as 
address your intentions is simply to request new SAFI for 3107bis.

From the draft you are really not updating 3107 base spec but obsoleting it 
which to me looks like a bad idea.

You are even requesting to remove IANA reference to original spec. How would 
IANA know when is it safe to do that .. meaning when all implementations will 
not suddenly support and all deployments will enable 3107bis ?

New SAFI requires a new capability which you are asking for anyway.

As far as implementations please keep in mind very important point that some 
implementations treat SAFI 1 & 4 in single table and some in separate tables. 
That when mixed with 3107bis may just explode if not in new set of bugs then 
with operational nightmare. While we are at this it would be much cleaner to 
mandate in the new spec to have 3107bis always to use separate tables as 
compared with from SAFI 1.

Thx,
Robert.

PS.

As we all know 3107(bis) tries to add NNI to MPLS. However it must be very well 
stated that this is only one deployment option for interdomain encapsulation. I 
would very much like to see a section indicating that IPv6 or/and IPv4 be used 
as an alternative encap for those applications which require it and when needed 
provide local bindings between intradomain MPLS and interdomain IP.


On Fri, Apr 1, 2016 at 6:44 PM, Eric C Rosen 
mailto:ero...@juniper.net>> wrote:
On 3/25/2016 7:25 AM, 
bruno.decra...@orange.com wrote:
I'm quite sure you have deployed  implementations, from several
prominent vendors, that will not properly handle this case.
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.
I strongly disagree with this.  We should not ignore the facts just because you 
don't like the way the facts were gathered.

A better approach would be to have operators state whether they have any 
deployments in which the "multiple labels" feature is used in a multi-vendor 
environment.  It is very useful when working on a "bis" draft to determine 
which features have been proven to work in a multi-vendor environment and which 
have not.

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.

There are deployed 3107 implementations which always assume that the NLRI 
contains a single label.  If you tried to interwork these with 3107 
implementations that send multiple labels , you will experience the kind of 
disruption.  3107bis tries to allow the use of multiple labels while preventing 
this sort of disruption from occurring.

If you mean that some non-compliant implementation do not work, well let's fix 
them.

The situation is that there is a commonly deployed "bug" in old 
implementations, but it is not seen because the bug is in a feature that no one 
has been using.  If new implementations use that feature, the bug will be seen, 
and network disruption will occur. One could say "fix all the old 
implementations", but it seems wiser to have new implementations avoid tickling 
the bug.   The Capability is not proposed  for the purpose of helping the 
vendors, it's there to help the operators.

I'm not sure why you think there would be BGP session drops due to 3107bis; if 
a 3107 implementation sends multiple labels to a 3107bis implementation, I 
think the 3107bis implementation would do "treat-as-withdraw" rather than "drop 
the session".

Perhaps a reasonable approach for 3107bis would be the following:

- A 3107bis implementation will not send multiple labels to a peer unless the 
Capability has been received from that peer.  (This prevents 3107bis 
implementations from tickling the 'bug' in 3107 implementations.)

- A 3107bis implementation will accept multiple labels from a peer even in the 
absence of the Capability.

Another approach would be to have a knob that determines 

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

[Robert Raszuk]

Hi Eric,

I have read your proposed draft as well as watched this thread with a bit
of an interest.

To me the best compromise - which is to agree with Bruno's points as well
as address your intentions is simply to request new SAFI for 3107bis.

>From the draft you are really not updating 3107 base spec but obsoleting it
which to me looks like a bad idea.

You are even requesting to remove IANA reference to original spec. How
would IANA know when is it safe to do that .. meaning when all
implementations will not suddenly support and all deployments will enable
3107bis ?

New SAFI requires a new capability which you are asking for anyway.

As far as implementations please keep in mind very important point that
some implementations treat SAFI 1 & 4 in single table and some in separate
tables. That when mixed with 3107bis may just explode if not in new set of
bugs then with operational nightmare. While we are at this it would be much
cleaner to mandate in the new spec to have 3107bis always to use separate
tables as compared with from SAFI 1.

Thx,
Robert.

PS.

As we all know 3107(bis) tries to add NNI to MPLS. However it must be very
well stated that this is only one deployment option for interdomain
encapsulation. I would very much like to see a section indicating that IPv6
or/and IPv4 be used as an alternative encap for those applications which
require it and when needed provide local bindings between intradomain MPLS
and interdomain IP.


On Fri, Apr 1, 2016 at 6:44 PM, Eric C Rosen  wrote:

> On 3/25/2016 7:25 AM, bruno.decra...@orange.com wrote:
>
>> I'm quite sure you have deployed  implementations, from several
>>> prominent vendors, that will not properly handle this case.
>>>
>> 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.
>>
> I strongly disagree with this.  We should not ignore the facts just
> because you don't like the way the facts were gathered.
>
> A better approach would be to have operators state whether they have any
> deployments in which the "multiple labels" feature is used in a
> multi-vendor environment.  It is very useful when working on a "bis" draft
> to determine which features have been proven to work in a multi-vendor
> environment and which have not.
>
> 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.
>>
>
> There are deployed 3107 implementations which always assume that the NLRI
> contains a single label.  If you tried to interwork these with 3107
> implementations that send multiple labels , you will experience the kind of
> disruption.  3107bis tries to allow the use of multiple labels while
> preventing this sort of disruption from occurring.
>
> If you mean that some non-compliant implementation do not work, well let's
>> fix them.
>>
>
> The situation is that there is a commonly deployed "bug" in old
> implementations, but it is not seen because the bug is in a feature that no
> one has been using.  If new implementations use that feature, the bug will
> be seen, and network disruption will occur. One could say "fix all the old
> implementations", but it seems wiser to have new implementations avoid
> tickling the bug.   The Capability is not proposed  for the purpose of
> helping the vendors, it's there to help the operators.
>
> I'm not sure why you think there would be BGP session drops due to
> 3107bis; if a 3107 implementation sends multiple labels to a 3107bis
> implementation, I think the 3107bis implementation would do
> "treat-as-withdraw" rather than "drop the session".
>
> Perhaps a reasonable approach for 3107bis would be the following:
>
> - A 3107bis implementation will not send multiple labels to a peer unless
> the Capability has been received from that peer.  (This prevents 3107bis
> implementations from tickling the 'bug' in 3107 implementations.)
>
> - A 3107bis implementation will accept multiple labels from a peer even in
> the absence of the Capability.
>
> Another approach would be to have a knob that determines whether the
> Capability needs to be used before multiple labels are advertised.
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Eric C Rosen]

On 3/25/2016 7:25 AM, bruno.decra...@orange.com wrote:

I'm quite sure you have deployed  implementations, from several
prominent vendors, that will not properly handle this case.

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.
I strongly disagree with this.  We should not ignore the facts just 
because you don't like the way the facts were gathered.


A better approach would be to have operators state whether they have any 
deployments in which the "multiple labels" feature is used in a 
multi-vendor environment.  It is very useful when working on a "bis" 
draft to determine which features have been proven to work in a 
multi-vendor environment and which have not.



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.


There are deployed 3107 implementations which always assume that the 
NLRI contains a single label.  If you tried to interwork these with 3107 
implementations that send multiple labels , you will experience the kind 
of disruption.  3107bis tries to allow the use of multiple labels while 
preventing this sort of disruption from occurring.



If you mean that some non-compliant implementation do not work, well let's fix 
them.


The situation is that there is a commonly deployed "bug" in old 
implementations, but it is not seen because the bug is in a feature that 
no one has been using.  If new implementations use that feature, the bug 
will be seen, and network disruption will occur. One could say "fix all 
the old implementations", but it seems wiser to have new implementations 
avoid tickling the bug.   The Capability is not proposed  for the 
purpose of helping the vendors, it's there to help the operators.


I'm not sure why you think there would be BGP session drops due to 
3107bis; if a 3107 implementation sends multiple labels to a 3107bis 
implementation, I think the 3107bis implementation would do 
"treat-as-withdraw" rather than "drop the session".


Perhaps a reasonable approach for 3107bis would be the following:

- A 3107bis implementation will not send multiple labels to a peer 
unless the Capability has been received from that peer.  (This prevents 
3107bis implementations from tickling the 'bug' in 3107 implementations.)


- A 3107bis implementation will accept multiple labels from a peer even 
in the absence of the Capability.


Another approach would be to have a knob that determines whether the 
Capability needs to be used before multiple labels are advertised.


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

[bess] IETF 95 meeting, final agenda

[thomas.morin]

Hi everyone,

We've just posted an updated agenda (last minute cancellation of 
draft-hao-bess-evpn-centralized-df-00, replaced by 
draft-hu-bess-l2vpn-service-yang-00).


https://www.ietf.org/proceedings/95/agenda/agenda-95-bess

Useful links:
- http://tools.ietf.org/wg/bess/agenda?item=agenda-95-bess.html
- https://datatracker.ietf.org/meeting/95/materials#bess

See you in Buenos Aires,

-Thomas


Thomas Morin :

The agenda posted below is the final agenda.

Thank you,
See you the next in Buenos Aires!

-Thomas

2016-03-22, Thomas Morin:

Hi everyone

We've just posted the **draft** agenda (still subject to changes) for
our meeting in Buenos Aires:

https://www.ietf.org/proceedings/95/agenda/agenda-95-bess

We were not able to accommodate for all requests for time, thank you for
your understanding.

Best,

-Thomas/Martin


WG Status
Co-Chairs, 10 min

Yang models
draft-dhjain-bess-bgp-l3vpn-yang
draft-shah-bess-l2vpn-yang-01
draft-brissette-bess-evpn-yang-01
Patrice, 10min

draft-li-bess-4pe-01
Zhenqiang, 10 min

draft-zzhang-bess-evpn-bum-procedure-updates-01
Jeffrey, 15 min

draft-rabadan-bess-evpn-pref-df-00
Jorge, 10 min

draft-rabadan-bess-evpn-ac-df-03
Jorge, 5 min

draft-rabadan-bess-vendor-evpn-route-00
Jorge, 10 min

draft-boutros-bess-evpn-auto-provisioning-01
Rex or Sami, 10 min

draft-boutros-bess-evpn-vpws-service-edge-gateway-02
Sami or Patrice, 10 min

draft-lin-bess-evpn-irb-mcast-02
Wen, 10 min

draft-sajassi-bess-evpn-l3vpn-multihoming-01
Ali, 10 min

draft-hao-bess-evpn-centralized-df-00
Weiguo, 10 min




___
BESS mailing list
BESS@ietf.org
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.

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