Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-redundant-mcast-source

[Eric C Rosen]

I am not aware of any relevant IPR.

On 6/7/2022 3:28 AM, slitkows.i...@gmail.com wrote:


Hi Authors,

We are still missing some IPR poll replies from some authors. Please 
help resolving it before we can move forward.


Thanks,

*From:*Sathappan, Senthil (Nokia - US/Sunnyvale) 


*Sent:* vendredi 20 mai 2022 01:58
*To:* Rabadan, Jorge (Nokia - US/Sunnyvale) ; 
slitkows.i...@gmail.com; 
draft-ietf-bess-evpn-redundant-mcast-sou...@ietf.org; bess@ietf.org

*Cc:* bess-cha...@ietf.org
*Subject:* Re: WGLC, IPR and implementation poll for 
draft-ietf-bess-evpn-redundant-mcast-source


As a co-author I am not aware of any relevant IPR.

Thanks,

Senthil.

*From: *slitkows.i...@gmail.com 
*Date: *Wednesday, May 18, 2022 at 12:23 AM
*To: *draft-ietf-bess-evpn-redundant-mcast-sou...@ietf.org 
, bess@ietf.org 


*Cc: *bess-cha...@ietf.org 
*Subject: *WGLC, IPR and implementation poll for 
draft-ietf-bess-evpn-redundant-mcast-source


Hello WG,
This email starts a two weeks Working Group Last Call on 
draft-ietf-bess-evpn-redundant-mcast-source

[1].
This poll runs until * the 1th of June *.
We are also polling for knowledge of any undisclosed IPR that applies to
this Document, to ensure that IPR has been disclosed in compliance 
with IETF

IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
If you are listed as an Author or a Contributor of this Document please
respond to this email and indicate whether or not you are aware of any
relevant undisclosed IPR. The Document won't progress without answers from
all the Authors and Contributors.
There is currently no IPR disclosed.
If you are not listed as an Author or a Contributor, then please 
explicitly
respond only if you are aware of any IPR that has not yet been 
disclosed in

conformance with IETF rules.
We are also polling for any existing implementation as per [2].
Thank you,
Stephane & Matthew
[1]
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-redundant-mcast-source/
[2]
https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw 



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

Re: [bess] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-mvpn-evpn-aggregation-label-04

[Eric C Rosen]

I am not aware of any undisclosed IPR relevant to this document.

- Eric


On 1/4/21 5:43 AM, slitkows.i...@gmail.com wrote:


We are still missing couple of IPR replies to close the WGLC: Eric, 
Ice (their email contact has to be updated).


In addition, we haven’t received any reply regarding an existing 
implementation. Is anyone aware of an implementation ?


Brgds,

Stephane

*From: *BESS mailto:bess-boun...@ietf.org>> on 
behalf of slitkows.i...@gmail.com  
mailto:slitkows.i...@gmail.com>>

*Date: *Friday, December 11, 2020 at 4:53 PM
*To: *draft-ietf-bess-mvpn-evpn-aggregation-la...@ietf.org 
 
>, 
bess@ietf.org  >
*Cc: *bess-cha...@ietf.org  
mailto:bess-cha...@ietf.org>>
*Subject: *[bess] WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-mvpn-evpn-aggregation-label-04


This email starts a two-week working group last call for 
draft-ietf-bess-mvpn-evpn-aggregation-label-04 [1]


Please review the draft and send any comments to the BESS list. Also, 
please indicate if you support publishing the draft as a standards 
track RFC.


This poll runs until the 28^th December 2020

We are also polling for knowledge of any undisclosed IPR that applies 
to this Document, to ensure that IPR has been disclosed in compliance 
with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).


If you are listed as an Author or a Contributor of this document 
please respond to this email and indicate whether or not you are aware 
of any relevant undisclosed IPR. The Document won't progress without 
answers from all the Authors and Contributors.


There is currently one IPR disclosure.

In addition, we are polling for knowledge of implementationsof this 
draft, per the BESS policy in [2].


Thank you,

Matthew & Stephane

[1]https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-evpn-aggregation-label/ 
 



[2]https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw 



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

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-irb-mcast-04

[Eric C Rosen]

I am unaware of any undisclosed IPR applicable to this document.

On 2/26/20 9:25 AM, slitkows.i...@gmail.com wrote:


Hi WG,

This email starts a two weeks Working GroupLast Call on 
draft-ietf-bess-evpn-irb-mcast-04 [2]


Please review the draft and send any comments to the BESS list. Also, 
please indicate if you support publishing the draft as a standards 
track RFC.


This poll runs until 11th March 2020.

We are also polling for knowledge of any undisclosed IPR that applies 
to this Document, to ensure that IPR has been disclosed in compliance 
with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).


If you are listed as an Author or a Contributor of this Document 
please respond to this email and indicate whether or not you are aware 
of any relevant undisclosed IPR. The Document won't progress without 
answers from all the Authors and Contributors.


There is currently one IPR disclosed.

https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-bess-evpn-irb-mcast

We are also polling for any existing implementation as per [1]. Please 
indicate if you are aware of any implementations.


 Thank you,

Stephane

[1]https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw

[2] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-irb-mcast/


___
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] REMINDER Re: WG Last Call, IPR and Implementation Poll for draft-ietf-bess-datacenter-gateway-04

[Eric C Rosen]

I am not aware of any undisclosed IPR that applies to this document.

On 3/11/20 5:23 AM, Adrian Farrel wrote:


Hi Matthew, WG,

I just posted -05

That is chiefly a keep-alive refresh, but I also updated the IANA 
section and uses to take account of the FCFS allocation of a code 
point for the document.


We still have an open discussion on a minor point with Stephane – I 
propose we roll that into the last call.


Wrt IPR

  * Eric Rosen
We may be able to rouse him from his retirement slumber, but
perhaps not.
I have a memory of Eric sending a cover-all email about Auth-48
and IPR, but:
- I may be imagining that
- I certainly can’t find it
  * Keyur Patel
We will prod him!

Best,

Adrian

*From:*Bocci, Matthew (Nokia - GB) 
*Sent:* 10 March 2020 11:35
*To:* adr...@olddog.co.uk; 
draft-ietf-bess-datacenter-gate...@ietf.org; bess@ietf.org
*Subject:* Re: REMINDER Re: [bess] WG Last Call, IPR and 
Implementation Poll for draft-ietf-bess-datacenter-gateway-04


Hi Adrian

Thanks for the response. Yes, please could you refresh the draft to 
keep it alive.


I’ve only received IPR responses from you, Luay and John. Please could 
you chase your other co-authors to respond as well.


I also didn’t see any other comments on the list. I suggest we put 
this document back in the WG LC queue so we can iron out any final 
discussion points before running another last call. It would probably 
make sense to inform the spring WG as well since this is really about 
interconnecting SR-enabled domains.


Cheers

Matthew

*From: *Adrian Farrel 
*Organisation: *Old Dog Consulting
*Reply to: *"adr...@olddog.co.uk" 
*Date: *Monday, 9 March 2020 at 13:00
*To: *"Bocci, Matthew (Nokia - GB)" , 
"draft-ietf-bess-datacenter-gate...@ietf.org" 
, "bess@ietf.org" 

*Subject: *RE: REMINDER Re: [bess] WG Last Call, IPR and 
Implementation Poll for draft-ietf-bess-datacenter-gateway-04


Hi Matt,

Sorry, did I miss this before?

I am not aware of any IPR that needs to be disclosed and has not 
already been disclosed for this document.


Of course (?) I support progressing this work which I think is a 
simple addition to enable quite a lot of function. I still regret that 
we used the “datacentre-gateway” file name as the document is about 
SR-enabled domains as indicated in the Title and Abstract.


Looking back at my email trail, there was a final point of discussion 
with Stephane that I am not sure was completely resolved: Stephane?


Also, since -04 expired, would you like me to post a keep-alive -05?

Thanks,

Adrian

*From:*Bocci, Matthew (Nokia - GB) 
*Sent:* 26 February 2020 11:29
*To:* draft-ietf-bess-datacenter-gate...@ietf.org; bess@ietf.org
*Subject:* REMINDER Re: [bess] WG Last Call, IPR and Implementation 
Poll for draft-ietf-bess-datacenter-gateway-04


WG

I have only seen one IPR responses to this WG last call and no 
comments. I will therefore extend it for another two weeks.


Regards

Matthew

*From: *BESS  on behalf of "Bocci, Matthew 
(Nokia - GB)" 

*Date: *Monday, 10 February 2020 at 16:17
*To: *"draft-ietf-bess-datacenter-gate...@ietf.org" 
, "bess@ietf.org" 

*Subject: *[bess] WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-datacenter-gateway-04



  This email starts a two-week working group last call for
  draft-ietf-bess-datacenter-gateway-04

Please review the draft and send any comments to the BESS list. Also, 
please indicate if you support publishing the draft as a standards 
track RFC.


This poll runs until Monday 24^th February 2020.

We are also polling for knowledge of any undisclosed IPR that applies 
to this Document, to ensure that IPR has been disclosed in compliance 
with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).


If you are listed as an Author or a Contributor of this document 
please respond to this email and indicate whether or not you are aware 
of any relevant undisclosed IPR. The Document won't progress without 
answers from all the Authors and Contributors.


There is currently no IPR disclosed.

We are also polling for any existing implementation as per [1]. Please 
indicate if you are aware of any implementations of the modified 
protocol described in this draft.


 Thank you,

Matthew

[1]https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw

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

Re: [bess] WG adoption and IPR poll for draft-rabadan-sajassi-bess-evpn-ipvpn-interworking-02 => MISSING IPR replies

[Eric C. Rosen]

I am not aware of any undeclared IPR relevant to this document.

On 3/5/2019 3:47 AM, stephane.litkow...@orange.com wrote:


Hi,

The document has a good level of support, however I’m missing two IPR 
replies from Eric and Wen.


Eric, Wen,

Could you please reply to the IPR poll ?

Thanks,

*From:*stephane.litkow...@orange.com 
[mailto:stephane.litkow...@orange.com]

*Sent:* Monday, February 18, 2019 16:53
*To:* draft-rabadan-sajassi-bess-evpn-ipvpn-interwork...@ietf.org; 
bess@ietf.org

*Cc:* bess-cha...@ietf.org
*Subject:* WG adoption and IPR poll for 
draft-rabadan-sajassi-bess-evpn-ipvpn-interworking-02


This email begins a two-week poll for adoption of 
draft-rabadan-sajassi-bess-evpn-ipvpn-interworking-02

[1]

Please review the draft and post any comments to the BESS working 
group list.


We are also polling for knowledge of any undisclosed IPR that applies 
to this Document, to ensure that IPR has been disclosed in compliance 
with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).


If you are listed as an author or a contributor of this document, 
please respond to this email and indicate whether or not you are aware 
of any relevant undisclosed IPR, copying the BESS mailing list. The 
document won't progress without answers from all the authors and 
contributors.


Currently, there are no IPR disclosures against this document.

If you are not listed as an author or a contributor, then please 
explicitly respond only if you are aware of any IPR that has not yet 
been disclosed in conformance with IETF rules.


This poll for adoption closes on Wednesday 4^th March 2019.

Regards,

Stephane and Matthew

[1] 
https://datatracker.ietf.org/doc/draft-rabadan-sajassi-bess-evpn-ipvpn-interworking/


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

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

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-nsh-bgp-control-plane

[Eric C Rosen]

I am not aware of any undisclosed IPR relevant to this document.

On 1/21/19 8:06 AM, stephane.litkow...@orange.com wrote:


Hello Working Group,

This email starts a three weeks Working Group Last Call on 
 draft-ietf-bess-nsh-bgp-control-plane [1].


This poll runs until *the 4th of February*.

We are also polling for knowledge of any undisclosed IPR that applies 
to this Document, to ensure that IPR has been disclosed in compliance 
with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).


If you are listed as an Author or a Contributor of this Document 
please respond to this email and indicate whether or not you are aware 
of any relevant undisclosed IPR. The Document won't progress without 
answers from all the Authors and Contributors.


We have several IPRs already disclosed.

If you are not listed as an Author or a Contributor, then please 
explicitly respond only if you are aware of any IPR that has not yet 
been disclosed in conformance with IETF rules.


We are also polling for any existing implementation as per [2].

Thank you,

    Stephane & Matthew

[1] 
https://datatracker.ietf.org/doc/draft-ietf-bess-nsh-bgp-control-plane/


    [2] 
https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw


_

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
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Rtgdir last call review of draft-ietf-bess-mvpn-expl-track-09

[Eric C Rosen]

On 9/12/2018 11:26 PM, Carlos Pignataro wrote:

I found the rational and specific details on what this document "Updates" from
three previous RFCs to be lacking, and confusing.


Carlos,

Thanks for your review.

I don't want to get caught up in the neverending discussion of exactly 
what constitutes an "Update".  This is being discussed right now on the 
IETF list, and it's quite clear that there is no consensus.  As usual, 
every possible opinion is dogmatically held by someone ;-)


The introduction of the expl-track draft explicitly points out a number 
of situations that are not adequately addressed in the prior RFCs, and 
for which the prior RFCs do not provide clear guidance. This is a 
potential source of interoperability problems.


The introduction also indicates a number of new features that are added 
by the draft.


Anyone implementing RFCs 6514, 6625, and/or 7524 will certainly be 
well-advised to read this draft in order to (a) make sure that they 
properly handle the situations that are not explicitly addressed by the 
prior RFCs, and (b) to make sure that they are aware of the new features 
so they can make an informed decision of whether to implement them.


I think this justifies the "Updates" status.


I recommend an "Updates from RFC XYZ" section in which there is a textual
explanation and ideally Old/New specifics on how this document updates previous
RFCs.


I think the introduction covers this in the appropriate level of detail; 
I really don't know what could be added.


Eric

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

Re: [bess] Comments on draft-ietf-bess-evpn-irb-mcast

[Eric C Rosen]

On 8/15/2018 4:07 AM, Ashutosh Gupta wrote:

Hi Folks,

I have following comments on draft-ietf-bess-evpn-irb-mcast. I also 
compare it to draft-sajassi-bess-evpn-mvpn-seamless-interop, which 
utilizes existing MVPN technology to achieve mcast-irb functionality 
in EVPN.



*1. Re-branding MVPN constructs into EVPN *
/evpn-irb/draft proposes a lot of MVPN constructs into EVPN. 
Originating multicast receiver interest "per PE"  instead of "per BD", 
use of selective tunnels are few examples. If solution really is 
achievable through MVPN, why do we need to re-brand it in EVPN?


As I and others have endeavored to explain in several messages to this 
list, the solution is not achievable by simply using MVPN routes and 
procedures.  Correct emulation of the ethernet muliticast service 
requires the addition of BD-specific information and procedures.  
Without this information, the distinction between "ES" and "BD" is 
lost.   This results in such problems as:


- Failure to correctly emulate ethernet behavior, and

- Inability to summarize routes on a per-subnet basis, thus requiring 
the MVPN PEs to be bombarded with host routes.


The seamless-mcast draft also severely underspecifies the behavior 
needed when interconnecting an EVPN domain to an MVPN domain that uses a 
different tunnel type, and does not appear to recognize either how 
common that scenario is, or how tricky it is to get that right.  (That's 
why the MVPN P-tunnel segmentation procedures are so intricate;  that's 
a whole area that seems to be ignored in the seamless-mcast draft.)


It's also worth reminding folks that 90% of EVPN is based on messages 
and procedures borrowed from L3VPN/MVPN, with the addition of 
information and procedures that are needed to do EVPN-specific things 
involving Ethernet Segments and Broadcast Domains.  This is certainly 
true of the EVPN procedures for advertising unicast IP routes, which do 
not "just use L3VPN".  The OISM proposal in the irb-mcast draft just 
follows along these lines.


Furthermore, it's worth noting that the so-called "seamless-mcast" draft 
has EVPN-specific procedures as well.  And more keep getting added as 
additional problems get discovered (e.g., the new intra-ES tunnels).   
It's very far from being "just use MVPN protocols as is".


Finally, one might also point out that the folks with the most in-depth 
knowledge of MVPN seem to be the least enthusiastic about the 
"seamless-mcast" draft.  Just saying ;-)


In the remainder of this message I want to focus on Ashutosh's 
criticisms of the OISM proposal (as we call the proposal in the 
irb-mcast draft).



*4. Data Plane considerations*
*
*
*4.1.* The data-plane nuances of solution has been underplayed. For 
example, if a PE1 has a (S, G) receivers in BD2, BD3 till BD10, 
whereas source S belongs in BD1 subnet on PE2. And if BD1 is not 
configured locally on PE1, a special BD (called SBD) is programmed as 
IIF in forwarding entry. Later if BD1 gets configured on PE1, it would 
cause IIF to change on PE1 from SBD to BD1.


So far correct.

This would result in traffic disruption for all existing receivers in 
BD2, BD3 till BD10.


The IIF in an (S,G) or (*,G) state can change at any time, due to 
distant (or not so distant) link failures, and/or due to other routing 
changes.  It changes whenever the UMH selection changes, and it changes 
if the ingress PE decides to move a flow from an I-PMSI to an S-PMSI.  
Of all the events that might cause a particular multicast state to 
change its IIF, the addition of a BD on the local PE does not seem to be 
one of the more frequent.


Some PIM implementations try to delay changing the IIF in a given (S,G) 
state until an (S,G) packet actually arrives from the new IIF.  However, 
such data-driven state changes introduce a lot of complexity.  MVPN has 
always tried to avoid data-driven state changes, and MVPN 
implementations will generally see some small amount of disruption when 
the IIF changes.  Methods for minimizing this are really an 
implementation matter.


In the case where a new BD is configured, there may be some risk of an 
(S,G) packet getting lost in the following situation:


- Time t0: The packet arrives and gets marked as being from the SBD.
- Time t1: The IIF changes from SBD to BD1
- Time t2: The packet is processed against the (S,G) state and discarded 
as having arrived from the wrong IIF


Given (a) how short the time t2-t0 is, (b) how infrequently new BDs get 
configured on a PE, and (c) the fact that there are many other causes of 
IIF changes, this does not seem like a real problem.  If it is regarded 
as a problem, resolving it would be an implementation matter.




*4.2. *Also, /evpn-irb/ solution proposes to relax the RPF check for a 
(*, G) multicast entry. This poses a great risk of traffic loops 
especially in transient network conditions in addition to poor 
debug-ability.


In the case where the receiving tenant systems ask for (*,G), and all 
the sources ar

Re: [bess] Comments on draft-sajassi-bess-evpn-mvpn-seamless-interop

[Eric C Rosen]

Eric> 1. It seems that the proposal does not do correct ethernet 
emulation.  Intra-subnet multicast only sometimes preserves MAC SA and 
IP TTL, sometimes not, depending upon the topology.


Ali> EVPN doesn't provide LAN service per IEEE 802.1Q but rather an 
emulation of LAN service. This document defines what that emulation means


The fact that the proposal doesn't do correct ethernet emulation cannot 
be resolved by having the proposal redefine "emulation" to mean 
"whatever the proposal does".


EVPN needs to ensure that whatever works on a real ethernet will work on 
the emulated ethernet as well; the externally visible service 
characteristics on which the higher layers may depend must be properly 
offered by the emulation.  This applies to both unicast and multicast 
equally.


Otherwise anyone attempting to replace a real ethernet with EVPN will 
find that not every application and/or protocol working on the real 
ethernet will continue to work on the EVPN.


Eric> TTL handling for inter-subnet multicast seems inconsistent as 
well, depending upon the topology.


Ali> BTW, TTL handling for inter-subnet IP multicast traffic is done 
consistent!


Consider the following in a pure MVPN environment:

- Source S is on subnet1, which is attached to PE1.

- Receivers R1 and R2 are on subnet2, which is attached to both PE1 and PE2.

- Subnet1 and subnet2 are different subnets.

Now every (S,G) packet will follow the same path: either (a) 
subnet1-->PE1-->subnet2 or (b) subnet1-->PE1-->PE2-->subnet2.


Both paths cannot be used at the same time, because L3 multicast will 
not allow both PE1 and PE2 to transmit the (S,G) flow to subnet2.  So an 
(S,G) packet received by R1 will always have the same TTL as the same 
packet received by R2.  TTL scoping will therefore work consistently; 
depending on the routing, and from the perspective of any given flow, 
the two subnets are either one hop away from each other, or two hops 
away from each other.


In the so-called "seamless-mcast" scheme, on the other hand, if R1 and 
R2 get the same (S,G) packet, each may see a different TTL. Suppose R1 
is on an ES attached to PE1 but not to PE2, S is on an ES attached to 
PE1 but not to PE2, and R2 is on an ES attached to PE2 but not to PE1.  
Then a given (S,G) packet received by R1 will have a smaller TTL than 
the same packet received by R2, even though R1 and R2 are on the same 
subnet.


Note that the seamless-mcast proposal does not provide the behavior that 
would be provided by MVPN, despite the claim that it is "just MVPN".


This user-visible inconsistency may break any use of TTL scoping, and is 
just the sort of thing that tends generate a stream of service calls 
from customers that pay attention to this sort of stuff.


In general, TTL should be decremented by 0 for intra-subnet and by 1 
(within the EVPN domain) for inter-subnet.  Failure to handle the TTL 
decrement properly will break anything that depends upon RFC 3682 ("The 
Generalized TTL Security Mechanism").  Have you concluded that no use of 
multicast together with RFC 3682 will, now or in the future, ever need 
to run over EVPN?  I'd like to know how that conclusion is supported.  
You may also wish to do a google search for "multicast ttl scoping".


A related issue is that the number of PEs through which a packet passes 
should not be inferrable by a tenant.  Any sort of multicast traceroute 
tool used by a tenant will give unexpected results if TTL is not handled 
properly; at the very least this will result in service calls.


The OISM proposal (as described in the irb-mcast draft) will decrement 
TTL by 1 when packets go from one subnet to another, as an IP multicast 
frame is distributed unchanged to the PEs that need it, and its TTL is 
decremented by 1 if an egress PE needs to deliver it to a subnet other 
than its source subnet.



The draft still makes the following peculiar claim:

"Based on past experiences with MVPN over last dozen years for supported 
IP multicast applications, layer-3 forwarding of intra-subnet multicast 
traffic should be fine."


Since MVPN does not do intra-subnet multicast, experience with MVPN has 
no bearing whatsoever on the needs of intra-subnet multicast.


Eric> 2. In order to do inter-subnet multicast in EVPN, the proposal 
requires L3VPN/MVPN configuration on ALL the EVPN PEs.  This is required 
even when there is no need for MVPN/EVPN interworking. This is portrayed 
as a "low provisioning" solution!


Ali> Using MVPN constructs doesn't requires additional configuration on 
EVPN PEs beyond multicast configuration needed for IRB-mcast operation.


I think you'll find that if you don't reconfigure all the BGP sessions 
to carry AFI/SAFIs 1/128, 2/128, 1/5, and 2/5, you'll have quite a bit 
of trouble running any of the native MVPN procedures ;-) This is perhaps 
the simplest example of additional configuration that is needed.


If doing MVPN/EVPN interworking, one needs to go to every EVPN PE and 
set u

Re: [bess] Shepherd's review of draft-ietf-bess-df-election-framework

[Eric C Rosen]

On 4/30/2018 12:40 PM, Ali Sajassi (sajassi) wrote:

The DF type is an 8-bit type, so there can be a single valid value.


Sorry, for some reason I thought it was a set of flags.  My mistake ;-(

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

Re: [bess] Shepherd's review of draft-ietf-bess-df-election-framework

[Eric C Rosen]

Let me add a couple of minor comments:

- The draft should state the action to be taken when receiving a route 
that has more than one DF Election Extended Community.  I think the two 
possible options are "treat the route as if it did not have any DF 
Election Extended Community", and "treat-as-withdraw" (defined in RFC 
7606).


- The draft should state the action to be taken when receiving a route 
whose DF Election Extended Community has more than one DF Type bit set.  
I think the procedures in the draft assume that at most one DF Type bit 
is set, and may not work properly if multiple DF Type bits are set.




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

Re: [bess] Short WGLC, IPR poll, implementation policy relax poll on draft-ietf-bess-mvpn-expl-track-08

[Eric C Rosen]

On 4/9/2018 10:32 AM, stephane.litkow...@orange.com wrote:
If you are listed as an Author or a Contributor of this Document 
please respond to this email and indicate whether or not you are aware 
of any relevant undisclosed IPR.


Not aware of any relevant undisclosed IPR.

As the document should be referred as the normative reference in 
draft-ietf-bier-mvpn,  we are requesting if you disagree/agree to 
progress the document without an implementation so the BIER document 
can progress as well.


Assuming the revised document passes WG LC, I'd like to see it progress 
as soon as possible, so that the bier-mvpn draft can be published as an 
RFC.


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

Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description

[Eric C Rosen]

[Jorge] my interpretation of RFC7432 is that IMET routes are mandatory 
to enable the handling of multi-destination traffic in a BD. But in a 
non-DF PE for a given ES and with no other ACs in the BD, assuming 
Ingress Replication, there is no such multi-destination traffic (Tx or 
Rx). So one could interpret that RFC7432 is ok with withdrawing the IMET 
route in that case.


If we consider the case of all-active multi-homing, then there may well 
be Tx multi-destination traffic in the scenario under discussion, as 
multicast traffic from a given ES could arrive at any PE attached to the 
ES, whether or not that PE is the DF.


The relevant section from RFC 7432 is:

11.  Handling of Multi-destination Traffic

   Procedures are required for a given PE to send broadcast or multicast
   traffic received from a CE encapsulated in a given Ethernet tag
   (VLAN) in an EVPN instance to all the other PEs that span that
   Ethernet tag (VLAN) in that EVPN instance.  In certain scenarios, as
   described in Section 12 ("Processing of Unknown Unicast Packets"), a
   given PE may also need to flood unknown unicast traffic to other PEs.

   The PEs in a particular EVPN instance may use ingress replication,
   P2MP LSPs, or MP2MP LSPs to send unknown unicast, broadcast, or
   multicast traffic to other PEs.

   Each PE MUST advertise an "Inclusive Multicast Ethernet Tag route" to
   enable the above.  The following subsection provides the procedures
   to construct the Inclusive Multicast Ethernet Tag route. Subsequent
   subsections describe its usage in further detail.

Interestingly, this says that the IMET route is mandatory to enable "the 
above", where "the above" is "send broadcast or multicast traffic 
received from a CE".  Note it says "send", not "receive".


If P2MP tunnels are used for the BUM traffic, the IMET route is 
certainly required to support all-active multi-homing.  If IR is used, 
or if single-active multi-homing is used, one could argue that RFC 7432 
didn't really need to require the IMET route. However, it does.


[John] Wouldn’t it be better to have this draft define a bit in the 
Multicast Flags extended community 
(https://tools.ietf.org/html/draft-ietf-bess-evpn-igmp-mld-proxy-01 
) 
indicating that that the originating PE is neither DF nor backup DF for 
this broadcast domain on any ES to which it is attached? This allows us 
to always advertise the IMET route and makes the situation explicit.  I 
think the consensus is that this situation is rare so the number of IMET 
route updates shouldn’t be excessive and we could also say that this bit 
is only set by EVPN DC GWs.


If it's worth doing at all, this would be a better method.  Alternatives 
would be omitting the PMSI Tunnel attribute, or setting the MPLS label 
in the PMSI Tunnel attribute to 0.


[Sandy] We’d considered alternative methods other than withdraw, such as 
extended community or something specific in PMSI Tunnel Attribute.  
Withdraw/don’t advertise RT3 approach was chosen for the following reasons;


 * Requires no change to protocol

Since the proposal changes the conditions under which an IMET route is 
originated, it is certainly changing the protocol.  (It's obvious that 
the finite state machine is changed.)  Perhaps what is meant is that the 
protocol change is backwards compatible with systems that implement only 
RFC7432.  But it does not appear to be backwards compatible with systems 
that have IRB, and the draft has no analysis of the impact on all the 
various extensions and proposed extensions to RFC7432.


 * Is computationally easier on all participating PE’s, to deal with a
   simple withdraw than to look for something in an update. For
   instance, on transition from BDF to NDF for example

These are of course not the only considerations.


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

Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description

[Eric C Rosen]

On 3/21/2018 12:36 PM, Rabadan, Jorge (Nokia - US/Mountain View) wrote:


This scenario definitively helps understand the use-case better. Still 
a bit specific but I think you should add this scenario to the draft, 
and again, make it Informational since there is no control plane 
change for this.




If I understand correctly, the draft does make a control plane change, 
since it describes situations in which IMET routes should not be 
originated.  This contradicts RFC 7432, and so would have to be 
considered a update to that, and hence a standards track document.


Since I wasn't at the BESS meeting (but did watch the video), it's 
possible I missed some of the discussion, but from my reading of the 
draft, I have the following concerns.


I'm not sure the draft properly describes the situations in which one 
may omit the IMET route.  It describes the situation in which a PE 
doesn't need to propagate, on any of its ACs, BUM traffic that it 
receives from the backbone.  However, if the PE has IRB interfaces, 
doesn't it need to receive some of the BUM traffic in order to process 
that traffic itself?  For example, if a PE is configured to be  a PIM 
router attached to two Broadcast Domains, BD1 and BD2, won't it need to 
receive PIM Hellos from BD1, even if it doesn't actually propagate those 
out the local AC attaching it to BD1?


At the meeting a DF election scheme was proposed in which, for a given 
 pair, there could be a different DF for each(S,G)  multicast 
flow.  I don't think the draft takes this into account.  I wonder how 
many other scenarios there are which the draft fails to consider.


Many EVPN drafts have been written on the presumption that IMET routes 
will always be originated.  Some of the drafts add flags or communities 
to the IMET routes to advertise capabilities of one sort or another.  
Every one of those drafts would need to be checked to see if it still 
works when some nodes do not originate IMET routes.


As future EVPN drafts are written, the authors (and reviewers) will now 
have to remember that they cannot presume that all the PEs attached to a 
given BD are originating IMET routes for that BD. This creates more 
complexity, more corner cases, and ultimately, more specification bugs.


Still, one might consider adopting this complication if it were a big 
win.  But it only seems to apply to one specific (and not very common) 
scenario, and from the discussion at the microphone it wasn't clear to 
me that the co-authors are even on the same page about just what that 
scenario is (recall the discussion about whether the diagram in the 
draft does or does not depict the intended use case).









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

Re: [bess] Call for adoption: draft-zzhang-bess-mvpn-msdp-sa-interoperation-01

[Eric C Rosen]

While MSDP may be a mess, customers do use it, and this draft describes 
a scheme that is useful for many such customers, and which is often 
requested.  So I support the adoption of this draft by the WG.


On 2/26/2018 3:01 AM, stephane.litkow...@orange.com wrote:


Hello working group,

This email starts a two-week call for adoption on

draft-zzhang-bess-mvpn-msdp-sa-interoperation-01 [1] as a BESS Working 
Group Document.


Please state on the list if you support the adoption or not (in both 
cases, please also state the reasons).


This poll runs until *the 19th of March*.

We are also polling for knowledge of any undisclosed IPR that applies 
to this Document, to ensure that IPR has been disclosed in compliance 
with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).


If you are listed as an Author or a Contributor of this Document 
please respond to this email and indicate whether or not you are aware 
of any relevant undisclosed IPR. The Document won't progress without 
answers from all the Authors and Contributors.


Currently no IPR has been disclosed against this Document.

If you are not listed as an Author or a Contributor, then please 
explicitly respond only if you are aware of any IPR that has not yet 
been disclosed in conformance with IETF rules.


Thank you

(Martin), Matthew, Stéphane

bess chairs

[1] 
https://datatracker.ietf.org/doc/draft-zzhang-bess-mvpn-msdp-sa-interoperation/


_

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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bess&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=pDfFk-uiQuAUkZJHe8GKaNs7gK2g8_dA5DnBh35f75A&s=p8yYuOb47PC57_wH4yhrUMcRLW52Aqbla9pfPU65efY&e=


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

Re: [bess] I-D Action: draft-ietf-bess-mvpn-expl-track-07.txt

[Eric C Rosen]

On 2/22/2018 3:10 AM, stephane.litkow...@orange.com wrote:

Hi Eric,



Thanks a lot for the update.


And thank you for your continued attention to the details.  I have 
posted -08.  Responses in-line.




Couple of more comments:



Section 2:

I still have some concern about these two sentences:

1)"This flag SHOULD NOT be set

unless it is known that all the PEs that are to receive the route

carrying the PTA support the flag."

2)"By setting LIR as well as

LIR-pF, one forces a response to be sent by an egress node that does

not support LIR-pF."



[SLI] As per 1), the situation described in 2) should not happen

Do we agree that this should not happen ?

I think we can make the text more clear about the implications of setting the 
LIR-pf in a partial deployment scenario.

We can add a text like after 1):

"Setting the LIR-pF in a network where only a subset of PEs supports it prevents the 
ingress PE to have a complete view of the receiving PEs."



We may also modify 2) as follows:

OLD

By setting LIR as well as

LIR-pF, one forces a response to be sent by an egress node that does

not support LIR-pF.  It is possible to tell from that response that

the egress node does not support LIR-pF.  This may be an aid to

troubleshooting.

NEW

By setting LIR as well as

LIR-pF, one forces a response to be sent by an egress node that does

not support LIR-pF.  It is possible to tell from that response that

the egress node does not support LIR-pF.  As the support of LIR-pF is 
recommended on all PEs, this situation should not happen.

   However, in case of deployment error, this may be an aid to troubleshooting.


[Eric] In revision -08, I have reworked this text to indicate what will 
happen in the case of deployment errors, and how such errors can be 
detected.  However, I wouldn't necessarily guarantee that there are no 
corner cases in which a deployment error might go undetected.










Section 5.2:

"The encoding of these Leaf A-D routes is similar to the encoding of

the Leaf A-D routes described in section 6.2.2 of [RFC7524], which

were designed for the support of "global table multicast".  However,

that document sets the RD to either 0 or -1; following the procedures

of this document, the RD will never be 0 or -1.  Therefore Leaf A-D

routes constructed according to the procedures of this section can

always be distinguished from the Leaf A-D routes constructed

according to the procedures of section 6.2.2 of [RFC7524].  Also,

Leaf A-D routes constructed according to the procedures of this

section are VPN-specific routes, and will always carry an IP-address-

specific Route Target, as specified in [RFC6514]."



[SLI] I'm wondering if this text is still required as we do not modify the RD 
compared to RFC6514.



[Eric] There are two situations in which an ingress node might receive a 
Leaf A-D route whose route key field is not identical to the NLRI of a 
current x-PMSI A-D route originated by the ingress node.  One situation 
is specified in RFC 7524.  The other is specified in the explicit 
tracking draft.  I think it is useful to point out that the ingress node 
can distinguish between these two cases when it receives such a Leaf A-D 
route.


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

Re: [bess] I-D Action: draft-ietf-bess-mvpn-expl-track-07.txt

[Eric C Rosen]

The -07 rev of draft-ietf-bess-mvpn-expl-track has the following changes 
from the -06 version:


1. The draft now says that it updates RFCs 6514 and 7524 as well as RFC 
6625.  I think this is now necessary because the draft modifies the 
ingress node processing of received Leaf A-D routes that carry a PTA 
with the LIR-pF flag set.  I'm not sure what the objective criteria are 
supposed to be for "updates",  but it makes sense that anyone trying to 
implement RFC 6514 or 7524 read this document as well.


2. There are a number of textual changes and clarifications in response 
to comments by Stephane Litkowski.


3. The boilerplate is updated to be in accord with RFC 8174.

4. There is now a warning that the LIR-pF flag should not be set unless 
it is known a priori that all nodes support it.


5. It is now REQUIRED that the LIR flag be set whenever the LIR-pF flag 
is set in the PTA carried by an S-PMSI A-D route.


6. The peculiar idea of modifying the RD of a Leaf A-D route originated 
in response to the LIR-pF flag has been eliminated. (Mea culpa.)


7. A Leaf A-D route originated in response to the LIR-pF flag is now 
REQUIRED to carry a PTA with the LIR-pF flag set.


8. Text has been added specifying when such a PTA should specify "no 
tunnel info" and when it should specify a tunnel type.


9. Text has been added to deal with the case where a wildcard S-PMSI A-D 
route has (a) LIR-pF set in its PTA, and (b) also specifies a tunnel 
type of Ingress Replication. The new text allows a Leaf A-D route sent 
in response to the LIR-pF bit to carry a PTA specifying an MPLS label.


10. Text has been added to say that the specifications for how to use 
new "tunnel types" with MVPN must specify procedures for originating 
Leaf A-D routes in response to S-PMSI A-D routes whose PTAs specify the 
given tunnel type and have the LIR-pF flag set.  An informational 
reference to the bier-mvpn draft has been added as an example.


11. A section has been added discussing how an ingress node responds to 
a Leaf A-D route that carries a PTA with the LIR-pF bit set.


I hope those who are interested will review the diffs and send feedback 
to the list.




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

Re: [bess] I-D Action: draft-ietf-bess-evpn-irb-mcast-00.txt

[Eric C Rosen]

FYI, this draft is just a refresh of 
draft-lin-bess-evpn-irb-mcast-04.txt, with only some changes in the 
boilerplate (per RFC 8174) and some updates to the references.


On 2/13/2018 3:11 PM, internet-dra...@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the BGP Enabled ServiceS WG of the IETF.

 Title   : EVPN Optimized Inter-Subnet Multicast (OISM) 
Forwarding
 Authors : Wen Lin
   Zhaohui Zhang
   John Drake
   Eric C. Rosen
   Jorge Rabadan
   Ali Sajassi
Filename: draft-ietf-bess-evpn-irb-mcast-00.txt
Pages   : 72
Date: 2018-02-13

Abstract:
Ethernet VPN (EVPN) provides a service that allows a single Local
Area Network (LAN), i.e., a single IP subnet, to be distributed over
multiple sites.  The sites are interconnected by an IP or MPLS
backbone.  Intra-subnet traffic (either unicast or multicast) always
appears to the endusers to be bridged, even when it is actually
carried over the IP backbone.  When a single "tenant" owns multiple
such LANs, EVPN also allows IP unicast traffic to be routed between
those LANs.  This document specifies new procedures that allow inter-
subnet IP multicast traffic to be routed among the LANs of a given
tenant, while still making intra-subnet IP multicast traffic appear
to be bridged.  These procedures can provide optimal routing of the
inter-subnet multicast traffic, and do not require any such traffic
to leave a given router and then reenter that same router.  These
procedures also accommodate IP multicast traffic that needs to travel
to or from systems that are outside the EVPN domain.


The IETF datatracker status page for this draft is:
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dbess-2Devpn-2Dirb-2Dmcast_&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=jOiBBQ6wFN6KIPuIY_yUoHAmSdV4mjeb_0wDoNuxeo8&s=64K9IlRkCFQ2SEk22CHRPFDIV-tbgB2vFZggUGDTrtk&e=

There are also htmlized versions available at:
https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dbess-2Devpn-2Dirb-2Dmcast-2D00&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=jOiBBQ6wFN6KIPuIY_yUoHAmSdV4mjeb_0wDoNuxeo8&s=IqalBZN_p6GIqZ_nuS68TFV1AAGXj3S_4hpPFa-e32o&e=
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dbess-2Devpn-2Dirb-2Dmcast-2D00&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=jOiBBQ6wFN6KIPuIY_yUoHAmSdV4mjeb_0wDoNuxeo8&s=mo_0ZW7h-1IBW2F_A1LpEcQbcBaYozCtBYZZk72uKtI&e=


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=jOiBBQ6wFN6KIPuIY_yUoHAmSdV4mjeb_0wDoNuxeo8&s=kFa4BM-OZifleMwtT0vglbN0tutuduOr8mQThKBHS98&e=

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_i-2Dd-2Dannounce&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=jOiBBQ6wFN6KIPuIY_yUoHAmSdV4mjeb_0wDoNuxeo8&s=cTZuXU8SvGCzF1shxmA9RMoKHcJ_Jusk6Yx-1zElfmg&e=
Internet-Draft directories: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ietf.org_shadow.html&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=jOiBBQ6wFN6KIPuIY_yUoHAmSdV4mjeb_0wDoNuxeo8&s=d5gryj_HgHgQzuKVegbadboSnMI0vVe54WQjT2Ho3-8&e=
or 
https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_ietf_1shadow-2Dsites.txt&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=jOiBBQ6wFN6KIPuIY_yUoHAmSdV4mjeb_0wDoNuxeo8&s=DLbhJ-JBwqKqqDxX5nopUH8y4mUICtCqQlzCb58Ym-o&e=


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

Re: [bess] Shepherd's review of draft-ietf-bess-mvpn-expl-track

[Eric C Rosen]

On 1/16/2018 11:29 AM, Eric C Rosen wrote:

“If the LIR-pF flag is set in a given PTA, the LIR flag of that PTA
   SHOULD also be set.”
[SLI] Why not using a MUST ?


[Eric] If all the PEs support the LIR-pF flag, the procedures will 
work as intended even if the LIR flag is not set.  So I don't think a 
MUST is appropriate.


Thinking about this more, I now think you are right that MUST would be 
better.  By saying MUST, we remove an unnecessary variation in behavior.


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

Re: [bess] Shepherd's review of draft-ietf-bess-mvpn-expl-track

[Eric C Rosen]

On 1/24/2018 2:25 AM, stephane.litkow...@orange.com wrote:

“The procedures of [RFC6625] do not clearly state how to handle an
   S-PMSI A-D route if its NLRI contains wild cards, but its PTA
   specifies "no tunnel info".”
  
[SLI] I quickly ran over RFC6625, it does not mention anything on explicit tracking or Leaf A-D routes.So we assume that RFC6513/6514 only applies here.



[Eric] RFC 6625 specifies the handling of wildcard S-PMSI A-D routes, 
but did not consider the case where the S-PMSI A-D routes do not carry 
a PTA.  This document corrects that.


[SLI2] My point was that RFC6625 does not specify anything regarding 
explicit tracking while your sentence says  “do not clearly state”. In 
reality, it does not state anything about how explicit tracking works 
for wildcard routes.




I see your point now.  I propose to change this in the -07 rev to:

  The procedures of [RFC6625] do not address the case of an S-PMSI

  A-D route whose NLRI contains wild cards, but whose PTA specifies

  "no tunnel info".



“If the LIR-pF flag is set in a given PTA, the LIR flag of that PTA
    SHOULD also be set.”
[SLI] Why not using a MUST ?


[Eric] If all the PEs support the LIR-pF flag, the procedures will 
work as intended even if the LIR flag is not set.  So I don't think a 
MUST is appropriate.


[SLI2] Ok so do we really care of having the LIR flag set ? If not, 
couldn’t be a MAY ? I’m just wondering how important is to set the 
LIR-flag here. It seems to be linked to the next sentence between 
parenthesis.


I understand that setting both allows to always have a response (per 
flow or not per flow). Can we see this as an optional feature ?




My reasoning for suggesting that LIR SHOULD be set whenver LIR-pF is set 
is captured in the following sentence from the draft:


   (By setting LIR as well as LIR-pF, one forces a

   a response to be sent by an egress node that does not support LIR-pF,

   and it is possible to tell from that response that the egress node

   does not support LIR-pF.)


This is intended to be a troubleshooting aid.  Nodes that don't support 
LIR-pF will respond to the LIR flag, and the response to the LIR flag is 
different than the response to the LIR-pF flag, because the RD is 
modified.  LIR-pF really shouldn't be used unless all the PEs support 
it, and this is a way of detecting  a configuration/provisioning problem.


I would be happy to hear others' opinions on whether this is a 
worthwhile hack.



“We also introduce a new notion: the "match for tracking".  This
    differs from the "match for reception" as follows:”
[SLI] It would be better to give a definition of the “match for tracking” 
before giving the rules. Here you’re explaining only the rules, not the 
difference in the meaning. Wouldn’t it be easier to tell that the 
implementation MUST consider only the S-PMSI A-D routes that have a LIR flag 
and/or LR-pF flag set and then run the same rules as the RFC6625. Why do you 
want to have S-PMSI routes with PTA and LIR unset in your route list for “match 
for tracking” ? You need to take care here on your text proposal as one of your 
previous statement updates the RFC6625 and the match reception procedure, so 
the rules to be applied are the original one from RFC6625 and not the updated 
one.


[Eric] IMO, the clearest way to express this is to give the rules and 
then illustrate with a couple of examples.


[SLI2] You are right, I’m just challenging the fact that the text says 
that it will explain how the match for tracking differs from the match 
from reception but it does not. It’s the job of the reader to deduce 
the difference from the rule you are giving.




Okay, I get your point now.

In the -07 rev, I propose to eliminate the sentence "This differs ...", 
and to add the following sentence after the rule:


  That is, the procedure for finding the match for tracking takes

  into account S-PMSI A-D routes whose PTAs specify "no tunnel

  information" and that have either LIR or LIR-pf set.  The

  procedure for finding the match for reception ignores such routes.



“   Also note that if a match for tracking does not have the LIR flag or
    the LIR-pF flag set, no explicit tracking information will be
    generated.  See Section 5.”
[SLI] Again I do not see the value added of keeping such route as a match for 
tracking as there is no tracking requested.


[Eric] As the terms are defined, there is always a "match for 
tracking" route for each flow.    If tracking is not requested, this 
route will have LIR and LIR-pF clear.  There are no unnecessary routes.


[SLI2] Agree, but based on my understanding such a route (with LIR and 
LIR-pF clear) cannot be a match for tracking by definition : “ignore any S-PMSI A-D route whose PTA specifies


  "no tunnel information", but does not have either LIR or LIR-pF

Set”

So the statement  “if a match for tracking does not have the LIR flag or the 
LIR-pF flag set” is IMO wrong.

Re: [bess] Comments on draft-ietf-bess-mvpn-expl-track-03

[Eric C Rosen]

Thanks for delving into the details here.  This part of the writeup is 
very confusing (for which I have no one to blame but myself); I've tried 
to clarify in the -06 revision.


On 1/18/2018 9:51 PM, Xiejingrong wrote:


Issue clarification:

According to chap 5.2 of this document:

In a [IngressPE--EgressABR--EgressPE] topology, IngressPE send a 
Wildcard S-PMSI(*,*) route with PTA(flag), whose NLRI is 
donated as  SPMSI(type<0/1/2>RD,*,*,IngressPE).


This SPMSI route will be relayed by EgressABR to EgressPE with PTA 
flag untouched.




The flags are required to be left untouched only if the PTA specifies 
"no tunnel info".


Then EgressPE will generate ONE LeafAD route with 
NLRI(type<0/1/2>RD,*,*,IngressPE,EgressPE) and RT, and 
N(N>=0) LeafAD routes with 
NLRI(type<16/17/18>RD,S,G,IngressPE,EgressPE) and RT.


Then according to chap 5.3  of this document:

EgressABR will only send a Leaf A-D route.

I guess, the said “a Leaf A-D route” should be the ONE of 
LeafAD(type<0/1/2RD,*,*,IngressPE,EgressABR) with RT.


Then how should EgressABR deal with the the N(N>=0) LeafAD routes with 
NLRI(type<16/17/18>RD,S,G,IngressPE,EgressPE) and RT ?


It is not clarified in RFC7524 either. See chap 7.1 of RFC7524, which 
only clarify LeafAD route with type<0/1/2>RD.


Should such LeafAD route with type<16/17/18>RD be accepted and 
installed by EgressABR ?


And then ‘relay’ back to IngressPE, and thus enable IngressPE explicit 
tracking inside the ingress “segmentation domain” ?




EgressABR originates Leaf A-D routes of its own if and when it knows 
that it has downstream receivers that are interested in receiving flows 
from IngressPE.  It may originate more than one Leaf A-D route if LIR-pF 
is set in the S-PMSI A-D route's PTA.



Question clarification:

(1)Should such LeafAD routes with type<16/17/18>RD be accepted and 
installed by EgressABR ? This draft does not describe this.




If such routes carry EgressABR's import RT, and if their NLRIs match the 
NLRI of an S-PMSI A-D route installed by EgressABR, the Leaf A-D routes 
will be accepted and installed by EgressABR.  They are also relayed 
upstream (after changing the RT), as described in section 5.3.


(2)If the said Leaf A-D routes (with RD type 16/17/18) be installed by 
EgressABR, then according to your answer, the Leaf A-D routes (with RT 
changed) will be ‘relay’ back to IngressPE. Right?  This draft does 
not describe this either.


(3)If the above two are correct, then We can use PTAflag=LIR+LIRpF> in segmented P-tunnels scenario? But 
 seems to imply that LIR-pF flag can’t be 
used in Segmented P-tunnels scenario. Its chap 2.2.2 requires that, 
LIR-pF Flag is used only when non segmented P-tunnels are used.




Yes, PTA can be used if segmented tunnels 
are used, and will enable the ingress PE to discover the egress PEs.  
However, there will not be a tunnel directly from the ingress PE to 
egress PEs that are on the other side of a segmentation boundary.


Draft-ietf-bier-mvpn states that, if segmented tunnels are used, LIR-pF 
should not be set in a PTA that specifies "BIER".  It doesn't say that 
the flag should not be set in a PTA that specifies "no tunnel info".


If you are using segmented BIER, the segmentation boundary router needs 
to change the BitString when a packet goes from one BIER domain to 
another.  This means that when the router receives a BIER packet, it 
needs to be able to infer, from the MPLS label following the BIER 
header, what the new BitString is.  The value of the new BitString 
depends on the flow being carried.  Since the labels are assigned by the 
S-PMSI A-D routes, the ingress needs to originate an S-PMSI A-D route 
for each flow.  Thus it can't really benefit from the LIR-pF technique 
when segmentation is used.  (On the other hand, segmented Ingress 
Replication could benefit from the LIR-pF technique, because in that 
case, the labels are assigned by the Leaf A-D routes.)




Thanks.

XieJingrong

*From:*Eric C Rosen [mailto:ero...@juniper.net]
*Sent:* Thursday, January 18, 2018 11:49 PM
*To:* Xiejingrong ; bess@ietf.org
*Subject:* Re: [bess] Comments on draft-ietf-bess-mvpn-expl-track-03

I apologize for the delay in answering this message.

On 12/21/2017 4:22 AM, Xiejingrong wrote:

I have a comment on draft-ietf-bess-mvpn-expl-track-03.

The chap 5.3 of this document said:

Furthermore, if the PTA specifies "no tunnel info", the LIR and
LIR-pF

flags in the PTA MUST be passed along unchanged.

   This will ensure that an egress ABR/ASBR only sends a Leaf A-D
route

   in response to a "match for tracking" if it is on the path to an

   egress PE for the flow(s) identified in the corresponding
S-PMSI A-D

   route.

The issue is as follow:

In a [IngressPE--EgressABR--EgressPE] topology, IngressPE send a
Wildcard

Re: [bess] Call for adoption: draft-lin-bess-evpn-irb-mcast

[Eric C Rosen]

Support (as co-author).  I am not aware of any relevant IPR.

On 1/11/2018 5:11 AM, Martin Vigoureux wrote:

Hello working group,

This email starts a two-week call for adoption on 
draft-lin-bess-evpn-irb-mcast-04 [1] as a BESS Working Group Document.


Please state on the list if you support the adoption or not (in both 
cases, please also state the reasons).


This poll runs until *the 26th of January*.

We are also polling for knowledge of any undisclosed IPR that applies
to this Document, to ensure that IPR has been disclosed in compliance
with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more
details).
If you are listed as an Author or a Contributor of this Document please
respond to this email and indicate whether or not you are aware of any
relevant undisclosed IPR. The Document won't progress without answers
from all the Authors and Contributors.

Currently no IPR has been disclosed against this Document.

If you are not listed as an Author or a Contributor, then please 
explicitly respond only if you are aware of any IPR that has not yet 
been disclosed in conformance with IETF rules.


Thank you

Martin & Stéphane
bess chairs

[1] 
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dlin-2Dbess-2Devpn-2Dirb-2Dmcast_&d=DwID-g&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=7stPyA6kx51d5f5KWpyDfBgEFvAcVWze4dSLeBo-CU0&s=z4hVPM7sSHQ0TMPjGtGCgLP0bm6MtvyY2ctPT6kbSCQ&e=


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

Re: [bess] Comments on draft-ietf-bess-mvpn-expl-track-03

[Eric C Rosen]

I apologize for the delay in answering this message.

On 12/21/2017 4:22 AM, Xiejingrong wrote:


I have a comment on draft-ietf-bess-mvpn-expl-track-03.

The chap 5.3 of this document said:

Furthermore, if the PTA specifies "no tunnel info", the LIR and LIR-pF

flags in the PTA MUST be passed along unchanged.

   This will ensure that an egress ABR/ASBR only sends a Leaf A-D route

   in response to a "match for tracking" if it is on the path to an

   egress PE for the flow(s) identified in the corresponding S-PMSI A-D

   route.

The issue is as follow:

In a [IngressPE--EgressABR--EgressPE] topology, IngressPE send a 
Wildcard S-PMSI(*,*) route with PTA(flag), whose NLRI is 
donated as  SPMSI(type<0/1/2>RD,*,*,IngressPE). This SPMSI route will 
be relayed by EgressABR to EgressPE with PTA flag untouched. Then 
EgressPE will generate ONE LeafAD route with 
NLRI(type<0/1/2>RD,*,*,IngressPE,EgressPE) and RT and 
N(N>=0) LeafAD routes with 
NLRI(type<16/17/18>RD,S,G,IngressPE,EgressPE) and RT. All 
according to chap 5.2 of this document.


Then according to chap 5.3  of this document:

IngressABR will only send a Leaf A-D route, It should be the ONE of 
LeafAD(type<0/1/2RD,*,*,IngressPE,EgressABR) with RT.




In the example above, there is an "EgressABR" but not an "IngressABR".  
So I'm not completely sure that I understand your question.


Then how should IngressABR deal with the the N(N>=0) LeafAD routes 
with NLRI(type<16/17/18>RD,S,G,IngressPE,EgressPE) and RT ?


It is not clarified in RFC7524 either. See chap 7.1 of RFC7524, which 
only clarify LeafAD route with type<0/1/2>RD.


Should such LeafAD route with type<16/17/18>RD be accepted and 
installed by EgressABR, and then ‘relay’ back to IngressPE, and thus 
enable IngressPE explicit tracking inside the ingress “segmentation 
domain” ?




The intention is the following.  Suppose an egress ABR/ASBR satisfies 
the following two conditions:


1. It has installed an S-PMSI A-D route  with the following properties:

- its NLRI has wildcards for S and G,
- its NLRI specifies PE1 as the ingress PE,
- its PTA specifies "no tunnel info" and has LIR-pF set.

2. It has installed one or more Leaf A-D routes whose NLRI specifies 
(S,G) with PE1 as ingress PE


Then the ABR/ASBR should originate a Leaf A-D route (with RD type 
16/17/18) specifying (S,G) with ingress PE1.
The Leaf A-D route would be withdrawn when one of these conditions no 
longer holds.


Does this answer your question?


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

Re: [bess] Shepherd's review of draft-ietf-bess-mvpn-expl-track

[Eric C Rosen]

I need to make a correction to my previous note.

From the draft:

The explicit tracking procedures do not allow an ingress node
to "see" past the boundaries of the segmentation domain.

This particular problem is not further addressed in this

revision of this document.

From my previous message in this thread.

[SLI] Do you plan to address it ? Or do we now consider it as out of 
scope ?


[ECR] I think this is actually addressed in Section 5.3, so I've removed 
the remark.


My response is mistaken, the draft does not address this issue.  I will 
change the text to say "This issue is not addressed by this draft".


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

Re: [bess] Shepherd's review of draft-ietf-bess-mvpn-expl-track

[Eric C Rosen]

Thanks for your review.  I have posted revision -04 which I believe 
addresses your substantive comments.


On 1/3/2018 8:01 AM, stephane.litkow...@orange.com wrote:


Hi,

As shepherd of this document, please find below some comments that I have:

Overall comments:

-Please add a section that contains all the abbreviations expansions: 
that may help non expert people to follow the acronyms without looking 
for the first reference in the text.




This is not generally required of an RFC.

-I usually like figures. For the intro, it may be wonderful to build a 
figure that reminds the existing S-PMSI/Leaf A-D procedure. So without 
reading the text, we can remember how it works.


-The interAS case may also be better with a Figure and an example (or 
couples of).




This seems like a matter of taste.  Admitedly, I'd probably like figures 
more if I had any skill in producing them ;-)



Introduction:

“By originating one of these BGP routes, an ingress node advertises that

   it is transmitting a particular multicast flow.”

[SLI] Is “is transmitting” correct ? Can’t we have situations where an 
S-PMSI route is/was advertised but no traffic is flowing (no yet 
started or switched, or stopped).




Fixed.


“Now
   suppose that the ingress node wants explicit tracking for each
   individual flow that it transmits (following the procedures of
   [RFC6625] on that P-tunnel.”
[SLI] Missing “)”


Fixed.


“This allows the
   ingress node to determine the set of egress nodes that are receiving
   flows from the ingress node.”
[SLI] I think the Leaf A-D tells that there is a receiver interested 
by the flow, but does not tell that it actually receives it.


Correct; fixed.


“   Howver, this procedure requires several clarifications:”
[SLI] There is a typo s/Howver/However/


Fixed.


“The procedures of [RFC6625] do not clearly state how to handle an
  S-PMSI A-D route if its NLRI contains wild cards, but its PTA
  specifies "no tunnel info".”
[SLI] I quickly ran over RFC6625, it does not mention anything on 
explicit tracking or Leaf A-D routes.So we assume that RFC6513/6514 
only applies here.


RFC 6625 specifies the handling of wildcard S-PMSI A-D routes, but did 
not consider the case where the S-PMSI A-D routes do not carry a PTA.  
This document corrects that.



“   *  The explicit tracking procedures do not allow an ingress node
 to "see" past the boundaries of the segmentation domain.
 This particular problem is not further addressed in this
 revision of this document.
“
[SLI] Do you plan to address it ? Or do we now consider it as out of 
scope ?


I think this is actually addressed in Section 5.3, so I've removed the 
remark.



Section 2:
“Prior specifications define one flag in the PTA, the "Leaf Info
   Required" (LIR) flag, that is used for explicit tracking.”
[SLI] Please point to the right reference


Fixed.


“If the LIR-pF flag is set in a given PTA, the LIR flag of that PTA
   SHOULD also be set.”
[SLI] Why not using a MUST ?


If all the PEs support the LIR-pF flag, the procedures will work as 
intended even if the LIR flag is not set.  So I don't think a MUST is 
appropriate.



“one forces a
   a response to be sent an egress node that does not support LIR-pF”
[SLI] Is there a missing word like ‘sent by an egress node” ?


Fixed.


Section 3:

“The definition of "match for reception" in [RFC6625] is hereby
   modified as follows:”
[SLI] Please point to the section that you are updating.
In addition, section 3.2 of RFC6625 contains multiple if then else 
conditions for each cases (C-S,C-G) and (C-*,C-G). Please give some 
precision in where do you want to insert your new statement in this 
processing sequence. I guess it is at the beginning.


I tried to make this clearer.


“When finding the "match for reception" for a given (C-S,C-G) or
  (C-*,C-G), ignore any S-PMSI A-D route that has no PTA, or whose
  PTA specifying "no tunnel information".”

[SLI] I would be in favor to introduce a normative statement here.



Fixed.


“We also introduce a new notion: the "match for tracking".  This
   differs from the "match for reception" as follows:”
[SLI] It would be better to give a definition of the “match for 
tracking” before giving the rules. Here you’re explaining only the 
rules, not the difference in the meaning. Wouldn’t it be easier to 
tell that the implementation MUST consider only the S-PMSI A-D routes 
that have a LIR flag and/or LR-pF flag set and then run the same rules 
as the RFC6625. Why do you want to have S-PMSI routes with PTA and LIR 
unset in your route list for “match for tracking” ? You need to take 
care here on your text proposal as one of your previous statement 
updates the RFC6625 and the match reception procedure, so the rules to 
be applied are the original one from RFC6625 and not the updated one.


IMO, the clearest way to express this is to give the rules and then 
illustrate with a couple of examples.



“   Also note th

Re: [bess] Comments on draft-dawra-idr-srv6-vpn-03

[Eric C Rosen]

On 12/28/2017 1:55 PM, Robert Raszuk wrote:

Ok let's start all over :)


From the draft:

The SRv6 VPN SID MAY be routable within the AS of the egress-PE and
  serves the dual purpose of providing reachability between ingress-PE
  and egress-PE while also encoding the VPN identifier.

I took this to mean that  a single IPv6 address could cause the backbone 
to forward the packet to the egress-PE and cause the egress-PE to look 
up the payload's IP address in a VRF which is identified by that same 
IPv6 address.  Did I misunderstand that?



 This suggests that an IPv6 address has to be assigned to each
VRF (for
 per-VRF "labeling"), or even to each CE (for per-CE labeling).


​No one suggests that. VPN SID is not IPv6 address .. it is part of v6 
SID which when appended to IPv6 prefix forms a complete SRv6 SID. 
Semantics does matter here. ​


Given the above quote from the draft, I'm not sure what is wrong with 
what I said.




 If those addresses are routable, doesn't this create a
security issue
 as discussed in RFC 4023 Section 8.2?


​PE's loopback address say /64 being routable causes any security risk ? ​


Please see the reference.



 The phrase "only has local significance" suggests that these
SIDs are
 not routable. But later on there is a suggestion that they are
 routable, or at least that they might be.


​Again SIDs are not routable and they have only local significance - 
true. ​They are prepended to say loopback address to form IPv6 SID.


 So there are a number of options:
 - not routable
 - globally routable
 - routable only within egress AS


​This is referring to routability of SID ... not right. SID does not 
need to be routable. What prefix they are part of may be routable. ​​


Just replace my use of the term "SID" with the longer term "the IPv6 
address of which the SID is a part".




   and the BGP ingress device receiving this route
   MAY choose to encapsulate or insert an SRv6 SRH, second it
indicates
   the value of the SID to include in the SRH encapsulation.  For
L3VPN,
   only a single SRv6-VPN SID MAY be necessary.

 I don't understand the phrase "only a single SRv6-VPN SID MAY be
 necessary".


​Analogy to basic L3VPN when you have VPN label and underlay LDP label. ​


Still don't understand what is being said.




   If the BGP speaker supports MPLS based
   L3VPN simultaneously, it MAY also populate the Label values in
L3VPN
   route types and allow the BGP ingress device to decide which
   encapsulation to use.  If the BGP speaker does not support MPLS
based
   L3VPN services the MPLS Labels in L3VPN route types MUST be set to
   IMPLICIT-NULL.

 Please provide a reference that specifies how you set the
Label field
 of a SAFI-4 or SAFI-128 route to "implicit null".  I don't
recall any
 such thing existing in RFC 3107, 4364, or 8277.



​4364 does not restrict what value of VPN label is used - does it ? I 
think this draft now right here defines ​how to read implicit-null 
being placed there :) It's not my idea though - so I will let real 
inventors to comment on it more.


 If you mean "set to three" (the value defined in RFC 3032 to
represent
 "implicit null"), I don't think the SAFI-4/SAFI-128
implementations
 generally interpret the value three in that manner.


​As mentioned I think it just is being defined here and now. ​


I didn't see any mention of the numeric value to put in the label field 
of the NLRI.


or to define a new special or reserved label ​for that embedded 
signalling.


Some discussion of why this won't cause any backwards compatibility 
problems would be appropriate.






 I'm not really sure what you're trying to do here. There are
at least
 four cases to consider:

 1. For the case where the backbone doesn't have MPLS, there
is no harm
 in saying "set the label to zero".


​Really ? ​What does the backbone having or not having MPLS has to do 
with this ? Underlay forwarding does not matter and this is what I 
read as "backbone".


What I meant is that if it is known a priori that SRv6 is being used 
instead of MPLS, the label value obviously doesn't matter, because it 
will never be used.




 2. For the case where the backbone supports both MPLS and
SRv6, and
 some PEs support L3VPN both ways, while others support only
MPLS-based
 L3VPN, then a real label needs to be put in.


​OK.​

 3. For the case where the backbone supports both MPLS and
SRv6, but a
 particular egress PE only supports SRv6, there needs to be
some way to
 instruct the ingress PEs to use SRv6 and not MPLS. Perhaps the
 presence of the prefix-SID attribute with VPN-SID TLV is
sufficient.


​Perhaps not ... and this is exactl

Re: [bess] Comments on draft-dawra-idr-srv6-vpn-03

[Eric C Rosen]

On 12/28/2017 12:14 PM, Robert Raszuk wrote:

Hi Eric,

A lot of your comments are an indication that you treat SID to be IPv6 
address fully responsible for demux to proper VRF or CE. This was 
never the intention.


Imagine egress PE having /64 loopback. Then you have remaining 64 bits 
to put there a 20 bit VPN label (as we know it :) and even much more 
then that. You can attach new arbitrary new functions to this single 
"VPN SID".


And further notice that this has no bearing on SID being routable or 
not. Only the first /64 bits of the dst address need to be routable in 
order for forwarding packets to happen ... So by no means there should 
be a case to have per vrf IPv6 address or per CE IPv6 address and make 
it fully /128 routable.


I'm not sure what you mean by "fully /128 routable".  If there is a 
route for a /64 prefix, then a /128 that begins with that prefix is 
routable.


I'm not sure what you mean by saying it is "not the intention for the 
IPv6 address to be fully responsible for demux to proper VRF or CE".  If 
the IPv6 adress contains the "VPN label" in its low-order part, then the 
IPv6 address is used for the demux.  The VPN label is part of the IPv6 
address, no?


I'm not sure which comments you consider to be invalid.



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

[bess] Comments on draft-dawra-idr-srv6-vpn-03

[Eric C Rosen]

Following are a few comments (look for lines beginning ) on 
draft-dawra-idr-srv6-vpn-03.  The name of the draft notwithstanding, I 
think this is clearly a draft that falls within the scope of BESS, so 
I've sent my comments to the BESS list. (Also copying the 12 "authors" ;-))


Section 1

...

   To provide SRv6-VPN service with best-effort connectivity, the egress
   PE signals an SRv6-VPN SID with the VPN route.  The ingress PE
   encapsulates the VPN packet in an outer IPv6 header where the
   destination address is the SRv6-VPN SID provided by the egress PE.
   The underlay between the PE's only need to support plain IPv6
   forwarding [RFC2460].

 This suggests that an IPv6 address has to be assigned to each VRF (for
 per-VRF "labeling"), or even to each CE (for per-CE labeling).
 Presumably these would be taken from an IPv6 prefix owned by the
 advertising PE?  Or not?

 If those addresses are routable, doesn't this create a security issue
 as discussed in RFC 4023 Section 8.2?

Section 3

...

   For egress-PEs which supports SRv6-VPN advertises an SRv6-VPN SID
   with VPN routes.  This SRv6-VPN SID only has local significance at
   the egress-PE where it is allocated or configured on a per-CE or per-
   VRF basis.

 The phrase "only has local significance" suggests that these SIDs are
 not routable. But later on there is a suggestion that they are
 routable, or at least that they might be.

...

   In practice, the SID encodes a cross-connect to a
   specific Address Family table (END.DT) or next-hop/interface (END.DX)
   as defined in the SRv6 Network Programming Document
   [I-D.filsfils-spring-srv6-network-programming]

 I'm not sure what is meant by "in practice".  Aren't these semantics
 NECESSSARY in order to provide the L3VPN service?

   The SRv6 VPN SID MAY be routable within the AS of the egress-PE and
   serves the dual purpose of providing reachability between ingress-PE
   and egress-PE while also encoding the VPN identifier.

 Did you mean:

   The SRv6 VPN SID MAY be routable all along the path from the ingress-PE
   to the egress-PE, and if so, MAY serve the dual purpose of providing
   reachability between ingress-PE and egress-PE while also encoding 
the VPN

   identifier.

 Though I guess if the SID is routable only in the egress AS, one could
 tunnel to an entry point of that AS and then route within the AS based
 on the SID.  (Of course this amplifies the spoofing problem discussed
 in Section 8.2 of RFC 4023.)

 So there are a number of options:
 - not routable
 - globally routable
 - routable only within egress AS

 If the intention is to allow all those options, please explain the
 signaling that lets the ingress PE know which option to use.  Or is the
 intention that this is known a priori (i.e., via provisioning)?

   To support SRv6 based L3VPN overlay, a SID is advertised with BGP
   MPLS L3VPN route update[RFC4364].  SID is encoded in a SRv6-VPN SID
   TLV, which is optional transitive BGP Prefix SID
   attribute[I-D.ietf-idr-bgp-prefix-sid].  This attribute serves two
   purposes; first it indicates that the BGP egress device is reachable
   via an SRv6 underlay

 Whether the egress PE is reachable via an SRv6 underlay has nothing to
 do with the presence or absence of the SRv6-VPN SID TLV.  The presence
 of that TLV really only means that the egress PE can handle the SRv6
 encapsulation for L3VPN.

   and the BGP ingress device receiving this route
   MAY choose to encapsulate or insert an SRv6 SRH, second it indicates
   the value of the SID to include in the SRH encapsulation.  For L3VPN,
   only a single SRv6-VPN SID MAY be necessary.

 I don't understand the phrase "only a single SRv6-VPN SID MAY be
 necessary".

   A BGP speaker supporting an SRv6 underlay MAY distribute SID per route
   via the BGP SRv6-VPN Attribute.

 I think you mean "If a PE supports an SRv6 underlay, it may attach the
 BGP SRv6-VPN attribute to the VPN-IP routes that it originates".

   If the BGP speaker supports MPLS based
   L3VPN simultaneously, it MAY also populate the Label values in L3VPN
   route types and allow the BGP ingress device to decide which
   encapsulation to use.  If the BGP speaker does not support MPLS based
   L3VPN services the MPLS Labels in L3VPN route types MUST be set to
   IMPLICIT-NULL.

 Please provide a reference that specifies how you set the Label field
 of a SAFI-4 or SAFI-128 route to "implicit null".  I don't recall any
 such thing existing in RFC 3107, 4364, or 8277.

 If you mean "set to zero", I think that will generally be interpreted
 in a SAFI-4 or SAFI-128 route as "push on label 0 (explicit null)".

 If you mean "set to three" (the value defined in RFC 3032 to represent
 "implicit null"), I don't think the SAFI-4/SAFI-128 implementations
 generally interpret the value three in that man

Re: [bess] Call for adoption: draft-drake-bess-datacenter-gateway

[Eric C Rosen]

I am unaware of any undisclosed IPR that applies to this draft.


On 9/25/2017 5:42 AM, Martin Vigoureux wrote:

Hello working group,

This email starts a two-week call for adoption on 
draft-drake-bess-datacenter-gateway-05 [1] as a BESS Working Group 
Document.


Please state on the list if you support the adoption or not (in both 
cases, please also state the reasons).


This poll runs until *the 2nd of October*.

We are also polling for knowledge of any undisclosed IPR that applies
to this Document, to ensure that IPR has been disclosed in compliance
with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more
details).
If you are listed as an Author or a Contributor of this Document please
respond to this email and indicate whether or not you are aware of any
relevant undisclosed IPR. The Document won't progress without answers
from all the Authors and Contributors.

Currently no IPR has been disclosed against this Document.

If you are not listed as an Author or a Contributor, then please 
explicitly respond only if you are aware of any IPR that has not yet 
been disclosed in conformance with IETF rules.


Thank you

Martin & Thomas
bess chairs

[1] 
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Ddrake-2Dbess-2Ddatacenter-2Dgateway_&d=DwIC-g&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=PH0tABqMXcA-TgEvraUZC2HrDAmgmPxVx36tE1gUWSw&s=GSHLcpm8n5C1KatiovmQUcLTxxzJS2YOrLtZMCuFrLY&e= 



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

Re: [bess] WG Last Call for draft-ietf-bess-mvpn-expl-track

[Eric C Rosen]

I am not aware of any relevant IPR.



On 7/10/2017 11:23 AM, Thomas Morin wrote:

Hello Working Group,

This email starts a Working Group Last Call on 
draft-ietf-bess-mvpn-expl-track-02 [1] which is considered mature and 
ready for a final working group review.


Please read this document if you haven't read the most recent version 
yet, and send your comments to the list, no later than *24th of July*.
Note that this is *not only* a call for comments on the document; it 
is also a call for support (or not) to publish this document as a 
Standard Track RFC.


*Coincidentally*, we are also polling for knowledge of any IPR that 
applies to draft-ietf-bess-mvpn-expl-track, to ensure that IPR has 
been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 
3669 and 5378 for more details).


If you are listed as a document Author or Contributor of the draft 
please respond to this email and indicate whether or not you are aware 
of any relevant IPR, additionally to what was already disclosed ([2]).


We are **also polling for knowledge of implementations** of part or 
all of what this document specifies. This information is expected as 
per [2].

Please inform the mailing list, or the chairs, or only one of the chairs.

Thank you,
T&M

[1] https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-expl-track
[2] 
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-bess-mvpn-expl-track
[3] 
https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw




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

Re: [bess] [pim] WGLC: draft-ietf-bier-mvpn-05

[Eric C Rosen]

On 6/21/2017 4:15 PM, Swadesh Agrawal (swaagraw) wrote:

I think it’s pretty standard to send ipv6 traffic with ipv6 explicit NULL.


I wouldn't make that assumption.  Especially not in MPLS backbones built 
on an IPv6 infrastructure.



It was never required to be explicitly mention in RFC.


The fact that this was never made explicit in any RFC has been the cause 
of numerous interoperability problems.  Many of these have been hammered 
down over the past twenty years, but new issues of this sort still 
arise, especially in new applications where label stacks are signaled in 
new and different ways.



We won’t need signaling. It will depend on ingress PE. If ingress PE does not 
send ipv6 explicit NULL, it should announce different upstream assigned label 
for afi.
Egress PE should work in both scenario without any signaling of what ingress PE 
has implemented.


I think it would be good for the egress PE to know in advance whether or 
not it is expected to infer the payload type from the upstream-assigned 
label (assuming that that label appears at the bottom of the stack).



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

Re: [bess] [Bier] [pim] WGLC: draft-ietf-bier-mvpn-05

[Eric C Rosen]

On reflection, I think it's best if there is no requirement for a PE's 
BFR-Prefix to appear in the NLRI of any of the MVPN routes, no 
requirement for it to appear in the VRF Route Import EC, no requirement 
for it to appear in any next hop field, no requirement for it to appear 
in the Inter-Area P2MP Next Hop EC, etc.  That is, no requirement for it 
to be anything other than a BFR-Prefix.


So if the PTA of an x-PMSI A-D route specifies tunnel type "BIER", I 
think the simplest thing is to require that the BFR-Prefix be specified 
in the PTA.


Similarly, the simplest way to ensure that the ingress PE knows the 
BFR-Prefix of an egress PE is to have the egress PE include a PTA in the 
Leaf A-D route, and require to PTA to specify "tunnel type" BIER, MPLS 
Label 0 (ignored), and the BFR-Prefix of the Leaf.  Which I think was 
Stig's original suggestion.



On 6/21/2017 1:08 PM, Mahesh Sivakumar (masivaku) wrote:

Hi Eric,


For BIER, I was thinking that the BFR-Prefix of the egress PE should
appear in the "originating router's IP address" field of the Leaf A-D
NLRI.  However, it is probably better to allow the "originating router's
IP address" to be different than the BFR-Prefix, and in that case to use
the Leaf A-D route's PTA to specify the BFR-Prefix.

I was thinking along the same lines so that we have the flexibility on the
Ingress BFR to use either the originating router or the BFR prefix while
tracking.
But do you envision a real use case at the ingress BFIR for using the BFR prefix
in the PTA given that the BFIR can use the originating router IP address to
match the appropriate S-PMSI A-D route.
Accordingly, should we make the BIER-pfx in the PTA optional?

Thanks
Mahesh





On 6/21/17, 8:39 AM, "BIER on behalf of Eric C Rosen"  wrote:


Stig, thanks for your comments.+

On 6/19/2017 5:47 PM, Stig Venaas wrote:

Hi

I think this draft is mostly ready. I just have a couple of comments.

In section 1:
 This revision of the document does not specify the procedures
 necessary to support MVPN customers that are using BIDIR-PIM.  Those
 procedures will be added in a future revision.

Remove this text?

We'll probably just change this to something like "Procedures to support
MVPN customers that are using BIDIR-PIM are outside the scope of this
document".


Section 2.1.  MPLS Label

Should one use different labels to distinguish address families in the same VRF?

Nice catch.  The customer's address family is identified by the AFI of
the MCAST-VPN routes.  There should be a requirement that a given router
MUST NOT originate two x-PMSI A-D routes with different AFIs but with
the same upstream-assigned label in their respective PTAs.


The PTA must be present in Leaf A-D routes so one can know the BIER
prefix of the router joining. It might be obvious, but I think it is
worth pointing it out. It is specified for IR (in RFC 7988 section
4.1.1 it says: "Leaf A-D route MUST also contain a PTA"...

For IR, the PTA is needed because each egress PE needs to advertise a
downstream-assigned label.

For BIER, I was thinking that the BFR-Prefix of the egress PE should
appear in the "originating router's IP address" field of the Leaf A-D
NLRI.  However, it is probably better to allow the "originating router's
IP address" to be different than the BFR-Prefix, and in that case to use
the Leaf A-D route's PTA to specify the BFR-Prefix.




___
BIER mailing list
b...@ietf.org
https://www.ietf.org/mailman/listinfo/bier


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

Re: [bess] [pim] WGLC: draft-ietf-bier-mvpn-05

[Eric C Rosen]

On 6/21/2017 2:22 PM, Swadesh Agrawal (swaagraw) wrote:

It can be achieved by having ipv6 explicit NULL in data path. We may not need 
different label to identify AFI.


We could have a rule saying that if MVPN payload packet is an IPv6 
packet, then v6 explicit null must be pushed before the 
upstream-assigned label is pushed.


But hen someone would claim that we're favoring v4 over v6, and the rule 
should be that if the MVPN payload is a v4 packet, v4 explicit null must 
be pushed before the upstream-assigned label is pushed.


If we don't have one rule or the other, we risk multi-vendor interop 
problems.


People will disagree about which rule is best, so someone will claim 
that we need a configuration item to say which payload type is the 
default and which requires explicit null.


Then someone would say that we need to add to the signaling an 
indication of which payload type is the default and which requires 
explicit null.


Then someone would say that the root cause of the problem is the lack of 
a protocol type field in MPLS, and we should fix the root cause instead 
of using explicit null.


So although your observation is absolutely correct, I think it's simpler 
if we just use different upstream-assigned labels for the different AFIs.




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

Re: [bess] [pim] WGLC: draft-ietf-bier-mvpn-05

[Eric C Rosen]

Stig, thanks for your comments.+

On 6/19/2017 5:47 PM, Stig Venaas wrote:

Hi

I think this draft is mostly ready. I just have a couple of comments.

In section 1:
This revision of the document does not specify the procedures
necessary to support MVPN customers that are using BIDIR-PIM.  Those
procedures will be added in a future revision.

Remove this text?


We'll probably just change this to something like "Procedures to support 
MVPN customers that are using BIDIR-PIM are outside the scope of this 
document".



Section 2.1.  MPLS Label

Should one use different labels to distinguish address families in the same VRF?


Nice catch.  The customer's address family is identified by the AFI of 
the MCAST-VPN routes.  There should be a requirement that a given router 
MUST NOT originate two x-PMSI A-D routes with different AFIs but with 
the same upstream-assigned label in their respective PTAs.



The PTA must be present in Leaf A-D routes so one can know the BIER
prefix of the router joining. It might be obvious, but I think it is
worth pointing it out. It is specified for IR (in RFC 7988 section
4.1.1 it says: "Leaf A-D route MUST also contain a PTA"...


For IR, the PTA is needed because each egress PE needs to advertise a 
downstream-assigned label.


For BIER, I was thinking that the BFR-Prefix of the egress PE should 
appear in the "originating router's IP address" field of the Leaf A-D 
NLRI.  However, it is probably better to allow the "originating router's 
IP address" to be different than the BFR-Prefix, and in that case to use 
the Leaf A-D route's PTA to specify the BFR-Prefix.



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

Re: [bess] Call for adoption: draft-rabadan-bess-evpn-pref-df

[Eric C Rosen]

Support, even though I'm not a co-author.

Provides a solution to a real problem.


On 6/6/2017 9:44 AM, thomas.mo...@orange.com wrote:

Hello working group,

This email starts a two-week call for adoption on
draft-rabadan-bess-evpn-pref-df-02 [1] as a Working Group Document.

Please state on the list if you support the adoption or not (in both 
cases, please also state the reasons).


This poll runs until *the 20th of June*.

We are also polling for knowledge of any undisclosed IPR that applies 
to this Document, to ensure that IPR has been disclosed in compliance 
with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more 
details).


If you are listed as an Author or Contributor of this Document please 
respond to this email and indicate whether or not you are aware of any 
relevant undisclosed IPR. The Document won't progress without answers 
from all the Authors and Contributors.


If you are not listed as an Author or Contributor, then please 
explicitly respond only if you are aware of any IPR that has not yet 
been disclosed in conformance with IETF rules.


Thank you,

Martin & Thomas
bess chairs

[1] https://datatracker.ietf.org/doc/draft-rabadan-bess-evpn-pref-df/

_ 



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


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

Re: [bess] Closed -- Working Group Last Call on draft-ietf-mpls-rfc3107bis

[Eric C Rosen]

I have now posted draft-ietf-mpls-rfc3107bis-02.txt, which I believe 
addresses the LC comments.


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

[bess] 3107bis LC discussion on MPLS list

[Eric C Rosen]

 labels MUST be explicitly withdrawn.”

If I have understood this correctly, it requires a speaker to withdraw 
NLRI that it sent on the previous session but that it has not sent on 
the restarted session (because the negotiated session capabilities 
changed).


(a) Why does it need to do that – isn’t the NLRI implicitly withdrawn 
when the EOR marker is sent?




The theory here is that the label stack in the stale routes is known to 
be invalid, so you really don't want your peer to hold on to them until 
EOR is received.


(b) This seems to contradict section 2.4 which says “Note that 
label/prefix bindings that were not advertised on the given session 
cannot be withdrawn by this method.”




I added the following text to section 2.4 right after the quoted sentence:

 (However, if the bindings were advertised on a previous session
   with the same peer, and the current session is the result of a
   "graceful restart" ([RFC4724]) of the previous session, then this
   withdrawal method may be used.)



2) In section 2.1 it says:

“A BGP speaker SHOULD NOT send an UPDATE that binds more labels to a 
given prefix than its peer is capable of receiving” – why isn’t that 
MUST NOT?




Section 2.1 also requires the receiving speaker to apply 
"treat-as-withdraw" to such updates, which does imply that the sending 
speaker must not send them.  So I've changed "SHOULD NOT" to "MUST NOT".



3) In section 2.4 it says:

“To do so, it may send a BGP UPDATE message with an MP_UNREACH_NLRI 
attribute.”


Should that be “it MUST send”?



I think the non-normative (non-RFC2119) language is fine here.

4) In section 5: although some implementations treat SAFI 1 and SAFI 4 
routes as comparable, I believe that they should always be treated as 
independent, in the following sense:


Suppose a speaker S1 sends a SAFI 1 route and then a SAFI 4 route to 
the same prefix P.  The SAFI 4 route MUST NOT be treated by the 
receiving speaker as an implicit withdraw of the SAFI 1 route.  If S1 
subsequently sends an explicit withdraw of the SAFI 4 route, this MUST 
NOT implicitly withdraw the SAFI 1 route, and vice versa.


Am I correct?  I have seen implementations that violate this so I 
think it is worth spelling out somewhere in this section.




From Section 1:

   This document also addresses the issue of the how UPDATEs that bind
   labels to a given prefix interact with UPDATEs that advertise paths
   to that prefix but do not bind labels to it. However, for backwards
   compatibility, it declares most of these interactions to be matters
   of local policy.

Different deployed implementations have different behavior, and I think 
it is better to advance the document as is rather than derail it with 
the inevitable food fight that would occur if we wanted to try to get 
the IETF to say which implementation is better than which other 
implementation.  The deployed implementations have been around for many 
years, and people seem to have adapted to the differences.



5) In section 7 it says:

“ If a BGP implementation, not conformant with the current document,

encodes multiple labels in the NLRI but has not sent and received the

"Multiple Labels" Capability, a BGP implementation that does conform

with the current document will likely reset the BGP session.”

Wouldn’t that prevent incremental deployment of this RFC into a 
network that is initially composed of such implementations?  Because 
it seems to require that both ends of each BGP session must be 
upgraded simultaneously, or else the BGP sessions will all reset.




This issue was discussed at great length when the draft was first 
submitted.  The vast majority of deployments do not check the S bit.  
That is, the de facto standard is to assume that a received update has 
only one label.   If any existing deployment were transmitting updates 
with multiple labels encoded into the NLRI, it would already be causing 
BGP session resets.


(Even iff this were a real problem, it wouldn't require both ends of a 
session to be upgraded simultaneously.  It would just require one end to 
have a knob allowing it to accept both old and new behavior from its 
peer, and a knob telling it whether to use old or new behavior when 
sending to its peer.  But since the defacto standard doesn't use 
multiple labels, I don't think we have to worry much about this.)


--- End Message ---
--- Begin Message ---
Hi Eric

Thanks for the replies – please see [Jon] inline.

Cheers
Jon

From: Eric C Rosen [mailto:ero...@juniper.net]
Sent: 03 May 2017 19:23
To: Jonathan Hardwick ; 
draft-ietf-mpls-rfc3107...@ietf.org; mpls-cha...@ietf.org; m...@ietf.org
Cc: rtg-...@ietf.org
Subject: Re: Routing directorate review of draft-ietf-mpls-rfc3107-bis


Thanks for your review!

On 4/27/2017 9:03 AM, Jonathan Hardwick wrote:
I also spotted a few nits that should be fixed at some point before publication.

I have fixed the nits.



Comm

Re: [bess] WG Last Call for draft-ietf-bess-evpn-prefix-advertisement-04

[Eric C Rosen]

Thanks for the preliminary -05 revision.  It answers a lot of my questions.

However, now that I better understand the "overlay index" concept, I 
have gone a bit deeper into the details of your use cases, and have some 
comments on them in-line in the attached document.


Probably the biggest issue is that I'm not sure it is quite clear 
precisely how you tell whether an overlay index is present in an RT-5, 
or precisely how you determine which kind of overlay index is present.


Thanks for the preliminary -05 revision.  It answers a lot of my questions.

However, now that I better understand the "overlay index" concept, I have
gone a bit deeper into the details of your use cases, and have some comments
on them in-line in the attached document.

Probably the biggest issue is that I'm not sure it is quite clear precisely
how you tell whether an overlay index is present in an RT-5, or precisely
how you determine which kind of overlay index is present.







BESS Workgroup   J. Rabadan, Ed.
Internet Draft W. Henderickx
Intended status: Standards Track   Nokia

J. Drake
  W. Lin
 Juniper

  A. Sajassi
   Cisco


Expires: September 23, 2017   March 22, 2017



IP Prefix Advertisement in EVPN
  draft-ietf-bess-evpn-prefix-advertisement-05


Abstract

   EVPN provides a flexible control plane that allows intra-subnet
   connectivity in an IP/MPLS and/or an NVO-based network. In some
   networks, there is also a need for a dynamic and efficient inter-
   subnet connectivity across Tenant Systems and End Devices that can be
   physical or virtual and do not necessarily participate in dynamic
   routing protocols. This document defines a new EVPN route type for
   the advertisement of IP Prefixes and explains some use-case examples
   where this new route-type is used.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt
 


Rabadan et al. Expires September 23, 2017   [Page 1]

Internet-Draft EVPN Prefix Advertisement  March 22, 2017


   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on September 22, 2017.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2. Introduction and problem statement  . . . . . . . . . . . . . .  3
 2.1 Inter-subnet connectivity requirements in Data Centers . . .  4
 2.2 The requirement for a new EVPN route type  . . . . . . . . .  6
   3. The BGP EVPN IP Prefix route  . . . . . . . . . . . . . . . . .  7
 3.1 IP Prefix Route encoding . . . . . . . . . . . . . . . . . .  8
 3.2 Overlay Indexes and Recursive Lookup Resolution  . . . . . . 10
   4. IP Prefix Overlay Index use-cases . . . . . . . . . . . . . . . 11
 4.1 TS IP address Overlay Index use-case . . . . . . . . . . . . 11
 4.2 Floating IP Overlay Index use-case . . . . . . . . . . . . . 14
 4.3 Bump-in-the-wire use-case  . . . . . . . . . . . . . . . . . 16
 4.4 IP-VRF-to-IP-VRF model . . . . . . . . . . . . . . . . . . . 18
   4.4.1 Interface-less IP-VRF-to-IP-VRF model  . . . . . . . . . 19
   4.4.2 Interfac

Re: [bess] Call for adoption: draft-mackie-bess-nsh-bgp-control-plane

[Eric C Rosen]

Support.

I am not aware of any undisclosed IPR that applies to this document.


On 3/6/2017 6:55 AM, Martin Vigoureux wrote:

Hello working group,

This email starts a two-week call for adoption on 
draft-mackie-bess-nsh-bgp-control-plane-04 [1] as a Working Group 
Document.


Please state on the list if you support the adoption or not (in both 
cases, please also state the reasons).


This poll runs until *the 19th of March*.

We are also polling for knowledge of any undisclosed IPR that applies
to this Document, to ensure that IPR has been disclosed in compliance
with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more
details).
If you are listed as an Author or Contributor of this Document please
respond to this email and indicate whether or not you are aware of any
relevant undisclosed IPR. The Document won't progress without answers
from all the Authors and Contributors.

IPR has been disclosed against this Document [2].

If you are not listed as an Author or Contributor, then please 
explicitly respond only if you are aware of any IPR that has not yet 
been disclosed in conformance with IETF rules.


Thank you

Martin & Thomas
bess chairs

[1] 
https://datatracker.ietf.org/doc/draft-mackie-bess-nsh-bgp-control-plane/
[2] 
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-mackie-bess-nsh-bgp-control-plane


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

Re: [bess] WG Last Call for draft-ietf-bess-evpn-prefix-advertisement-04

[Eric C Rosen]

While I would like to see this document advance eventually, I don't 
think it is ready yet.


Main points:

- There is no clear explanation of the key concept of "overlay index".  
In particular, there is no real explanation of when to use an overlay 
index, or of when to use each kind of overlay index. There are some use 
case descriptions, and some examples of the sort "in this use case use 
this kind of overlay index", but no rules that specify the precise 
circumstances under which it is appropriate to use each kind of overlay 
index.


- There are no rules given that say how an NVE knows whether to 
originate an RT-5 route, or knows how to construct an RT-5 route.  A 
number of use cases are walked through, which is helpful, but that is 
not a substitute for a real specification.


- In the discussion of use case, there are statements like "support of 
this use case is REQUIRED".  But it is very difficult to know exactly 
which features of the protocol are being mandated.


- Too much of the draft is the "RT-5's are good" sale pitch, which is 
repeated three times.  (Sections 2.2, 4, and 6.)  A single time would do.


- The talk of IP-VRFs is a bit misleading, as this might be taken to 
suggest that the document provides a way to interoperate L3VPN with EVPN.


I've attached the draft with some more comments in-line, look for lines 
beginning with .




BESS Workgroup   J. Rabadan, Ed.
Internet Draft W. Henderickx
Intended status: Standards Track   Nokia

J. Drake
  W. Lin
 Juniper

  A. Sajassi
   Cisco


Expires: August 17, 2017   February 13, 2017



IP Prefix Advertisement in EVPN
  draft-ietf-bess-evpn-prefix-advertisement-04


Abstract

   EVPN provides a flexible control plane that allows intra-subnet
   connectivity in an IP/MPLS and/or an NVO-based network. In NVO
   networks, there is also a need for a dynamic and efficient inter-
   subnet connectivity across Tenant Systems and End Devices that can be
   physical or virtual and may not support their own routing protocols.

 Perhaps: "may not support their own" -->  "do not necessarily
 participate in dynamic"

   This document defines a new EVPN route type for the advertisement of
   IP Prefixes and explains some use-case examples where this new route-
   type is used.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt
 


Rabadan et al.  Expires August 17, 2017 [Page 1]

Internet-Draft EVPN Prefix Advertisement   February 13, 2017


   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on August 17, 2017.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2. Introduction and problem statement  . . . . . . . . . . . . . .  3
 2.1 Inter-subnet connectivity requirements in Data Centers . . .  4
 2.2 The requirement for a new EVPN route type  . . . . . . . . .  6
   3. The BGP EVPN IP Prefix route  . . . . . . . . . . . . . . . . .  8
 3.1 IP Prefix Route encoding . . . . . . . . . . . . . . . . . .  8
   4. Benefits of using the EVPN IP Prefi

Re: [bess] WG Last Call for draft-ietf-bess-evpn-inter-subnet-forwarding-03

[Eric C Rosen]

I have a number of comments on this draft.  I've attached a copy of the 
draft with comments in-line; look for lines beginning with "".


I don't think the document is ready to advance at the present time.

Issues:

- Most of this document is a discussion of various Data Center use 
cases, with an informal discussion of how EVPN procedures could be used 
to get IP datagrams into or out of a DC.  A little bit of the document 
is the specification of EVPN protocols and procedures that is specific 
to inter-subnet-forwarding.  However, these two parts are not clearly 
separated.  This makes it very hard to know which parts of the document 
are normative (i.e., suitable for Proposed Standard status) and which 
are just use case descriptions (as one might find in an Informational 
document).  This really needs to be fixed; I don't see how one would 
expect interoperable implementations to result from this document.


- These seems to be an architectual model hidden here, in which 'IRB 
interfaces' connect IP-VRFs to Bridge Tables (or something). However, 
there doesn't seem to be a clear description of this model.


- The use cases discussed in section 4 (Asymmetric Forwarding) are 
different than the use cases in section 5 (Symmetric Forwarding). 
However, I don't think there is an implication that certain use cases 
require asymmetric forward and certain require symmetric forwarding.  
I'm really confused about how to interpret sections 4 and 5.


- It is not always clear whether the discussion of use cases is or is 
not intended to be normative.


- The sections discussing the use cases contain a lot of text that is 
repeated verbatim (or almost verbatim) from other sections. This makes 
almost impossible to see what is done differently for the different use 
cases.  I think this repeated text needs to be refactored or removed.


- The discussion of routing packets between an "EVPN domain" (my term) 
and the "outside world" (Internet, IPVPN, other EVPN domain) does not 
provide much information on how one actually makes that happen 
correctly.  (The only thing that is really covered is routing between 
two subnets of the same tenant; everything else seems like just a 
placeholder for sections that were never actually written).


- Much of the terminology is not precisely defined, and normative 
references are not given to documents where the terminology is defined.


- No attempt is made to use a consistent set of terms.  This often 
leaves on wondering: "it says 'Broadcast Domain' here, it says 'subnet' 
there, it says 'MAC-VRF' in the other place, are these terms being used 
interchangeably, or is there some difference that needs to be attended 
to?".


- In a number of places, there seems to be a presupposition that an EVI 
contains one Broadcast Domain.  This is not true for all the variants of 
EVPN service.


In order for this document to advance, I think it needs the following:

- Decide whether it is a protocol spec or an applicability guide. If 
both, separate the normative from the descriptive part in a clear way.


- Clarify the architectural model.

- Eliminate the large sections of repeated text.

- Tighten up the terminology.

- Eliminate the sections that don't really say anything (e.g., the 
sections on routing between an IPVPN and an EVPN, the section on 
mobility).  Alternatively, provide content.


Having said all that, I would like to see this document go forward, but 
I don't think it is ready.


More comments in the attachment.




  

  

  
  


L2VPN Workgroup  A. Sajassi, Ed.
INTERNET-DRAFT  S. Salam
Intended Status: Standards Track   S. Thoria
   Cisco
J. Drake
 Juniper
  J. Rabadan
   Nokia
 L. Yong
  Huawei

Expires: August 8, 2017 February 8, 2017


Integrated Routing and Bridging in EVPN 
draft-ietf-bess-evpn-inter-subnet-forwarding-03 


Abstract

   EVPN provides an extensible and flexible multi-homing VPN solution
   for intra-subnet connectivity among hosts/VMs over an MPLS/IP
   network. However, there are scenarios in which inter-subnet
   forwarding among hosts/VMs across different IP subnets is required,
   while maintaining the multi-homing capabilities of EVPN. This
   document describes an Integrated Routing and Bridging (IRB) solution
   based on EVPN to address such requirements. 

Re: [bess] FW: New Version Notification for draft-mackie-bess-nsh-bgp-control-plane-01.txt

[Eric C Rosen]

On 11/2/2016 4:50 PM, Joel M. Halpern wrote:

I would observe that what we are discussing is really SFC definition.


That's what you're discussing ;-), but we're just trying to devise a way 
that a node can figure out where the next node in the service chain for 
a particular packet is, how to get the packet there, and how to set up 
the forwarding tables to achieve that.




The draft is really concerned only with the fact that the SFF passes a
packet to a "local" service function, and ultimately gets the packet
back with an NSH that contains an SPI/SI.  The question is -- what are
the possible SPI/SI values that the packet may have when the SFF gets it
back?  In order to do "fast path" forwarding, the SFF needs to create
forwarding state for this set of SPI/SI's.  If arbitrary
reclassification is possible, then any value of SPI/SI may be seen when
the packet comes back, and forwarding state needs to be created for
every valid SPI/SI value.  It's good to have some indication in advance
about which SPI/SI values one is likely to see when the packet returns;
this allows one to maintain only the set of forwarding states that one
is likely to see.  That's what the markers are for.  Of course, this is
just an optimization meant to improve performance and scaling.


Mostly, I think this is backwards.  The only valid values for SPI/SI 
that can be given back to the SFF by the SF are those for which the 
SFF has forwarding state.  Any other values will result in the packet 
being dropped.the SFF does not create this forwarding state from 
whole cloth.  It creates this state from the information provided by 
the control mechanism (BGP, ForCES, NetConf, XMPP, ...)  The SFF does 
not care what the SF will hand it.  Rather, it cares what it is 
supposed to forward, and to where. 




I don't see any difference between what you stated and what I stated.  
However you say it, the SFF has to have forwarding state for whatever 
SPI/SI values it might see in an NSH, and does not have to have 
forwarding state for values that it will not see.


Even when arbitrary reclassification is possible, control mechanisms 
need to be coordinated such that the markings the classifier wants to 
produce correspond to forwarding state the SFF has.


Of course, that's what I said.

You seem to be trying hard to disagree with something, but I really 
don't understand the content of the disagreement.


I am saying that the set of markers in the BGP draft seem to cover 
cases they don't need to cover, and not cover cases that they need to 
cover in order to handle all of the provisioning of the SFF.


I think we are having trouble following your argument here.  Do you have 
an example of how the mechanisms in the draft will produce incorrect 
forwarding state?



The NSH draft only requires that the packet be dropped if its SPI/SI do
not "correspond" to a "valid" next hop.   Note that the quoted terms do
not appear to be defined.  This leaves a lot of leeway for 
interpretation.


Eric, on this you are stretching.  If you really want us to add more 
specific wording, we can.  But as a participant it has seemed to me 
that the WG has understood these quite well, and that they are 
actually quite clear and reasonable words. 


The use of undefined terms like this usually hides disagreements and 
differing interpretations.



If you want them clarified, we can do that.  In contrast to your 
paragraph below, the WG has been clear that if an SFF has state for 
SPI X, SI Y, that does not mean that the SFF has state for any other 
SI value.  While we allow for SFF that also look at other things (for 
example load balancing), the SPI/SI match is exact. 




Perhaps the WG did not think of the advantages of allowing a more 
flexible scheme.  Or to put it another way, allowing more flexibility 
here doesn't really seem to damage the architecture in any way.  If we 
are wrong about that, perhaps someone will explain what goes wrong if 
one interprets "SI=n" to mean "whatever SI is closest to n without being 
greater than n".






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

Re: [bess] FW: New Version Notification for draft-mackie-bess-nsh-bgp-control-plane-01.txt

[Eric C Rosen]

[Joel] If they are disjoint, it is not really separate overlays at all.  
The RT allows you to reduce stored state, but they are really all part 
of the same overlay (as they have to coordinate.)


I think it's pretty well understood how to use the mechanism of RTs and 
RDs to install routes for overlapping address spaces, as long as the 
addresses are unique in the relevant context.  Reusing an SPI value in a 
different overlay is no different than reusing an IP address in a 
different VPN.


[Joel] we could divide by using separate transport identifiers for an 
SFF which is in multiple overlays.  Seems very fragile.  I do hope there 
is a robust way to make it work.


???  When multiple overlays exist over a common infrastructure, it's 
quite common to have a separate set of tunnels for each overlay, and to 
have a control plane that associates each tunnel with the proper overlay.


[Joel] The assumption in the SFC work is that the SF indicates the need 
for reclassification by adjusting the flags in the NSH header, and that
a classifier co-resident with the SFF then performs reclassification. 
The mechanism you describe in section 6.1 does not seem to support that


Actually, the draft does not say anything whatsoever about how the SF 
talks to a co-resident classifier.


The draft is really concerned only with the fact that the SFF passes a 
packet to a "local" service function, and ultimately gets the packet 
back with an NSH that contains an SPI/SI.  The question is -- what are 
the possible SPI/SI values that the packet may have when the SFF gets it 
back?  In order to do "fast path" forwarding, the SFF needs to create 
forwarding state for this set of SPI/SI's.  If arbitrary 
reclassification is possible, then any value of SPI/SI may be seen when 
the packet comes back, and forwarding state needs to be created for 
every valid SPI/SI value.  It's good to have some indication in advance 
about which SPI/SI values one is likely to see when the packet returns; 
this allows one to maintain only the set of forwarding states that one 
is likely to see.  That's what the markers are for.  Of course, this is 
just an optimization meant to improve performance and scaling.


Perhaps you are saying that it is impossible to create these markers, as 
there is no way to tell in advance just what a classifier may do when 
reclassifying.


Or perhaps you're saying something else that you don't like these 
markers, because they implicitly restrict the sort of reclassification 
that can be done.


[Joel] If an SFF gets a packet with an SI it does not recognize, then it 
is required to drop the packet.


The NSH draft only requires that the packet be dropped if its SPI/SI do 
not "correspond" to a "valid" next hop.   Note that the quoted terms do 
not appear to be defined.  This leaves a lot of leeway for interpretation.


For instance, given an SPI, SPI-X, whose elements are <, 
>, one might decide that  refers to SF2.  
Why?  Because 5 is the largest SI in SPI-X that is not larger than 9.  
If done this way, decrementing the SI by 1 would always get you to the 
next hop, even if successive SIs are not successive integers.


Now suppose that an SPI is modified in real time, by adding or deleting 
elements.  Since the SPIs are learned dynamically, when a change is 
made, there will be a convergence period during which not everyone has 
seen the change.  I think you will see much more predictable behavior 
during the convergence period if the SIs are not changed.


[Joel] Personally, I consider modifying an in-place chain rare enough 
that needing to instead create a new chain, create the state for it, and 
then change the classification rules to use the new chain to be a 
cleaner and more robust way to get there.  But that is just my take.


I don't know whether this will be rare, but perhaps we don't have to 
decide now how rare that will be.  Also, I don't see any reason to 
believe that replacing one chain with another is "cleaner and more 
robust" than modifying a chain that is in use.










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

Re: [bess] Poll for adoption: draft-zzhang-bess-evpn-bum-procedure-updates-03

[Eric C Rosen]

Support.

MVPN has a number of multicast features that are valuable, but haven't 
yet been incorporated into EVPN.  This draft takes a comprehensive look 
at the MVPN  procedures that provide those features, and shows how to 
adapt them to EVPN.   This seems quite valuable to me, and thus I think 
the WG should adopt this draft.


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

Re: [bess] Poll for adoption: draft-dolganow-bess-mvpn-expl-track-02

[Eric C Rosen]

I am not aware of any undisclosed IPR applying to this document.


On 5/30/2016 11:55 AM, Martin Vigoureux wrote:

Hello working group,

This email starts a two-week poll on adopting
draft-dolganow-bess-mvpn-expl-track-02 [1] as a Working Group Document.

Please state on the list if you support adoption or not (in both 
cases, please also state the reasons).


This poll runs until *the 13th of June*.

We are also polling for knowledge of any undisclosed IPR that applies
to this Document, to ensure that IPR has been disclosed in compliance
with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more
details).
If you are listed as an Author or Contributor of this Document please
respond to this email and indicate whether or not you are aware of any
relevant undisclosed IPR. The Document won't progress without answers
from all the Authors and Contributors.
No IPR has been disclosed against this Document

If you are not listed as an author or contributor, then please 
explicitly respond only if you are aware of any IPR that has not yet 
been disclosed in conformance with IETF rules.


Thank you

Martin & Thomas
bess chairs

[1] https://datatracker.ietf.org/doc/draft-dolganow-bess-mvpn-expl-track

___
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] Ben Campbell's No Objection on draft-ietf-bess-pta-flags-03: (with COMMENT)

[Eric C Rosen]

On 5/3/2016 6:48 PM, Ben Campbell wrote:

I am curious why the
"Additional PMSI Tunnel Attribute Flags" registry needs a
standards-action policy. It's pretty obvious why for the main flag
registry, due to the small value-space. Are people concerned that the
Additional flag will also run out of space?


Yes, I think that is an issue.  48 flags may sound like a lot, but the 
existing 8 flags got used up fairly quickly and suddenly; one draft 
grabbed four flag bits.  So FCFS doesn't really seem like an appropriate 
policy here.   The other possible policies are all subject to politics, 
but at least Standards Action comes with early allocation.






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

Re: [bess] Stephen Farrell's No Objection on draft-ietf-bess-pta-flags-02: (with COMMENT)

[Eric C Rosen]

Revision -03 (just posted) has the text resulting from Christian 
Huitema's secdir review, as well as a change resulting from Alexey 
Melnikov's review.



On 5/3/2016 11:41 AM, Stephen Farrell wrote:

Stephen Farrell has entered the following ballot position for
draft-ietf-bess-pta-flags-02: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-pta-flags/



--
COMMENT:
--


The discussion resulting from the secdir review [1] lead
to some suggested changes that haven't yet been included
in an update. This is just to remind ourselves about
that.

[1] https://www.ietf.org/mail-archive/web/secdir/current/msg06525.html


___
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] Mirja Kühlewind's No Objection on draft-ietf-bess-pta-flags-02: (with COMMENT)

[Eric C Rosen]

On 5/2/2016 4:05 AM, Mirja Kuehlewind (IETF) wrote:

Hi,

I guess it’s not possible to registered that bit already in this doc?

Mirja


The registration policy is "Standards Action".  Before registering that 
bit, someone would have to write the draft specifying its use, the WG 
would have to adopt it, etc.  I hope this will be done, but it is 
outside the scope of draft-ietf-bess-pta-flags.


I think there are four other bits that are also known to be in use, 
these are described in draft-ietf-bess-evpn-optimized-ir. Presumably the 
authors of that draft will ask the WG chairs to request "early 
allocation" as soon as the registry is established.






Am 26.04.2016 um 21:29 schrieb Eric C Rosen :

On 4/26/2016 12:22 PM, Mirja Kuehlewind wrote:

Not important but why is the Extension flag bit 1 and not bit 0?

There is reason to believe that bit 0 is already in use in one or more 
deployments.  Hopefully, it will get properly registered once the registry is 
created!





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

Re: [bess] Mirja Kühlewind's No Objection on draft-ietf-bess-pta-flags-02: (with COMMENT)

[Eric C Rosen]

On 4/26/2016 12:22 PM, Mirja Kuehlewind wrote:

Not important but why is the Extension flag bit 1 and not bit 0?


There is reason to believe that bit 0 is already in use in one or more 
deployments.  Hopefully, it will get properly registered once the 
registry is created!




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

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

[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

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

[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

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

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

[Eric C Rosen]

On 3/24/2016 11:17 AM, bruno.decra...@orange.com 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?



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

Re: [bess] Fw: New Version Notification for draft-li-bess-4pe-01.txt

[Eric C Rosen]

On 3/16/2016 4:57 AM, li_zhenqi...@hotmail.com wrote:

Hi, Eric and all,

Try to answer your questions below, please comment.

Q: If the core runs only IPv6/MPLS, and the next hop of a 4PE route is 
an IPv4 address, I don't really see how the next hop resolution is 
going to work, as the next hop (a v4 address) will not appear to be 
reachable through the v6 core.
A: No, you can not use the v4 next hop to reach the egress 4PE in the 
v6 core directly. But, the ingress 4PE can use the v4 next hop to get 
the corresponding v6 address of the egress 4PE and forward the packet 
toward the egress 4PE through the v6 LSP after encapsulation. 
Encapsulation here means adding two labels. Ingress 4PE needs a data 
structure to establish the connection between the v4 next hop and the 
the corresponding v6 address of the egress 4PE. This data structure is 
implementation specific.


I think the key statement here is "Ingress 4PE needs a data structure to 
establish the connection between the v4 next hop and the the 
corresponding v6 address of the egress 4PE. This data structure is 
implementation specific." Whatever implementation technique you choose 
to use, you are still treating the v6 next hop as the real next hop.  I 
don't see why the protocol should not carry the v6 next hop in the next 
hop field, per RFC 5549.




Q: I think your proposal really is intended to treat the v6 address in 
the NLRI as the next hop.  But that leaves open the question of why 
you want to put the next hop address in the NLRI field instead of in 
the next hop field.
A: What I want is to send both the IPv4 and IPv6 addresses of the 4PE 
to other 4PEs.


But the IPv4 address of the 4PE router plays no role in the protocol.  
In the implementation, you seem to be using it only as a sort of pointer 
to the IPv6 address of the 4PE router.


Q: Some people think it's a bad idea for the prefix and the next hop 
to be of different address families; those folks tend to regard RFC 
5549 as a bad solution.

A: I don't think I am one of those folks.

Q: However, I don't see what advantage your proposal has over RFC 
5549.   In order to determine whether a given 4PE route is feasible, 
or whether it is the bestpath, you still have to resolve the IPv6 next 
hop, you still have to consider the IGP distance to the IPv6 next hop, 
etc.
A: If 4PE only gets the v6 addresses of the other 4PEs, how does the 
4PE build its IPv4 routing table? Can it install a v6 address in its 
v4 routing table?


Whether an IPv6 address can be installed as a next hop in the IPv4 
routing table is an implementation issue.


I don't see any reason for the protocol to carry around the IPv4 address 
of the 4PE router, as this information doesn't really play any role.


If you put the next hop in the NLRI, and put a meaningless value in the 
next hop field, you have to revise all the bestpath selection rules.



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

Re: [bess] Fw: New Version Notification for draft-li-bess-4pe-01.txt

[Eric C Rosen]

On 3/10/2016 4:32 AM, li_zhenqi...@hotmail.com wrote:

Thank you very much for your comments, Eric.

Yes, RFC5549 does specify the procedures for creating a route with 
IPv4 or VPN-IPv4 NLRI and an IPv6 next hop. IPv4 NLRI with IPv6 next 
hop is for the situation where an IPv6-only network conneting 
IPv4-only islands. VPN-IPv4 NLRI with IPv6 next hop is for the 4vPE 
situation.


What I want to solve is the 4PE situation, where an IPv6-only network 
running with MPLS connecting the IPv4-only islands. The routes in the 
4PE NLRI have labels assigned by the 4PE routers.


RFC 5549 will work when the IPv6-only network runs MPLS.

If you want the 4PE routers to send labeled IPv4 routes to each other, 
they just need to use SAFI 4.


If the core runs only IPv6/MPLS, and the next hop of a 4PE route is an 
IPv4 address, I don't really see how the next hop resolution is going to 
work, as the next hop (a v4 address) will not appear to be reachable 
through the v6 core.


I think your proposal really is intended to treat the v6 address in the 
NLRI as the next hop.  But that leaves open the question of why you want 
to put the next hop address in the NLRI field instead of in the next hop 
field.




Besides, 4PE routers need both IPv4 next hop and IPv6 next hop to 
build their IPv4 routing table and IPv6 routing table respectively.


Some people think it's a bad idea for the prefix and the next hop to be 
of different address families; those folks tend to regard RFC 5549 as a 
bad solution.


However, I don't see what advantage your proposal has over RFC 5549.   
In order to determine whether a given 4PE route is feasible, or whether 
it is the bestpath, you still have to resolve the IPv6 next hop, you 
still have to consider the IGP distance to the IPv6 next hop, etc.





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

Re: [bess] Joel Jaeggli's Discuss on draft-ietf-bess-mvpn-extranet-06: (with DISCUSS and COMMENT)

[Eric C Rosen]

On 3/10/2016 10:34 AM, joel jaeggli wrote:

I think the question comes down to, is this document adequately
prescriptive when it comes to implementation in a network.
As far as I can tell, no one has offered any reason to think that the 
document is not adequately prescriptive.



You see to be asking us to write the words.


No, you are just being asked to state what you think is needed that 
isn't present.  This should be stated with enough precision to enable 
the authors to know what it would take to lift the DISCUSS.


The text you quote from Sue:


I am looking for an operator-based “abstract” that focuses the reader on the key
points.


does not help me understand what is claimed to be missing.  I do not 
know what an "operator-based abstract" would be, or where it is stated 
that such a thing is required.



unique RD per VRF, yes it discusses this, then brings in the extranet RD
leakage. calling this spongy is maybe an understatement.


This statement is a good example of the way in which the DISCUSS is 
unsatisfactory.  There is in fact no such technical concept as "RD 
leakage", and it is impossible to understand from the above text just 
what objection is being made.


Procedures for the use of the extranet RD are defined in such a way that 
existing procedures using the default RD will still work.



This question
might be easier to discuss cogently if in fact the document were easier
to read. It is not, so you find your CO-ADs relying on the reviews of
domain experts, and previous discussion on the list.


Lack of familiarity with the normative references seems to be a factor 
here.  However, I am not aware of any requirement to provide an 
"executive summary" for people who are not familiar with the normative 
references.


I would like to call your attention to 
http://www.ietf.org/iesg/statement/discuss-criteria.html.  In section 
3.2, "DISCUSS Non-Criteria", it says "None of the following are criteria 
for which the IESG should DISCUSS a document", and among "the following" 
it lists:


Unfiltered external party reviews. While an AD is welcome to consult 
with external parties, the AD is expected to evaluate, to understand and 
to concur with issues raised by external parties. Blindly 
cut-and-pasting an external party review into a DISCUSS is inappropriate 
if the AD is unable to defend or substantiate the issues raised in the 
review.


Also among the non-criteria is:

Stating "I think there's something wrong here, and I'll tell you what it 
is later" is not appropriate for a DISCUSS;


I think this would rule out a DISCUSS based on the feeling that "there 
might be some mistakes in the part of the document that I don't understand".


On that same page, it lists among the valid DISCUSS criteria:

It would present serious operational issues in widespread deployment, by 
for example neglecting network management or configuration entirely.


This seems to be the main criterion being used to support the DISCUSS, 
but given the number of provisioning rules and warnings contained in the 
document, and the extensive discussion of what has to be configured in 
the PEs, I don't see how one could claim that network management or 
configuration are neglected entirely.


Thus I think this DISCUSS violates the IETF process in the following ways:

- The DISCUSS is too vague to be actionable.

- It is not based on a valid DISCUSS criterion.

- It relies entirely on an "unfiltered external party review".



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

Re: [bess] Fw: New Version Notification for draft-li-bess-4pe-01.txt

[Eric C Rosen]

I think this problem is already solved in RFC 5549.

RFC 5549 specifies the procedures for creating a route with IPv4 or 
VPN-IPv4 NLRI and an IPv6 next hop, which should provide both 4PE and 
4vPE functionality.


Your proposal seems to differ, in that it puts the v6 next hop address 
in the NLRI, rather than in the next hop field.  I don't think it makes 
much sense to put the next hop address in the NLRI, as that would then 
require a special set of rules for bestpath selection.


On 3/8/2016 10:37 PM, li_zhenqi...@hotmail.com wrote:

Hello all,

I update my draft. 4PE is introduced in this doc to meet the gap 
pointed out in RFC7439. 4PE routers in IPv6-only MPLS network can use 
MP-BGP extended in this doc to connect IPv4-only islands.. Your 
comments are very appreciated.



li_zhenqi...@hotmail.com

*From:* internet-drafts 
*Date:* 2016-03-09 09:54
*To:* Zhenqiang Li 
*Subject:* New Version Notification for draft-li-bess-4pe-01.txt
A new version of I-D, draft-li-bess-4pe-01.txt
has been successfully submitted by Zhenqiang Li and posted to the
IETF repository.
Name: draft-li-bess-4pe
Revision: 01
Title: Connecting IPv4 Islands over IPv6 MPLS Using IPv4 Provider
Edge Routers (4PE)
Document date: 2016-03-08
Group: Individual Submission
Pages: 9
URL: https://www.ietf.org/internet-drafts/draft-li-bess-4pe-01.txt
Status: https://datatracker.ietf.org/doc/draft-li-bess-4pe/
Htmlized: https://tools.ietf.org/html/draft-li-bess-4pe-01
Diff: https://www.ietf.org/rfcdiff?url2=draft-li-bess-4pe-01
Abstract:
   This document explains how to interconnect IPv4 islands over a
   Multiprotocol Label Switching (MPLS)-enabled IPv6-only core.  This
   approach relies on IPv4 Provider Edge routers (4PE), which are Dual
   Stacks in order to connect to IPv4 islands and to the MPLS
core.  The
   4PE routers exchange the IPv4 reachability information
transparently
   over the core using the Multiprotocol Border Gateway Protocol (MP-
   BGP).  MP-BGP is extended to do this.  A new Subsequence Address
   Family Identifier (SAFI) with corresponding new format Network
Layer
   Reachability Information (NLRI), is introduced.  The BGP Next Hop
   field is used to convey the IPv4 address of the 4PE router, a field
   is added in Network Layer Reachability Information (NLRI) to convey
   the IPv6 address of the 4PE router, so that dynamically established
   IPv6-signaled MPLS Label Switched Paths (LSPs) can be used without
   explicit tunnel configuration.
Please note that it may take a couple of minutes from the time of
submission
until the htmlized version and diff are available at tools.ietf.org.
The IETF Secretariat



___
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] Benoit Claise's Discuss on draft-ietf-bess-mvpn-extranet-04: (with DISCUSS and COMMENT)

[Eric C Rosen]

On 2/28/2016 11:36 AM, joel jaeggli wrote:

Anyone who understands the normative references will know what a Route
>Distinguisher is and what a VRF is.  The fundamental part of
>provisioning any RFC4364 VPN is to create the VRFs, and to provision
>each VRF with Route Distinguishers.

Yeah, I'm not convinced of that,
You're not convinced that the normative references explain the concepts 
of "VRF" and "RD"?



there is eleborate discussion of the
requirement for one RD per VRF and then extranet seperation adds a twist
that.
True.  Is there something about this that is not explained properly?  If 
so, please say what.


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

Re: [bess] Benoit Claise's Discuss on draft-ietf-bess-mvpn-extranet-04: (with DISCUSS and COMMENT)

[Eric C Rosen]

On 2/24/2016 6:14 PM, joel jaeggli wrote:

Providing
operational advice isn't in scope? Section 1.3 goes into detail to the
point where it is hard to parse the application of route  distinguishers.
Anyone who understands the normative references will know what a Route 
Distinguisher is and what a VRF is.  The fundamental part of 
provisioning any RFC4364 VPN is to create the VRFs, and to provision 
each VRF with Route Distinguishers.


Section 1.3 states that, for the purposes of MVPN, two VRFs MUST NOT be 
configured with the same RD.


It further states that if the "extranet separation" feature is not 
required, every VRF MUST be configured with a single RD.  If the feature 
is required, every VRF MUST be configured with two RDs, one called the 
"default RD" and one called the "extranet RD".


In other words, that entire section specifies requirements that must be 
met by whatever process is used to provision the MVPN extranet. It also 
specifies reasons why these requirements are in place by mentioning some 
of the situations in which the protocols presuppose that these 
provisioning requirements are met.


I don't see what's missing.  I find it puzzling that a section whose 
whole purpose is to clarify the provisioning requirements (and the 
dependencies of the protocols on those requirements) would be held up as 
an example of how there are no operational considerations.


It's true that the section is more focused on providing a precise 
description of the provisioning requirements than on providing a 
tutorial or guide or "advice".  But the former is within the scope of 
the document and the latter is not.  After all, the purpose of this 
document is to specify the protocols and procedures that need to be 
implemented.  The purpose is not to define a service model or 
provisioning system.



extranets are by the nature set up by two independent entities. one
presumes both mutual cooridnation, and design efforts required to avoid
collisions.
Extranet involves two VPNs, but the provisioning of the extranet is 
generally done by the single service provider that is providing both of 
those VPNs.  Thus the provisioning of an extranet generally does not 
require coordination between two independent entities.


It is possible that two independent providers will coordinate to provide 
an extranet, but it is also possible that two independent providers will 
coordinate to provide a single VPN, if that single VPN has sites 
attached to both providers.


For this reason, RFC4364 defines the Route Targets in such a way as to 
enable service providers to allocate globally unique Route Targets.   
The need for uniqueness of the Route Targets is not specific to extranet 
or to multicast, and is covered in the normative references.



the concerns in 2.3.2

Section 3 of this document describes a procedure known as "extranet
separation".  When extranet separation is used, the ambiguity of
Section 2.1 is prevented.  However, the ambiguity of Section 2.2 is
not prevented by extranet separation.  Therefore, the use of extranet
separation is not a sufficient condition for avoiding the procedures
referenced in Section 2.3.1.  Extranet separation is, however,
implied by the policies discussed in this section (Section 2.3.2).

so being prescriptive with respect to how these may be operated seems
like it would be helpful.
The draft goes into excruciating detail about how to avoid address 
ambiguity when moving data between two VPNs that have overlapping 
address spaces.  It specifies a protocol-based mechanism ("discard from 
the wrong tunnel") allows you to determine which of two streams is the 
one you want, even if both streams use the same IP addresses.  It also 
specifies policies, for assigning multicast flows to tunnels, that can 
be used to avoid address ambiguity.


Again, I don't see what is lacking.

Note that there is no requirement to have a separate "operational
considerations" section.
nor would that I think be necessary to address the concern.

Perhaps someone could explain to me exactly what is necessary to address 
the concern.




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

Re: [bess] I-D Action: draft-ietf-idr-tunnel-encaps-01.txt

[Eric C Rosen]

On 2/11/2016 6:38 PM, Carlos Pignataro (cpignata) wrote:

Hi, Eric,

Thanks for sending this out — I am interested in this document, and will give 
it a critical review (in particular the sections you call out below).

Thanks!


In the mean time, however, I wanted to send a few high-level comments 
(prepended with “CMP”) from scanning through it. I hope these are useful.

3.2.  Encapsulation Sub-TLVs for Particular Tunnel Types

This section defines Tunnel Encapsulation sub-TLVs for the following
tunnel types: VXLAN ([RFC7348]), VXLAN-GPE ([VXLAN-GPE]), NVGRE
([RFC7637]), GTP ([GTP-U]), MPLS-in-GRE ([RFC2784], [RFC2890],
[RFC4023]), L2TPv3 ([RFC3931]), and GRE ([RFC2784], [RFC2890],
[RFC4023]).


CMP: More comments below, but I am a bit confused about the need to include 
MPLS-in-GRE, and the lack of IP-in-IP (Tunnel Type 7) for example.
MPLS-in-GRE is included in section 3.2 because there is already a tunnel 
type codepoint allocated for it, and if that tunnel type is used, an 
encapsulation sub-TLV is needed in order to signal the GRE key.


One can argue that there is no need for the MPLS-in-GRE tunnel type, 
since everything you can do with it could be done instead with the GRE 
tunnel type.  But unless and until we decide to deprecate the 
MPLS-in-GRE tunnel type, it needs to be included.In theory, I would 
love to see the MPLS-in-GRE tunnel type deprecated, but I worry that 
that might introduce a backwards compatibility problem.This is 
certainly something that can be discussed by the WG.


IP-in-IP is not mentioned in section 3.2 because, although there is a 
tunnel type codepoint allocated for it, no one has ever defined an 
encapsulation sub-TLV for it.  Also, if it is necessary to signal values 
for the fields of the outer iP header, it might make more sense to use 
an "outer encapsulation sub-TLV" (section 3.3).  Do you have an opinion 
about this?


CMP: A couple of editorial comments as well: For GRE, I think you also need to 
cite RFC 7676 (GRE over IPv6)

Sure.


CMP: Also, having this document Obsolete RFC 5512 effectively also orphans a 
number of Tunnel types and sub-TLVs. For example, Tunnel Types values 3-6 from 
RFC 5566 (IPsec Tunnel Encap) and IPsec Tunnel Authenticator sub-TLV. I do not 
know if the answer is to also have that incorporated (useful parts as you say) 
and obsoleted. Maybe not, maybe it does make sense given it is a short doc, 
which would lead to a complete self-contained set of Tunnel types.
I think RFC 5566 will have to be obsoleted and replaced.  I've been 
thinking about that, but I'm still not sure how much of 5566 should be 
moved into the tunnel-encaps draft and how much should be in a separate 
draft.  There are some non-obvious issues to consider.  For example, 
5566 really is  just intended to facilitate iPsec Security Associations 
between BGP Next Hops, but with the tunnel encapsulation attribute we 
could presumably set up Security Associations from ingress to egress.


3.2.4.  L2TPv3
…
   Cookie: an optional, variable length (encoded in octets -- 0 to 8
   octets) value used by L2TPv3 to check the association of a

CMP: The cookie can only take sizes 0, 4, or 8 octets, and not 0..8
Do you have a reference for that?  Section 4.1 of RFC 3931 seems to say 
only that the field is variable length with a maximum size of 64 bits.


3.2.7.  MPLS-in-GRE

CMP: This seems to be an example and not a separate encapsulation type. This is 
GRE Type, with MPLS as protocol sub-TLV. I see that the section says:

While it is not really necessary to have both the GRE and MPLS-in-GRE
tunnel types, both are included for reasons of backwards
compatibility.

CMP: I will also note that having two different ways of doing the same thing 
(Tunnel Type 2 and protocol 0x8847 vs. Tunnel Type 11) takes us away from 
interop., and that there does not seem to be MPLS-in-GRE defined in any RFC (so 
it seems like potentially a good time to rationalize instead of perpetuate). My 
$0.02 only.

Tunnel type 11 is used by draft-ietf-bess-evpn-overlay.


CMP: Should MPLS-over-GRE be an example only? Or otherwise, how do we interop 
the two types of “ MPLS-over-GRE”?
Well, the two ways of doing the same thing are explicitly defined to be 
equivalent, so I don't think there is an interop issue, the issue is 
more of "can we get rid of the MPLS-in-GRE type without causing a 
backwards compatibility problem".

Should an example be also added about MPLS-over-L3TPv3?

Surely no one will ever propose MPLS-over-L2TPv3 again!


3.3.1.  IPv4 DS Field

CMP: Why not also define this for IPv6?
There are a lot of possible Outer Encapsulation sub-TLVs that could be 
created, I only included a couple of examples that seemed like they 
might be useful.  If you have some sub-TLVs to suggest for the case 
where the outer encapsulation is IPv6, please suggest some text.   (Some 
IPv6-specific text will probably make it easier to get the draft past 
the IESG ;-))


3

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

[Eric C Rosen]

I've reposted the draft as draft-rosen-mpls-rfc3107bis-00.

On 2/11/2016 10:18 AM, Alvaro Retana (aretana) wrote:

On 1/13/16, 1:11 PM, "mpls on behalf of Eric C Rosen"
 wrote:

Hi!


While I put "idr" in the name of the draft, it's not completely
obvious which WG should own this draft (assuming it progresses)

Deborah and I had a quick chat about this point and we think that (if it
progresses) this document should belong in mpls -- if for no other reason
just because RFC3107 was produced there.

mpls-chairs: If this document progresses, please make sure that both idr
and bess are cc'd on adoption and WGCL.

Thanks!

Alvaro.



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

Re: [bess] draft-rosen-idr-rfc3107bis-00

[Eric C Rosen]

Thanks for reviewing the draft!

On 1/26/2016 2:47 AM, Dongjie (Jimmy) wrote:

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


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


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

Re: [bess] Benoit Claise's Discuss on draft-ietf-bess-mvpn-extranet-04: (with DISCUSS and COMMENT)

[Eric C Rosen]

On 1/27/2016 4:37 AM, Benoit Claise wrote:


This document doesn't give an operator “so-what” for deployment in 60 
pages.

I'm afraid I don't understand this sentence.

You know, a few summary paragraphs that indicates where this 
specification is useful and where it is not for operators, and the 
potential fragility of the solution (which could be in a new 
operational consideration section or in the security considerations.
As I've been trying to explain to Sue, I don't understand what is being 
asked for in these "few summary paragraphs".   An "operator's guide to 
provisioning extranets" would be useful, but not within the scope of 
this draft.


The security considerations section already points out that 
misconfiguration of the Route Targets may result in misdelivery of 
traffic; the above text is merely a paraphrase of material that is 
already present in the document.


Note that there is no requirement to have a separate "operational 
considerations" section.


I don't think I've seen text around coordination to set up filter, for 
example.

Coordination to set up filters?  I don't know what you are referring to.



Sue has been trying to be helpful and even proposed some text:

Whenever a VPN is provisioned, there is a risk that provisioning
errors will result in an unintended cross-connection of VPNs,
which would create a security problem for the customers.  Extranet
can be particularly tricky, as it intentionally cross-connects
VPNs, but in a manner that is intended to be strictly limited by
policy.  If one is connecting two VPNs that have overlapping
address spaces, one has to be sure that the inter-VPN traffic
isn't to/from the part of the address space that is in the
overlap. The draft discusses a lot of the corner cases, and a lot
of the scenarios in which things can go wrong.



Actually, I wrote that text in an email to Sue.  Although it too is just 
a paraphrase of existing materiaI, I could add it to the "overview" 
section as part of the description of what an extranet is.   Are you 
saying that you will lift the DISCUSS if I just add that paragraph?




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

Re: [bess] draft-rosen-idr-rfc3107bis-00

[Eric C Rosen]

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.

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


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

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

[bess] draft-rosen-idr-rfc3107bis-00

[Eric C Rosen]

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

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

Re: [bess] Benoit Claise's Discuss on draft-ietf-bess-mvpn-extranet-04: (with DISCUSS and COMMENT)

[Eric C Rosen]

On to version -06 ...

On 12/23/2015 10:13 AM, Susan Hares wrote:


Sections which must be added to clear my concerns



*4.4.1 Extranet Source Extended Community *

   To facilitate this, we define a new Transitive Opaque Extended  
Community, the "Extranet Source" Extended Community.


   The value field of this extended community is all zeros.

*Restrictions: *This value field MUST be set  to zero upon 
origination,  MUST be ignored upon reception and MUST  be passed 
unchanged by intermediate routers.


*Additional Restrictions: *A Route Reflector MUST NOT add/remove the 
Extranet Source Extended  Community from the VPN-IP routes reflected 
by  the Route Reflector,  including the case where VPN-IP routes 
received via IBGP are reflected to EBGP peers (inter-AS option (c), 
see [RFC6513]   Section 10).




The draft has the following text in section 4.4.1 ("The Extranet Source 
Extended Community"):


"The value field of the Extended Community MUST be set to zero. "

"A PE router that interprets this Extended Community MUST ignore the 
contents of the value field."


and the following text in section 4.4.2 ("Distribution of Extranet 
Source Extended Community"):


   "A Route Reflector MUST NOT add or remove the Extranet Source 
Extended Community from the VPN-IP routes reflected by the Route 
Reflector, including the case where VPN-IP routes received via IBGP are 
reflected to EBGP peers (inter-AS option (c), see [RFC6513] Section 
10).  The value of the Extended Community MUST NOT be changed by the 
route reflector."


   "When re-advertising VPN-IP routes, ASBRs MUST NOT add/remove the 
Extranet Source Extended Community from these routes.  This includes 
inter-AS options (b) and (c) (see [RFC6513] Section 10).  The value of 
the Extended Community MUST NOT be changed by the ASBRs."


It seems to me that this contains the information you have requested.  
It may not be in the format you prefer, but I think it goes beyond the 
scope of an ops-dir review (or an IESG Discuss) to demand format changes.


*4.4.2 Extranet Separation Extended community *

**

We define a new Transitive Opaque Extended Community, the "Extranet  
Separation" Extended Community.  This Extended Community is used only  
when extranet separation is being used.


*Restrictions:*  Its value field MUST be set to zero upon origination, 
MUST be ignored upon reception, and MUST be


   passed unchanged by intermediate routers.

*  Restrictions on Adding/deleting this community:*  ??  (Eric – 
please add something here).


The draft now contains the following text in section 4.5 ("The Extranet 
Separation Extended Community"):


"We define a new Transitive Opaque Extended Community, the "Extranet 
Separation" Extended Community (see [RFC4360], [RFC7153], and Section 9 
of this document).  This Extended Community is used only when extranet 
separation is being used. Its value field MUST be set to zero upon 
origination, MUST be ignored upon reception, and MUST be passed 
unchanged by intermediate routers.  A Route Reflector MUST NOT add or 
remove the Extranet Separation Extended Community from the routes it 
reflects, including the case where routes received via IBGP are 
reflected to EBGP peers (inter-AS option (c), see [RFC6513] Section 10)."


It seems to me that this contains the information you have requested.


*Comments that could be put in a Security section: *

**

Whenever a VPN is provisioned, there is a risk that provisioning 
errors will result in an unintended cross-connection of VPNs, which 
would create a security problem for the customers.  Extranet can be 
particularly tricky, as it intentionally cross-connects VPNs, but in a 
manner that is intended to be strictly limited by policy.



The Security Considerations section already contains the following text:

 "As is the case with any application of technology based upon 
[RFC4364], misconfiguration of the RTs may result in VPN security 
violations (i.e., may result in a packet being delivered to a VPN where, 
according to policy, it is not supposed to go)."


I don't think the above requested text really adds anything, it's just 
saying the same thing over again.


If one is connecting two VPNs that have overlapping address spaces, 
one has to be sure that the inter-VPN traffic isn't to/from the part 
of the address space that is in the overlap.  The draft discusses a 
lot of the corner cases, and a lot of the scenarios in which things 
can go wrong.


The difficulty of dealing with overlapping address spaces when 
connecting two VPNs is already discussed extensively throughout the 
document.  I don't see that the requested paragraph adds anything of 
substance.


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

Re: [bess] WG Last Call for draft-ietf-bess-pta-flags-01

[Eric C Rosen]

On 1/5/2016 9:48 AM, Martin Vigoureux wrote:

*If* you are listed as a document author or contributor of
draft-ietf-bess-pta-flags-01 please respond to this email and indicate 
whether or not you are aware of any relevant IPR. 


I am not aware of any relevant IPR.

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

Re: [bess] I-D Action: draft-ietf-idr-tunnel-encaps-01.txt

[Eric C Rosen]

The -01 revision of draft-ietf-idr-tunnel-encaps has the following 
changes from the -00 revision:


- By popular request, it has been written in such a way as to obsolete 
RFC5512.  This means that anything useful in RFC5512 had to be 
incorporated into the new draft.  I would welcome opinions on whether 
this was done correctly.


- Two new sub-TLVs are specified:  "MPLS Label Stack" and "Prefix-SID".  
I would welcome opinions on whether these are useful or not.  (I'm 
pretty sure that the first is useful, the second is more speculative.)


- If you are familiar with deployed uses of the Encapsulation Extended 
Community, the Color Extended Community, or the Router's MAC Extended 
Community, it may be worth checking section 4 to make sure that the 
draft does not introduce any problems.


- I wish more folks would take a critical look at section 8, which is 
primarily about the use of VXLAN/NVGRE/VXLAN-GPE together with labeled 
address families.


I would also be interested in hearing if anyone has an opinion on the 
utility of using this sort of mechanism to signal IPsec tunnels.  Once 
RFC 5512 is obsoleted, RFC 5566 ("BGP IPsec Tunnel Encapsulation 
Attribute") will need to be revised.  It might be possible to generalize 
that in such a way as to facilitate the secure interconnection of two 
private ASes across the public Internet.  Comments on whether RFC 5566 
takes a reasonable approach would be welcome.




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

Re: [bess] Benoit Claise's Discuss on draft-ietf-bess-mvpn-extranet-04: (with DISCUSS and COMMENT)

[Eric C Rosen]

On 12/22/2015 12:51 PM, Susan Hares wrote:


Eric:

Thank you for revisions in version -05 of your document. 
 Unfortunately it does not resolve either of the two points I raised.


1)*On the BGP Extended Communities*, I feel your specification is 
*unclear and warrants change on the DISCUSS* Criteria due to 
interoperability issues.




I've explained why I don't think this is correct.  In particular, I 
don't think it is wise to mention the value of the "Transitive Opaque 
Extended Community Type" codepoint, as this can be found in the IANA 
registry for Transitive Extended Community types, and implementers 
should really be encouraged to consult the registries for the codepoints.


I’ve given you 2 small sections to add to your document at the 
beginning of section 4.4. to resolve this DISCUSS point.




Note that the codepoint you mention for Transitive Opaque Extended 
Community Type is not correct.  Unnecessary last minute changes do tend 
to introduce errors.


You need to just fill in one part below on RR restrictions for 
*Extranet Separation Extended community*.




I will add some text saying that RRs must not add or remove this EC.

2) *On the deployment section:*  I given text and examples – but I 
think you still misunderstand what I am looking for.




Perhaps.


Since you are an author of academic papers,



I am not.

consider I am looking for an operator-based “abstract” that focuses 
the reader on the key points.I am sure you can create one for this 
document, but I not clear why you object to it the concept.




It seems to me that you are asking for something that could be titled 
"An Operator's Guide to Provisioning Extranet MVPN".  While that might 
be useful, it is not within the scope of the current document.  As I've 
said, I am not aware of any IETF requirement that requires such a thing 
to be included.


will you please let me know that you have read my suggested text 
insertions on both these topics.


I have.








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

Re: [bess] Benoit Claise's Discuss on draft-ietf-bess-mvpn-extranet-04: (with DISCUSS and COMMENT)

[Eric C Rosen]

Draft-ietf-bess-mvpn-extranet-05 has been posted.

This revision contains some edits to the sections on the Extended 
Communities, and some other editorial changes, stemming from the ops-dir 
review.


I did not follow the suggestion of the ops-dir review to add an 
"Operator Tips and Tricks" section, as that would be outside the scope 
of the document, and there is no IETF requirement to include such a section.


On 12/17/2015 8:30 AM, Benoit Claise wrote:

Benoit Claise has entered the following ballot position for
draft-ietf-bess-mvpn-extranet-04: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-extranet/



--
DISCUSS:
--

As mentioned in Sue Hares' OPS DIR, 3 major concerns. The last one is
actually for the security ADs.

Status: Not ready,  three major concerns and two editorial nits:

Major concerns:

1)  Specification of the Extranet Source Extended Community and Extra
Source extended Community

Please provide the type of detail as show in RFC 4360 sections 3.1, 3.2,
and 3.3.

2)  Why is there no Deployment considerations section?

The whole draft is a set of rules for handling policy, BGP A-D routes,
tunnel set-up, and PIM Join/leaves in the case of an intra net.  Unless
these rules are followed exactly, traffic may flow into a VPN it is not
suppose to.

If the customer and the SP must coordinate on setting up filters, the
procedure is outside the document.

An error in any of these set-ups is considered a “security violation”.

Milo Medin stated “with enough trust” a rock can fly to the moon.
However, the NASA flights were fragile and risky.  In the journey to the
moon, there was no other choice.  Instrumentation has 4-5 backups.

In this set-up, one has to ask “is there another choice” to this whole
design that seem fragile addition of extranets to an intra-AS multicast
design.  If the design is not fragile, then there should be a deployment
section indicating how to manage the RTs, RDs, and policy set-up.
Perhaps experience with the Intra-As has shown deployment tips that would
make this less fragile.  If so,  it would be good to include an
operations consideration section.

If a new class of tools provides monitoring or provisioning, mentioning
these would be useful.  If yang modules are being developed, that would
be useful.

Places that indicate issues with violated constraint:

p. 11, 12, 19 (2.3.2 – a priori knowledge, inability to detect), , p. 25
last paragraph (violation of constraints will cause things to not work.
However, only policy can control), p. 27 4.2.2 (1st paragraph, Route
Reflector must not change), p. 31 (5.1, first paragraph),

3)  Is security section really a security section? It seems more like
“do this policy” or this will fail.  It should get a stronger review from
the security directorate


--
COMMENT:
--

Editorial suggestions:

  


Summary: In general the authors provide dense English text to describe
this rules.   In general the English text contains valid complex
sentences.  However, a few things should be suggested:

  


1)  PTA – define it in a definition section or spell out the
abbreviation

2)  Phrases like  “the RT RT-R” become overly dense.  Use “Route
Target RT-R”.

3)  Breaking up section 6.2.1 – with subjection and subtitles would
make it more readable,

4)  P. 36 second paragraph.  The reason for the “MUST” in 1st full
paragraph is a bit vague.  It seems logical, but the reasoning is just
vague in the text.

5)  paragraph 2 in page 47 (section 7.3.1) is awkward, please reword.


6)  Paragraph 5 in page 47 (section 7.3.1) – does not explain why the
condition should hold.  The authors have done this in eac other case, so
it seems inconsistent.

7)  Page 53 – section 7.4.5 paragraph 3  “VRF route Import EC” –
please spell out first usage and give abbreviation (VRF Route Import
Extended Community (EC).




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

Re: [bess] Benoit Claise's Discuss on draft-ietf-bess-mvpn-extranet-04: (with DISCUSS and COMMENT)

[Eric C Rosen]

Sue,

With regard to the issues re extended communities, you say "I cannot 
tell from your description what fields exist or the values in these two 
communities".


Per RFC 4360, an EC consists of a type field, possibly a sub-type field, 
and a value field.  The two ECs are defined to be Transitive Opaque 
Extended Communities.  Per RFC 7153, the codepoint to place in the type 
field of a Transitive Opaque Extended Community can be found in the IANA 
registry "BGP Transitive Extended Community Types".  Also per RFC 7153, 
the codepoints to placed in the sub-type field of a Transitive Opaque 
Extended Community can be found in the IANA registry "Transitive Opaque 
Extended Community Sub-Types", and the document requests IANA to make 
these two sub-type assignments. The text of the extranet draft says, in 
both cases, that the value field is to be set to zero.  Thus the fields 
and values are already clearly specified.  However, I did neglect to add 
normative references to RFC 4360 and RFC 7153.


I will add normative references to both RFC 4360 and RFC 7153 to the 
sections defining the two new ECs.


I'll modify the text a bit to make it clearer that the value field of 
the ECs MUST be set to zero, MUST be left unchanged during propagation, 
and MUST be ignored upon reception.


With regard to deployment considerations ...

Sue> What is necessary for the OPS/NM directorate review is a summary 
deployment section to guide operations on deployment tools, tips, and 
constraints.


I am not aware of any IETF requirement to include such a section.

Sue> Management of OAM overlays is a necessary part of understanding a 
protocol which is based 50+ pages of rules.  Do you believe this 
protocol can operate without standard monitoring or provisioning tools?


Certainly the protocol can operate without standard tools.  Numerous 
deployments of Extranet MVPN have been operating for years without 
standard tools.  Whether provisioning and/or monitoring tools need to be 
standardized is orthogonal to anything in this document.


It might be nice for operators to have tools to verify whether their 
provisioning and their device configurations have been done correctly, 
but the design of such tools is certainly outside the scope of this 
document.


Sue> you indicate that if the rules/constraints in this complex overlay 
of rules are violated (p. 11, 12, 19), and especially p. 19 in section 
2.3.2 which indicates a priori knowledge, inability to detect.


Whenever a VPN is provisioned, there is a risk that provisioning errors 
will result in an unintended cross-connection of VPNs, which would 
create a security problem for the customers.  Extranet can be 
particularly tricky, as it intentionally cross-connects VPNs, but in a 
manner that is intended to be strictly limited by policy.  If one is 
connecting two VPNs that have overlapping address spaces, one has to be 
sure that the inter-VPN traffic isn't to/from the part of the address 
space that is in the overlap.  The draft discusses a lot of the corner 
cases, and a lot of the scenarios in which things can go wrong.  But it 
is not intended to be an "operator's guide to provisioning and 
configuring extranet MVPN."


With regard to section 2.3.2, the point is the following.  If one is 
deploying hardware that cannot implement the "discard multicast flows 
that are received on the wrong tunnel" procedures, then one has to 
provision the extranet to limit the ways in which multiple flows can be 
aggregated into a single tunnel.  Section 2.3.2 also points out that one 
cannot tell from inspection of the control messages whether this 
provisioning has been done correctly. Operators worried about whether 
their provisioning systems are up to the task may choose to deploy 
equipment that can do the "discard multicast flows from the wrong 
tunnel" procedures.


Sue> What is necessary for the OPS/NM directorate review is a summary 
deployment section to guide operations on deployment tools, tips, and 
constraints.  3+ paragraphs in 1 section.


I'm still perplexed about what you are asking for, or about what you 
think these "3 paragraphs" would say.  The draft has extensive 
discussion of deployment constraints.  There is no IETF requirement for 
a document of this sort to include a "tips and tools" section; that is 
clearly out of scope.


Eric




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

Re: [bess] Kathleen Moriarty's Discuss on draft-ietf-bess-mvpn-extranet-04: (with DISCUSS)

[Eric C Rosen]

On 12/17/2015 8:47 PM, Kathleen Moriarty wrote:

I just have one question/request to improve the security consideration
section.  The only security mentioned in this draft is what's called a
"security violation", where traffic may go to the incorrect "VPN"
endpoint.  If you are worried about traffic winding up in the wrong
place, why is there no consideration for observing this traffic on the
wire?  Since there is no encryption, wouldn't this also be a security
consideration to call out specifically?

Mention of the possibility of active attacks that could alter or tamper
with the traffic or passive attacks that could observe the traffic as a
risk due to lack of encryption (confidentiality protection) would help or
a reason why this doesn't matter.
The reason I didn't mention this in the Security Considerations section 
is that the issues are not specific to Extranet MVPN, which is the topic 
of this document.   The Security Considerations section mentions those 
issues that could result in misdelivery of traffic if the procedures of 
the document are not properly executed; this set of issues is certainly 
within the scope of the document.


I understand that there are issues having to do with the possibility of 
observing or altering the traffic on the wire.  Certainly I could 
mention that the procedures of this document do not provide encryption, 
and hence do not by themselves ensure the privacy/integrity of the data 
against attacks on the backbone network.   Would that be sufficient?


I don't want to make any specific recommendations for mitigating those 
attacks, because:


- Issues of how to provide privacy/integrity for multicast traffic in 
general would seem to be out of scope for this document;


- Issues of how to provide privacy/integrity for various 
tunneling/encapsulation methods would seem to be out of scope for this 
document;


- Issues of how to provide privacy/integrity for the base L3VPN 
technology would seem to be out of scope for this document;


- Issues of how a Service Provider can protect its backbone network 
against various attacks would also seem to be out of scope for this 
document.







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

Re: [bess] Benoit Claise's Discuss on draft-ietf-bess-mvpn-extranet-04: (with DISCUSS and COMMENT)

[Eric C Rosen]

I responded to Sue's review, but noticed that the response did not go to 
the BESS mailing list.  So I am sending my response again; apologies to 
those who are getting it twice.


On 12/17/2015 7:47 AM, Susan Hares wrote:


Eric, Rahul, Yiqun, and Thomas:

I have reviewed this document as part of the Operational directorate's

ongoing effort to review all IETF documents being processed by the 
IESG.  These


comments were written with the intent of improving the operational 
aspects of the


IETF drafts. Comments that are not addressed in last call may be 
included in AD reviews


during the IESG review.  Document editors and WG chairs should treat 
these comments


just like any other last call comments.

Please let me know if any of these comments are unclear.  This is 
interesting BESS work, and a clear deployable specification will help 
with multicast traffic (video and other traffic).


Sue Hares

==

Status: Not ready,  three major concerns and two editorial nits:

Major concerns:

1)Specification of the Extranet Source Extended Community and Extra 
Source extended Community


Please provide the type of detail as show in RFC 4360 sections 3.1, 
3.2, and 3.3.


It would not be correct to do so.  As you may recall, RFC7153 
reorganized the Extended Community registries, and Section 4 of RFC7153 
provides instructions  on how to request Extended Community codepoints 
from IANA.   In fact, one of the main purposes of RFC7153 was to 
eliminate the need to provide IANA with the sort of detail that is 
indicated in RFC4360.  I believe that the specification of the two ECs 
(and the request for codepoints for them) is in accord with RFC7153 and 
does not need revision.



2)Why is there no Deployment considerations section?

There is no requirement for a Deployment Considerations section, so 
absence of one cannot be grounds for a DISCUSS.  I will interpret this 
comment as meaning that there is insufficient discussion of deployment 
issues.  However, I find the comment puzzling, as so much of the draft 
is about proper provisioning of the Route Targets, and Route 
Distinguishers.  There is also quite a bit of discussion about corner 
cases, such as (a) the problem that may arise if a source host 
originates both extranet and non-extranet sources, and (b) the problem 
that may arise if a single address prefix is the best match for both an 
extranet source and a non-extranet source.


In fact, you say yourself:


The whole draft is a set of rules for handling policy, BGP A-D routes, 
tunnel set-up, and PIM Join/leaves in the case of an intra net.  
Unless these rules are followed exactly, traffic may flow into a VPN 
it is not suppose to.



So I really don't understand what you think is missing.


If the customer and the SP must coordinate on setting up filters, the 
procedure is outside the document.


Yes, the interaction between the service provider and its customers is 
outside the scope of this document.



An error in any of these set-ups is considered a “security violation”.

Not quite; any error in these set-ups could result in a security 
violation, i.e., in delivery of data to hosts that aren't supposed to 
get it.


In this set-up, one has to ask “is there another choice” to this whole 
design


Certainly the WG has had plenty of time to come up with up with a better 
alternative.


 there should be a deployment section indicating how to manage the 
RTs, RDs, and policy set-up.


I do not understand what you think is missing.  This is covered quite 
extensively in sections 1.3, 4, and 5.


Perhaps experience with the Intra-As has shown deployment tips that 
would make this less fragile.  If so,  it would be good to include an 
operations consideration section.


I do not think there is any requirement to have "deployment tips" in 
this document, nor is there any requirement to have an "operations 
considerations" section.  However, since so much of the document is 
devoted to the issue of how to properly provision the RTs and RDs, I 
don't quite understand what you think is not covered.


If a new class of tools provides monitoring or provisioning, 
mentioning these would be useful.  If yang modules are being 
developed, that would be useful.




It is not within the scope of this document to "mention" monitoring or 
provisioning tools.  Yang models are also outside the scope of this 
document.


Places that indicate issues with violated constraint:

p. 11, 12, 19 (2.3.2 – a priori knowledge, inability to detect), ,


I am not entirely sure what you are asking.

As discussed in Section 2, the big problem in MVPN extranet is that an 
egress PE may receive two distinct multicast flows that happen to have 
the same IP source and IP group address, say (S,G).The procedures 
and policies specified in the draft prevent two such flows from 
traveling across the backbone on the same tunnel.  However, the detailed 
examples in sections 2.1 and 2.2 show how a given egress VRF can end up 
listening 

Re: [bess] Introducing a one-implementation requirement before WG last calls

[Eric C Rosen]

I am very strongly opposed to this "proposal".

It takes the WG in the wrong direction, and attempts explicitly to undo
the work that led to RFC4794, which eliminated some of the time-wasting
requirements that served only to further extend the already slow IETF
process.

The right time to preserve a specification in an archived form (such as
an RFC) is when the specification has stabilized. Implementation and
deployment sometimes do not occur for years afterward, at which time the
the original authors and/or editors of the specification might have
moved on to other pursuits. In WGs that do have implementation
requirements, specification that were implemented years ago often sit
around as internet-drafts for extended periods of time, just because no
one is available to restart the standardization process. Often the
drafts expire, and sometimes remain expired for years after they've been
deployed. This creates considerable confusion about whether the drafts
have been abandoned.

There is also the point that Andy has raised, that delaying publication
may also delay deployment.

I believe it is improper for the IETF to be demanding details about
implementations, release cycles, and release dates.  It should be noted 
that it becomes quite difficult to gather this sort of information about 
a draft that has been sitting around for years, especially if that draft 
has has been implemented and deployed piecemeal.


There are also some process issues to discuss.


[Martin] the point of our e-mail is to continue the discussion on the
list. We explicitly say that this is a proposal and that we are open
to comments.


The email in question certainly suggests that the WG chairs have already
made a decision to impose a new requirement, but are allowing two weeks
(during what is a holiday season for many) for "discussion" before they 
announce that there is a consensus in favor of their proposal.  This 
does not seem like an appropriate approach, and imho would be worthy of 
appeal.


The routing area used to have more implementation requirements, but
after extensive discussion in 2006 (discussion lasting more than two
weeks), these requirements were eliminated by RFC4794.  The reason is
clear enough.  Quoting RFC4794:

   "Today, one of the big problems the IETF faces is timeliness.
   Applying additional rules to a certain class of protocols hurts the
   IETF's ability to publish specifications in a timely manner."

I don't think anything has changed since the topic was discussed in
2006.  We should be looking for ways to speed up the process, not
looking for even more ways to slow it down.


[Adrian] To be clear, the WG is allowed to make a decision to do
this. http://datatracker.ietf.org/doc/rfc4794/


Are you referring to the following paragraph:

   Some working groups within the Routing Area have developed
   procedures, based on RFC 1264, to require implementations before
   forwarding a document to the IESG.  This action does not prevent
   those working groups from continuing with these procedures if the
   working group prefers to work this way.  We encourage working groups
   to put measures in place to improve the quality of their output.

I don't see that this gives individual WGs (not to mention WG chairs)
any right to impose arbitrary new rules.  It only allows them to keep
existing rules.  The most it says about allowing the creation of new
rules is:

   that does not prohibit the Routing Area Directors from requiring
   implementation and/or operational experience

though this presumably would also be subject to appeal if it were
applied arbitrarily.


[Martin] The basic motivation for this is simply to avoid
(over)loading the iesg with documents that have no (and could
possibly never have an) implementation.


I don't think the problem of AD workload can be addressed by having a 
single WG add more delay to its process.  Certainly I don't agree that 
the IESG workload problem should be addressed by having the IETF do less 
work.






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

Re: [bess] AD Review of draft-ietf-bess-mvpn-extranet-03

[Eric C Rosen]

On 11/12/2015 2:50 PM, Alvaro Retana (aretana) wrote:

Hi!

I just finished reading this document.


[Eric]  Alvaro, thanks for your review.  I just posted revision -04, 
with a number of edits made in response to your comments.



As mentioned by the WG chairs at the meeting in Yokohama, the technology
in bess can be complex and hard to penetrate for the average (or novice)
reader.  While the target of documents like this one is not always the
average (or novice) reader, it is important that those readers
(including the IESG and other review directorates) are able to at least
understand what's going on.


[Eric] Often, reviewers from various directorates are assigned documents
that they are not qualified to review.  This is certainly a problem, but 
not a problem with the documents.  There is also a problem with certain 
ADs (NOT routing area ADs of course) who don't know nearly as much as 
they think they do.  Well, luckily for them, bidirectional multicast is 
not discussed in this document, as it really seems to freak them out!



Because of the length of the document, it would be nice to include a
"road map" to guide the reader (in general: "Section x talks about X,
Section y covers Y, etc.").  It might be easier to include references to
the specific sections in 1.4 (Overview).


[Eric]  I think the table of contents is as good a road map as we are 
going to get.  Adding additional pointers to the overview doesn't 
provide additional value, and most likely would just introduce errors.


This is a long standards track document, so it is bound to have a lot of
normative language.  On one hand I don't want to go overboard with
explicitly mandating every little step..but at the same time we want to
be clear as to what is "actually required for interoperation or to limit
behavior which has potential for causing harm" [RFC2119].  Due to the
potential of bad configurations resulting in incomplete/illdefined
extranets, I can see why the behavior around RTs would require normative
language.  However, there are some places where the use of rfc2119
keywords may be lacking, not needed or inconsistent.  An example of
inconsistency is this paragraph from Section 7.2.3.1. (When Inter-Site
Shared Trees Are Used):

If VRF-S exports a Source Active A-D route that contains C-S in the
Multicast Source field of its NLRI, and if that VRF also exports a
UMH-eligible route matching C-S, the Source Active A-D route MUST
carry at least one RT in common with the UMH-eligible route.  The RT
must be chosen such that the following condition holds: if VRF-R
contains an extranet C-receiver allowed by policy to receive extranet
traffic from C-S, then VRF-R imports both the UMH-eligible route and
the Source Active A-D route.

.. If the "route MUST carry at least one RT", why isn't the condition to
be met also normative?  I don't want to belabor on this specific case,
it is just an example.


[Eric] I think you are right about this case; I've fixed the text.


However, I would appreciate it if the authors
would scan the document for required or unneeded normative language.  I
pointed at some cases in my comments below.


[Eric] I looked at each of the 200 or so occurrences of "must", 
"should", etc., and made some changes.  I think it's more consistent 
now, but the criteria for when to say "MUST" and when to say "must" have 
never been very clear.



I do have a couple of items that I think are Major (see below) that I
would like to see addressed before starting the IETF Last Call.



Major:

 1. Section 1.3. (Clarification on Use of Route Distinguishers) uses the
word "REQUIREs" in a couple of places.  In a strict manner, the
rfc2119 key words is "REQUIRED".  While I think that the meaning of
using "REQUIREs" should be obvious, please rephrase the text to
strictly use the rfc2119 language.


[Eric]  I changed "this document REQUIREs" to "it is REQUIRED by this
document".  Hopefully, the RFC editor won't ding me for unnecessary use
of the passive voice ;-)


 2. Section 10 (Security Considerations)
  * What is a "VPN security violation"?  It is mentioned in several
places, but it is not explicitly defined.  Please either add a
reference or be clear in what it is.


[Eric] A "VPN security violation" is just any situation in which a
packet gets delivered to a VPN where it isn't supposed to go.  I added a
definition in the terminology section, and also in the Security
Considerations section.


  * Misconfiguration is a significant risk, for example assigning
the wrong RTs to the wrong routes.  I think that risk should be
mentioned.


[Eric] This is generally true of any technology based upon RFC4364.  I
added a sentence about this to the Security Considerations.


Minor:

 1. Section 1.1. (Terminology): "We will sometimes say that a route
"matches" a particular host if the route matches an IP address of
the host."  Given the previous definiti

Re: [bess] Poll for adoption: draft-morin-bess-mvpn-fast-failover

[Eric C Rosen]

I support the adoption of this draft by the WG.


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

Re: [bess] PMSI Tunnel Attribute Flags

[Eric C Rosen]

Jorge,

Sorry about the delay getting back to you; hopefully we can bring this 
document to WGLC relatively sonn.



Although I was still leaning towards a registry per tunnel-type or at
least per SAFI (since it would save the use of a new EC) I think at this
moment it is even more important to close on this as soon as possible to
avoid issues.


Slide 6 of the presentation I gave at the Dallas IETF provides some 
reasons for not setting up a different registry per tunnel-type or SAFI.


My only other comment is that it would seem 'cleaner' to use the most
significant bit to indicate the existence of the EC instead of bit 1. If
would be good to confirm that the rumor about the use of bit 0 is an
existing implementation, in which case I agree it can’t be used.


I did hear the "rumor" from a reliable source ;-)


If that
is the case, it would be good if the relevant people document that
somewhere.


Indeed it would.  But hopefully, once we set up the registry, similar 
undocumented uses of the flag bits will be less likely to happen.


Eric

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

Re: [bess] Comments on draft-ietf-bess-ir

[Eric C Rosen]

Hi Thomas,

Thanks for your review and comments!

From the draft:

"This document does not provide any new protocol elements or 
procedures"


I think we can agree that it does not specify any new protocol elements.

> [Thomas] Sections 3, 4.1.1 and 9, at least, introduce what I think 
can fairly be considered new procedures.


I don't see anything in section 3 or 4.1.1 that I would call "new 
procedures".


However, your point is well-taken about section 9, as RFC6514 does not 
really address the use of timers to achieve "make before break" 
functionality.  On the other hand, RFC 6513 section 7 does specify the 
use of timers when switching a flow from one P-tunnel to another, so the 
use of timers is not a new addition.


When we started implementing ingress replication, we found that it 
wasn't always very clear how to apply the procedures of RFC6514 when 
ingress replication is being used.  The purpose of this draft is to pull 
together into one place all the procedures relevant to ingress 
replication, and to explain clearly how ingress replication is done 
using the procedures of RFC6514.  The focus is on getting it clear 
enough to increase the likelihood of multi-vendor interoperability.  We 
really tried hard to avoid creating any new IR-specific procedures, 
though section 9 may be an exception.


From the draft:

"4.1. Advertised P-tunnels The procedures in this section apply 
when the P-tunnel to be joined has been advertised in an S-PMSI A-D 
route, an Inter-AS I-PMSI A-D route, or an Intra-AS I-PMSI A-D route."


> For sake of clarity and avoid any misinterpretation, can you please 
add ", and the PMSI Tunnel Attribute is of type Ingress Replication"


Well, section 4 is called "How to Join an IR P-tunnel", and the entire 
draft is exclusively about IR P-tunnels.  If you think that is not 
clear, perhaps the sentence above should just say "when the IR P-tunnel 
to be joined has been ..."


From the draft:

"Note that if a set of IR P-tunnels is joined in this manner, the 
"discard from the wrong PE" procedures of [RFC6513] section 9.1.1 cannot 
be applied to that P-tunnel.  Thus duplicate prevention on such IR 
P-tunnels requires the use of either Single Forwarder Selection 
([RFC6513] section 9.1.2) or native PIM procedures ([RFC6513] section 
9.1.3).


[Thomas] I would suggest rewording with "Note that, in the general case, 
..."  and "...unless the tunneling technique relies on an IP transport, 
which may allow the identification of the PE sourcing the traffic".


It is certainly true in theory that one could use an IP encapsulation in 
this way, but in practice it creates a couple of complications:


- I think it presupposes that the IP source address field of the 
tunneled packets contains the same IP address that the ingress PE puts 
in the Global Administrator field of the VRF Route Import EC that it 
attaches to the unicast routes that it distributes.


- All the egress PEs need to implement this IP address check in the data 
plane forwarding path.


While using the IP encapsulation in this way is a possible option, it 
has never seemed like a very attractive option, and as far as I know, no 
one has implemented it.


To avoid the need for an option like this, I always recommend that if 
one wants to use IR by default, one should advertise the IR P-tunnels in 
a (C-*,C-*) S-PMSI A-D route rather than in an Intra-AS I-PMSI A-D 
route.  One can still use IP tunnels if one wants, but the "discard from 
the wrong PE" procedures would be based on the MPLS label that is 
carried by the IP payload.


Another problem with using the IP header to apply the "discard from the 
wrong PE" procedure is that it will not easily generalize to the case of 
extranet.  (Still another problem would be that it is just one more 
unnecessary option.)


I could add some text explaining this, and explaining why it is not 
recommended to use the IP header to apply the "discard from the wrong 
PE" procedure.


Now, regarding the use of timers when switching UMH ...

[Thomas] I understand -- even if that is a bit implicit -- that the NLRI 
for the Leaf A-D route to the old UMH is the same as the NLRI for the 
Leaf A-D route to the new UMH.


Correct.

[Thomas] But I don't in fact understand why this has to be the case...

Leaf A-D routes are originated in response to I/S-PMSI A-D routes, and 
the rules for creating the NLRI of a Leaf A-D route, as specified in 
RFC6514, are independent of the tunnel type.


[Thomas] One has to ignore the procedures to build a Leaf A-D route of 
RFC6514 since this document specifies new ones for IR in section 4.1.1


I don't understand why you say that.  The 4.1.1 rules for generating the 
NLRI of a Leaf A-D route follow the RFC6514 procedures.


[Thomas] section 4.1.1 says that the Key field of the Leaf A-D route 
contains the "tunnel identifier" defined in section 3


Yes; the tunnel identifier defined in section 3 is the NLRI of the 
corresponding I/S-PMSI A-D route

Re: [bess] comment on draft-ietf-bess-ir

[Eric C Rosen]

Lucy,

1. Constraining the distribution of Leaf A-D routes.

If you look at sections 9.2.3.2.1 and 9.2.3.4.1 of RFC 6514, you'll see 
that there are some rules that enable you to avoid sending a Leaf A-D 
route on an EBGP session unless a corresponding I/S-PMSI A-D route was 
received over that session.  There are similar rules in RFC 6514 
governing the distribution of C-multicast routes.  These rules are 
intended to prevent the Leaf A-D routes and C-multicast routes from 
being distributed more widely than necessary.  Whether these rules 
always work is questionable; they tend to have hidden assumptions about 
the deployment.


But if you want to investigate ways to optimize the distribution of the 
Leaf A-D routes, that's a good place to start.


One might try the following rule.  If R1 receives a Leaf A-D route, and 
if R1 is not identified in the route's RT, and if the Leaf A-D route has 
a route key that is the NLRI of an S-PMSI A-D route that R1 has 
installed, then only distribute the Leaf A-D route on a BGP session that 
leads to the BGP speaker that is the next hop of the S-PMSI A-D route. 
Whether this rule actually works in various deployment scenarios would 
require further investigation.


[Lucy] To suppress unnecessary redistribution, a P-tunnel BGP node 
tracks P-tunnel neighbor state. A BGP next hop is one of P-tunnel 
downstream neighbor, upstream neighbor, and N/A. The policy is, if the 
BGP next hop of the UPDATE of Leaf A-D route is the downstream neighbor, 
redistribution the route; if not, no redistribution.


I don't understand this proposal; I don't see how you can tell by 
examining the next hop of the Leaf A-D route whether you need to 
redistribute the route.  A rule based on the next hop of the 
corresponding I/S-PMSI A-D route sounds more promising.


Another approach would be to use Constrained Route Distribution.  This 
would ensure that the Leaf A-D route reaches its target, and would 
prevent the route from traveling over "unnecessary" alternate paths.  In 
certain deployment scenarios, ORF is also available as a way to prevent 
routes from being distributed unnecessarily.  Both these methods are 
forms of RT-based filtering, and both are independent of MVPN.


Of course, one also has to worry about creating a robustness problem if 
route distribution is constrained so that routes follow only one path.


Since the topic of this thread is "comment on draft-ietf-bess-ir", and 
since that draft is in WGLC, I'll just point out again that this issue 
is not specific to ingress replication.


[Lucy] IMO: this mechanism for membership announcement raises a BIG 
concern on the scalability and performance. Why is it not a concern for you?


I wouldn't say it's not a concern, but it's important not to focus 
exclusively on the worst case.  Typical deployment scenarios don't come 
close to the worst case, and there are various tools and filtering 
policies that can be used to constrain the distribution of updates based 
on the RTs.


2. Changing your parent on an IR tree

I think we have a disconnect here, having to do with the layering 
between the MVPN application and BGP.


MVPN can create a route and give it to BGP.  MVPN can set and modify 
attributes of the route.  MVPN can withdraw the route.  But the 
distribution of the route is controlled by BGP.


MVPN cannot tell BGP "send an update for NLRI X with attribute A1 on BGP 
session S1, but send an update for NLRI X with attribute A2 on BGP 
session S2".  MVPN cannot tell BGP "send an update for NLRI X on session 
S1 but send a withdraw for NLRI X on session S2."  And MVPN cannot 
control the timing of BGP's route distribution procedures.


In short, MVPN does not create and send the update messages.

[Lucy] To change the parent, a child sends out the UPDATE of Leaf A-D 
route with new parent address in RT.


MVPN can tell BGP to change the RT and the PMSI Tunnel attribute on a 
given Leaf A-D route.  Suppose MVPN replaces the RT so that the RT now 
identifies the new parent rather than the old one.


If Constrained Route Distribution is being used, this will cause an 
explicit withdraw to be sent to the old parent.  There is no way for the 
MVPN process in the child node to control the timing of this BGP message.


If Constrained Route Distribution is not being used, changing the RT 
will cause BGP to send a new update to the old parent as well as to the 
new parent.  The old parent will treat this as a replacement route, and 
will consider the old route to have been (implicitly) withdrawn.  This 
behavior is mandated by section 3.1 of RFC4271.  Since the old parent is 
not identified in the RT, the action it must take is the action 
specified for the withdrawal of a Leaf A-D route.


Now suppose MVPN doesn't simply replace the RT on the Leaf A-D route, 
but adds a second RT, identifying the new parent.  MVPN would also have 
to replace the PMSI Tunnel attribute, to specify a new label for the new 
parent to use.  The old pa

Re: [bess] comment on draft-ietf-bess-ir

[Eric C Rosen]

Hi Lucy,

[Lucy] A parent for a mcast group can not consider the route to have
been withdrawn and replaced because of RT is not indicate the parent.
The parent must check if the leaf A-D for the mcast is from its child.
There is a case, a parent for a mcast group receives an leaf A-D of the
group from a downstream node whose parent is not this parent. In this
case, the parent must not treat it as implicit withdraw.

I believe your suggestion is in violation of the BGP specification.

[Lucy] Leaf A-D is for downstream to inform upstream parent, shouldn't
be the same for segmented P-tunnels (IR) or non-segmented P-tunnels? If
not, please explain.

When non-segmented ingress replication is used, the ingress PE needs to 
see the Leaf A-D routes from all the egress PEs.  (The ingress PE is the 
upstream parent in this case, even if the ingress PE is not a BGP peer 
of the egress PEs.)  This means that the RT on the Leaf A-D routes needs 
to identify the ingress PE.  However, the Leaf A-D routes may need to 
travel over multiple BGP sessions before they reach the ingress PE. 
Some of these BGP sessions may be IBGP sessions, some may be EBGP 
sessions. It's rather important that the route not get discarded before 
it reaches the ingress PE, even though it passes through multiple BGP 
speakers.  If one wants to constrain the distribution of the routes, one 
still has to guarantee that the routes will reach their targets.


Now let's turn to the issue you raised with regard to section 6.2 of the 
draft -- when is it is safe for an intermediate node to assign the same 
label to two tunnels?


Consider two flows that originate from the same ingress PE (and same 
ingress VRF).  Call these flows K1 and K2.  We'll call the ingress PE 
"I-PE".


Let's consider a single egress PE, "E-PE", and let's suppose that we are 
using segmented ingress replication.


The following diagram depicts a possible way that the Leaf A-D routes 
may flow from E-PE to I-PE (thanks, Jeffrey, for the diagram):



   K1: L4 <   K1: L2 <
  <---- N2 -  <-
  K1&K2: L6 /   \K1&K2: L1
I-PE - N1   N3 --- E-PE
\   /
 -- N4 -
   K2: L5 <   K2: L3 <
In words:

- E-PE sends Leaf(K1) to N3 with label L1.

- E-PE sends Leaf(K2) to N3 with label L1. (Flows K1 and K2 have same 
ingress PE and same parent node, so can be assigned the same label.)


- N3 sends Leaf(K1) to N2 with label L2.

- N3 sends Leaf(K2) to N4 with label L3.  (The choice of N4 rather than 
N2 as parent might be due to ECMP.)


- N2 sends Leaf(K1) to N1, with label L4.

- N4 sends Leaf(K2) to N1, with label L5.

Now N1 has to send both Leaf(K1) and Leaf(K2) to I-PE.  Per section 6.2, 
it will assign a different label in each Leaf A-D route, since K1 and K2 
have different children.  But let's suppose for now we follow your 
suggestion, and allow N1 to assign the same label (L6) in both Leaf A-D 
routes.


Let's look at the resulting data flow.  Suppose I-PE sends a K1 packet 
to N1, with label L6.  N1 will have to send this packet to N2 with label 
L4, and to N4 with label L6.


N2 will send the packet to N3 with label L2, and N4 will send the packet 
to N3 with label L3.


N3 will send both packets to E-PE with label L1.

E-PE will then have received two copies of the K1 packet, and both 
copies carry label L1.  Therefore E-PE has no way of knowing that it 
needs to discard one copy.  The result is that E-PE will forward 
duplicate traffic out its VRF interface.


On the other hand, if we follow the procedure specifies in section 6.2, 
N1 will not forward K1 packets to N4, and E-PE will not forward 
duplicate traffic.



Eric

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

Re: [bess] comment on draft-ietf-bess-ir

[Eric C Rosen]

Think more about using BGP mechanism to achieve the make before
break at a child.

The child can do it without parent cooperation. When a child changes
the parent for a Leaf A-D route, it first sends out the route with
the new parent address encoded in RT; when old parent receives the
route, it does not need to take any action on it;


Note that if Constrained Route Distribution (RFC4684) is running, the
old parent will see an explicit withdraw when the RT is changed.

Even if Constrained Route Distribution is not running, once the 
attributes of a route are modified, the route is considered to have been 
implicitly withdrawn, and the route with the new attributes is 
considered to be a replacement route.  (See section 3.1 of RFC 4271.)


So once the RT no longer identifies the old parent, the old parent must
consider the route to have been withdrawn and replaced.  Since the 
replacement route does not identify the old parent, it does not impact 
the old parent's multicast state.



The old parent updates multicast state and new parent do nothing when
receiving the withdraw leaf A-D route.


As indicated above, the old parent will have seen an implicit or
explicit withdraw as soon as the RT was changed.

Further, if the new parent sees a withdraw, it cannot decide to maintain
the route anyway, as this would violate BGP semantics.


Regarding suppress the non-parent node to re-distribute the leaf A-D
route, if we take RR as an exception case and require RR to
re-distribute leaf A-D; IMO, it MAY work too.


There are a variety of deployment scenarios in which a received Leaf A-D
route must be redistributed, even by a router that is not identified in
the route's RT and that is not an RR.  For instance, this will be
necessary if non-segmented P-tunnels are being used, but the routes need
to be distributed through multiple EBGP sessions in order to travel from
egress to ingress.  The only time it is safe to not redistribute a Leaf
A-D route is when one knows that the route has already reached its
target, or that it will reach its target through some other path.  There
is no simple set of rules to determine this.  If you want to constrain
the distribution of the Leaf A-D routes, you either need to use
Constrained Route Distribution, or to set up policies that are specific
to a particular deployment.


I suggest to relax the second rule in Section 6.2, i.e. no need to
require N to have exact same set of downstream neighbors in two
tunnels. For example, if K1 has downstream neighbors n1~n10 and K2
has downstream neighbors n2-n10. N node can assign a single label for
the upstream for both tunnels. As a result, the packet with this
label from upstream node will be sent to downstream neighbors n1-n10;
n1 accepts the packets that associate with K1 and discard the packets
that associate with K2. N2-N10 will accept the packets that associate
with either K1 or K2.


As Jeffrey has explained, there is no way in this scenario for N1 to 
determine that a particular packet should be associated with K1 rather 
than with K2.  Suppose the parent node receives packet P1 on tunnel K1 
and packet P2 on tunnel K2.  Since  those packets carry the same label, 
the parent node doesn't know which packet has arrived on which tunnel. 
The parent node will just do a label swap and send the packets along to 
N1-N10.  When N1 gets packets P1 and P2, they both have the same label, 
and therefore N1 has no way to determine that one of the two packets is 
on tunnel K2 and should be discarded.




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

Re: [bess] WG Last Call for Ingress Replication Tunnels in Multicast VPN (draft-ietf-bess-ir)

[Eric C Rosen]

On 9/18/2015 12:14 PM, Martin Vigoureux wrote:

*If* you are listed as a document author or contributor of
draft-ietf-bess-ir-01 please respond to this email and indicate whether
or not you are aware of any relevant IPR.


As co-author, I am unaware of any IPR relevant to this document.

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

Re: [bess] comment on draft-ietf-bess-ir

[Eric C Rosen]

Hi Lucy,

It is certainly true that the BGP route distribution mechanism is not 
optimal for multicast signaling.  The advantages and disadvantages of 
using BGP for multicast signaling were discussed extensively in the WG 
when RFCs 6513 and 6514 were being written.  But the entire mechanism is 
built around the standard BGP route distribution procedures, and one has 
to be very cautious about making changes.


> [Lucy] What you say is that, in BGP distribution mechanism, BGP
> (child here) chooses the bestpath (i.e. parent here) for a particular
> NLRI, then distributes the NLRI to all BGP peers (including the
> parent node).

Right.  But ...

One thing you have to remember is that the child might not have a BGP 
session directly with the parent.  For instance, one can have a 
deployment where ingress replication is used in a non-segmented manner, 
such that the ingress PE makes a copy for each egress PE.  In this case, 
when an egress PE originates a Leaf A-D route, the RT will identify the 
ingress PE.  But ingress and egress PEs generally don't have BGP 
sessions to each other.  In many deployments, the ingress and egress PEs 
are clients of a route reflector; the egress PE sends the Leaf A-D route 
to the RR, and the RR redistributes it to the ingress PE.  In other 
deployments, the Leaf A-D route from a given egress PE may have to 
travel over several BGP sessions before it reaches the ingress PE.


> Since the NLRI is only stored by the parent node and may be removed
> by old parent node, such distribution mechanism has no advance for
> such purpose and causes a scaling issue. To reduce the distribution
> symptom, it should explicitly require that, if a node receiving a
> leaf A-D route is not the parent node including old parent node, the
> node should not redistribute the leaf A-D route; in other words, only
> the parent node is allowed to readvertise the leaf A-D route.

This would break the deployment scenarios described above.

> One question, if one ASBR or ABR node that is the parent for a set of
> downstream neighbors fails, what is the procedure for the downstream
> neighbors to select a new parent?

If a node fails, its BGP sessions go down, and the routes it originated 
are considered to have been withdrawn.  If parent and child are 
separated by a RR, failure of the parent will cause its session to the 
RR to go down.  The RR will then send withdraws to the child for all of 
the routes that were originated by the parent and redistributed to the 
child.


If there are two potential parents for a given flow, each will have 
originated an S-PMSI A-D route with an NLRI identifying the flow.  One 
of these S-PMSI A-D routes is the bestpath for that NLRI, and the next 
hop (or P2MP Inter-Area Segmented Next Hop Extended Community) of that 
route determines the parent that is chosen by a given child.  If that 
parent fails, the route from the other potential parent becomes the best 
path, and the child will then rehome itself by changing the RT on the 
Leaf A-D route.


> If a child fails, the parent should
> update multicast state as if the child is withdrawn.

If a child fails, its Leaf A-D route appears to the parent to have been 
withdrawn, and this causes the change in multicast state.


Note that the procedures for dealing with withdrawn S-PMSI or Leaf A-D 
routes are not specific to Ingress Replication.


Eric

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

Re: [bess] comment on draft-ietf-bess-ir

[Eric C Rosen]

On 9/2/2015 9:47 AM, Lucy yong wrote:

Let me clarify, I suggest to relax the second rule in Section 6.2, i.e.
no need to require N to have exact same set of downstream neighbors in
two tunnels. For example, if K1 has downstream neighbors n1~n10 and K2
has downstream neighbors n2-n10. N node can assign a single label for
the upstream for both tunnels. As a result, the packet with this label
from upstream node will be sent to downstream neighbors n1-n10; n1
accepts the packets that associate with K1 and discard the packets that
associate with K2. N2-N10 will accept the packets that associate with
either K1 or K2.


Lucy,

The ingress replication procedures are designed so that the forwarding 
is entirely MPLS-based, and the intermediate nodes are not required to 
examine the payload or to maintain any VPN-specific flow states.


In the scenario you describe above, the K1 packets from N and the K2 
packets from N will arrive at N1 with the same top label.  Hence N1 will 
forward the K1 packets just as if they were K2 packets, causing an 
unintended merging of the two tunnels.


Eric


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

Re: [bess] comment on draft-ietf-bess-ir

[Eric C Rosen]

However, a child can use one leaf A-D with the new
parent with a new label and later send withdraw leaf A-D to the old
parent


Lucy,

Note that "both" of Leaf A-D routes you mention above have the same NLRI 
and the same next hop.  Thus to BGP, these are really the same route.


What you are suggesting is:

- Send a route with a particular set of attributes to one neighbor;

- Send the same route with a different set of attributes to another 
neighbor;


- Then withdraw the route from the first neighbor without withdrawing it 
from the second.


This sort of functionality is not really supported by the BGP 
distribution mechanisms.   The MVPN mechanisms generally assume the 
typical BGP distribution mechanisms, where BGP chooses the bestpath for 
a particular NLRI, and then distributes it.


Eric


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

Re: [bess] Brian Haberman's No Objection on draft-ietf-bess-mvpn-global-table-mcast-02: (with COMMENT)

[Eric C Rosen]

Brian,


I support the publication of this document, but I have one (non-blocking)
comment...


Thanks!


I do not see any forwarding plane discussions in this document
and I wonder if there was discussion about impacts on multicast
forwarding.  With the removal of the VPN-related checks, is there a
possibility of loops in the forwarding of multicast data based on the GTM
information?  What about implications for RPF checks?


I don't think there are any issues here.  Is there something specific 
that concerns you?


As in MVPN, each egress node still has to select an ingress node for a 
given flow, and has to discard traffic that is not from that ingress 
node.  This requires that the egress be able to infer the identity of 
the ingress from the data packet's encapsulation.  But the relevant 
mechanisms are not impacted by the fact that there is no VPN-specific 
context.


Similarly, the procedures for setting up the multicast tunnels are not 
impacted by the lack of VPN-specific context; if the global table 
unicast routing is loop-free, the resulting multicast trees should be 
loop-free as well.


Eric

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

Re: [bess] [Idr] I-D Action: draft-rosen-idr-tunnel-encaps-03.txt

[Eric C Rosen]

On 8/6/2015 9:50 PM, Xuxiaohu wrote:

Hi co-authors,

Thanks for this update which looks much better.

I still have three questions as follows:

1. This draft assumes that NVGRE adopts the same approach to carrying
IP traffic as VXLAN. However, NVGRE has a protocol field and
therefore it could directly carry IP traffic w/o adding the fake
Ethernet header between the IP payload and the GRE header (see
https://www.ietf.org/mail-archive/web/nvo3/current/msg01520.html and
http://tools.ietf.org/html/draft-yong-l3vpn-nvgre-vxlan-encap-03#page-3.)
Hence, how about considering the simpler layer3 overlay for NVGRE?


Our reference for the NVGRE encapsulation was 
draft-sridharan-virtualization-nvgre-08.txt, which is now on the RFC 
Editor's queue for publication as an Informational draft in the 
"Independent Submissions" stream.  That RFC-to-be only discusses the use 
of NVGRE to carry ethernet frames.  Draft-yong-l3vpn-nvgre-vxlan-encap 
discusses the use of NVGRE to carry IP packets (analogous to VXLAN-GPE), 
but that draft is expired.


I have no objection to incorporating the idea of draft-yong into the 
tunnel-encaps draft, if that's what the relevant WGs support, but it 
would be nice to see some further discussion first.




2. It said "...Note that if none of the TLVs specifies the MPLS
tunnel type, a Label Switched Path SHOULD NOT be used." IMO, since
the LSP is signaled by label distribution protocols such as LDP,
RSVP-TE or L-BGP, why is it still necessary to specify the tunnel
encapsulation attribute to indicate whether or not an LSP should be
used.


If the tunnel encapsulation attribute is present, identifying one or 
more tunnel types, the semantics are that one should try to send packets 
through one of the identified tunnel types (if possible).  So if MPLS is 
not specified as one of the tunnel types, the use of an MPLS LSP for 
transport would have to be avoided.  The presence of a TLV identifying 
an MPLS tunnel type would indicate that the use of an MPLS transport 
tunnel is one of the permissible options for transmitting the packets.



3. Since this draft has mentioned the encapsulation of MPLS over
VXLAN/NVGRE, would you please give any clue to the scenario of this
special encapsulation?


Any IP-based overlay should be able to pass an MPLS packet with an 
arbitrary label stack.


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

[bess] PMSI Tunnel Attribute Flags

[Eric C Rosen]

Thomas and I have just posted draft-ietf-bess-pta-flags-01.  This rev 
introduces a new proposal for making the PMSI Tunnel attribute's Flags 
Field extensible.  It defines a new opaque extended community that can 
be used to carry up to 48 new flags, and uses one of the bits in the 
existing Flags Field to mean that additional flags are set in the 
extended community.  The draft also establishes an IANA registry for the 
existing Flags Field and for the flags in the extended community.


The draft registers two bits in the existing Flags Field;

- Bit 7 (least significant): the LIR bit defined in RFC6514

- Bit 1: Extension bit.  If this bit is set, there are additional flags 
in the new extended community.


Although not mentioned in the draft, bits 3-6 are given defined uses in 
draft-rabadan-bess-evpn-optimized-ir. 
Draft-dolganow-bess-mvpn-expl-track defines another bit, LIR-pF, for 
which we will likely request Bit 2.  I have heard a rumor that Bit 0 
(most significant) is also in use, though not documented in an 
internet-draft.  So all 8 bits are now used.  If the WG agrees to 
advance draft-ietf-bess, additional flags would have to come from the 
new opaque extended community.


This proposal seems like a good way to preserve the existing uses of the 
flags field, to discourage "squatting", and to allow additional flags to 
be defined.


The proposed registration policy for both the existing flags field and 
for flags in the new extended community is "Standards Action", which 
implies the possibilty of "early allocation".


Comments?

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

Re: [bess] [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/20/2015)

[Eric C Rosen]

[Eric] I don't think the payload type can necessarily be inferred
from the AFI/SAFI of the UPDATE that is carrying the Tunnel
Encapsulation attribute.  Consider, for instance, a case where the
next hop is not of the same address family as the NLRI, but the
route to the next hop is the route carrying the Tunnel
Encapsulation attribute.



[Xiaohu] It seems that the example that you had mentioned is the
usage of the Tunnel Encapsulation attribute e as described in
RFC5512, rather than the usage of the Tunnel Encapsulation attribute
as proposed by this draft:)


No; see section 5 ("Recursive Next Hop Resolution") of the new draft.

I think there are other examples where one might not be able to infer 
the type of the payload from the AFI/SAFI of the route.  Suppose you use 
BGP as your only routing algorithm, and you use only the unlabeled 
address families (AFI/SAFI = 1/1 or 2/1).  But you use LDP (or SDN or 
something else) to assign labels to prefixes.  In this case, your data 
traffic might be MPLS, but there is no use of the labeled address 
families (AFI/SAFI = 1/4, 2/4, 1/128, or 2/128).  If you use the Tunnel 
Encapsulation attribute to specify a GRE tunnel for some route, you 
could end up having to do an MPLS-in-GRE encapsulation.


I'm not sure whether there is a real use case for this, but I'm not also 
not sure that we want to rule it out.


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

Re: [bess] [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/20/2015)

[Eric C Rosen]

On 7/24/2015 4:40 AM, Xuxiaohu wrote:

Now it seems that the above rationale has been shaken by this draft.


The argument in favor of the Encapsulation-SAFI doesn't seem to have
been as persuasive to everyone else as it was to the authors of RFC 5512 ;-)


Futhermore, since it allows to attach BGP Encap attributes to routes
now, the BGP encapsulation extended community can now be safely
replaced by BGP Encap attribute. Therefore, I wonder whether RFC5512
would be obsoleted by this draft in the end.


Quite a few people have suggested that RFC5512 should be obsoleted by
the tunnel encaps draft; this is worth considering.

However, I think we need to maintain compatibility with the parts of
RFC5512 that have actually been implemented, such as the encapsulation EC.


Since BGP encapsulation attributes are now attached to routes, the
AFI/SAFI of the NLRI is already capable of indicating the payload
type of the advertised tunnel protocol.


I don't think the payload type can necessarily be inferred from the
AFI/SAFI of the UPDATE that is carrying the Tunnel Encapsulation
attribute.  Consider, for instance, a case where the next hop is not of
the same address family as the NLRI, but the route to the next hop is
the route carrying the Tunnel Encapsulation attribute.


it seems unnecessary to allocate two additional type codes for
MPLS-in-UDP and IP-in-UDP.


I think I could argue this point either way:

- On the one hand ... When you are about to sending a particular payload 
packet through a tunnel, you know whether the packet is MPLS or IP, so 
you know enough to form the encapsulation correctly.


- On the other hand ... if you want the control plane to form the 
rewrite string in advance, you might want to form a different rewrite 
string for MPLS-in-GRE than for IP-in-GRE.


I would be good if we had some general rules for when it is good to 
define a new tunnel type and when it is good to reuse an existing tunnel 
type.  Of course, we still need to maintain compatibility with the 
tunnel types that are already defined.


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

Re: [bess] [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/20/2015)

[Eric C Rosen]

* to allow multicast support in the context of RFC6514/6513, RFC7117,
and RFC7432 with a consistent way of advertising the encapsulations,I
think that  draft-rosen-idr-tunnel-encaps-00 section 2.4 should also
consider as a "labelled address family" an AFI/SAFI that may be
associated to a PMSI Tunnel attribute, in which case the "embedded
label" is the Label in the PMSI Tunnel Attribute

* consistently with the above,  1/5 and 25/8 should also be added as
authorized families in section 3


In the particular case where (a) the PMSI Tunnel attribute specifies 
"Ingress Replication", and (b) the PMSI Tunnel attribute carries an MPLS 
label, then I think it might well make sense to include a Tunnel 
Encapsulation attribute.  This would allow one to use an 
MPLS-in-something-else encapsulation to do ingress replication.


In other cases, I don't really know what it would mean to have both a 
PMSI Tunnel attribute and a Tunnel Encapsulation attribute on the same 
route.  Suppose the PMSI Tunnel attribute specifies an mLDP-created P2MP 
LSP, and the Tunnel Encapsulation attribute specifies a VXLAN tunnel. 
What would that mean?


Another issue is the following.  In MVPN the transmitter specifies the 
tunnel type, but the Tunnel Encapsulation attribute is most useful in 
scenarios where the receiver needs to specify the tunnel type.  (Ingress 
replication is an exception, since it requires both a multipoint tunnel 
and a set of unicast tunnels, as is discussed in draft-ietf-bess-ir.  So 
in that particular case, it makes sense for the transmitter to specify 
the former and the receivers to specify the latter.)


It's also worth noting that except for ingress replication,  a label is 
specified in the PMSI Tunnel attribute only if traffic from multiple 
VPNs is going to share the same multicast tunnel; this is not really 
analogous to the label that is embedded in the case of SAFI 4 ("Labeled 
IP Unicast") or SAFI 128 ("Labeled VPN-IP unicast").




* draft-ietf-bess-evpn-overlay currently relies on the Tunnel Encap
Extended Community to advertise the use of MPLS-over-GRE or VXLAN or
NVGRE, and section 5.1.3 of that draft specifies that the VNI to use is
the value in the Label field of the route -- this is I believe /nearly/
inline with draft-rosen-idr-tunnel-encaps, but the devil is in the
details:   if I read correctly draft-rosen-idr-tunnel-encaps-01 Section
7.2, the behavior consisting in using the embedded label as the VNI
requires advertising a BGP Tunnel Encap  Attribute with an Embedded
Label Handling Sub-TLV with value 2, or not advertising a BGP Tunnel
Encap at all (nor using the Tunnel Encapsulation ExtendedCommunity which
is made semantically equivalent by section 6) ---  it thus seems to me
that one of the two drafts needs something to allow proper compatibility


Right now the Tunnel Encaps draft specifies that omitting the Embedded 
Label Handling Sub-TLV is equivalent to including an Embedded Label 
Handling Sub-TLV with value 1.  The simplest fix would be to change this 
so that omitting the Sub-TLV is equivalent to including a Sub-TLV with 
value 2.  Or would this introduce an incompatibility with some other 
EVPN draft? ;-)



With a lesser priority, I have a few other comments as well:

* I think the intent of the MPLS codepoint 10 for tunnel type, as
defined in draft-ietf-bess-evpn-overlay, intends to indicate the ability
to receive plain MPLS in a context where other encaps are advertised (if
you advertise only one non-MPLS encap, it means you support this encap
but not MPLS) -- this I think would be nice to capture in
draft-rosen-idr-tunnel-encaps


I think that makes sense.


* about the Remote Endpoint sub-TLV: why allow that an AF of 0 means
"use next-hop address", but still require the presence of the TLV ?  it
seems that its absence could conveniently be interpreted as "use
next-hop address", like what's done for the Tunnel Encap EC in section 6


Some folks have expressed the opinion that the BGP procedures for 
handling errors in this attribute will be simplified if the Remote 
Endpoint Sub-TLV is always required to be present.  I don't have a 
strong opinion about that myself.




* section 6 should say that, associated to a labelled address family,
the Tunnel Encap EC of value GRE (2) means the same as MPLS-in-GRE
(value 11) (like section 2.2.5 does for the attribute)


Makes sense.



And my second head, the one trying to fill my BESS co-chair hat, can't
help adding that addressing some of the above will require keeping the
BESS working group involved all along the life of this draft.


No problem.

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

Re: [bess] RtgDir review: draft-ietf-bess-mvpn-bidir-03.txt

[Eric C Rosen]

Ben,

Thanks for your review and comments.

I have incorporated your corrections into the XML, and they will be 
included in the -04 revision.


Eric


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

[bess] draft-rosen-bess-pta-flags

[Eric C Rosen]

The PMSI Tunnel attribute defined in RFC6514 contains a "flags" octet. 
RFC 6514 only defines a single one-bit flag, "Leaf Information 
Required".  However, the next revision of 
draft-dolganow-l3vpn-mvpn-expl-track is probably going to specify the 
use of a second bit from the flags octet.  And 
draft-rabadan-bess-evpn-optimized-ir specifies the use of 4 bits from 
the flags octet.  Since this particular octet only contains eight bits, 
it is probably a good idea to have an IANA registry for it, to minimize 
the chance that two different drafts will try to allocate the same bit 
for different purposes.


Thus the trivial draft draft-rosen-bess-pta-flags, which, if progressed 
to RFC, would establish this registry.


Given the small number of possible allocations, the proposed 
registration procedure is "Standards Action", which automatically 
includes the possibility of "early allocation".


It might also be worth thinking about whether the interpretation of the 
flags octet should be dependent on the type of route to which the PMSI 
Tunnel attribute is attached.  However, that complication is not 
currently suggested in the draft.


Comments?

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

Re: [bess] Poll for adoption: draft-rosen-l3vpn-ir

[Eric C Rosen]

On 12/4/2014 11:29 AM, Thomas Morin wrote:


If you are listed as a document author or contributor please respond
to this email and indicate whether or not you are aware of any
relevant IPR.



I am not aware of any such IPR.

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

Re: [bess] [Technical Errata Reported] RFC4659 (4087) / IPv6 mandatory for an RFC4364 implem ?

[Eric C Rosen]

IETF isn't the protocol police.


Agreed.  But the IPv6 police seem a bit overenthusiastic these days.
("These days" meaning for the last 20 years or so.)


Metadata in this case is to help implementers find the links between
documents when they build upon one another and make the act of
implementing IETF standards mildly more user-friendly. 4659 has 4364
as a normative reference, I am simply suggesting that there should be
a forward reference to 4659 from 4364 to identify that the protocol
was later extended with new features that they should consider
implementing.


This just isn't the meaning of "Updates".


I think that the nuanced inference that you are making as to why
"updates" is used or not used is going to be lost on all but those
deeply involved in IETF standards minutiae.


Agreed.  Of course, the same could be said of all the meta-data, 
including the classification as "standards track", "experimental", etc. 
 Nevertheless, the terms have been given a certain meaning with regard 
to IETF process, and we can't just decide that we're going to use them 
differently.


The only real impact of accepting this erratum would be to give fuel to 
non-productive arguments like:


- "Hey, your alleged implementation of 4364 isn't compliant to 4364, 
because it doesn't implement 4659."


- "But it was compliant last week!"

- "No, it hasn't been compliant since BCP177 was published".

- "Then BCP177 should have updated 4364"

So I would suggest rejecting this erratum on the grounds that any 
positive effect is more than outweighed by the time wasted having 
non-productive arguments about it.





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

[bess] Comments on draft-dolganow-l3vpn-mvpn-expl-track-00

[Eric C Rosen]

I have a few comments on draft-dolganow-l3vpn-mvpn-expl-track-00.txt.

The draft points out a few issues with regard to the use of a PMSI Tunnel
attribute (PTA) whose "tunnel type" is set to "no tunnel information". 

The first issue is the following.

RFC6625 gives a detailed set of procedures for figuring out which S-PMSI A-D
route specifies the P-tunnel to be used for sending or receiving a
particular multicast C-flow.  However, RFC6625 neglects to point out that if
the PTA of particular S-PMSI A-D route specifies "no tunnel information",
then the that S-PMSI A-D route should be ignored when those procedures are
applied.

The draft is correct to point this out, though I'm not sure any implementer
would actually try to send or receive packets on a P-tunnel whose type is
"no tunnel information".  This particular issue might be better addressed
through an erratum to RFC6625.

But a couple of more difficult issues are raised as well.

I think the original intention of using "no tunnel information" is that it
would be used with (C-S,C-G) S-PMSI A-D routes.  Thus there is no clear
statement in any of the RFCs about how to use it with an S-PMSI A-D route
that has one or more wildcards in its NLRI.

It's clear that a egress node, say PE1, interested in (C-S,C-G), needs to
send a Leaf A-D route in response to a "no tunnel info" S-PMSI A-D route
with (C-S, C-G) in its NLRI, as long as the S-PMSI A-D route is originated
by the ingress node that PE1 has selected for (C-S,C-G).

What's not clear is what to do in the following case:

- PE1 is an egress node interested in (C-S,C-G)

- PE1 has chosen PE2 as the ingress node for (C-S,C-G)

- PE1 has installed a (C-S,C-G) S-PMSI A-D route from PE2, where the route
  specifies a tunnel to join

- PE1 has installed an S-PMSI A-D route from PE2 with a "less specific" NLRI
  (e.g., (C-*,C-G) or (C-S,C-*) or (C-*,C-*)), and that specifies "no tunnel
  information" with LIR set.

Does PE1 have to respond to PE2's less specific S-PMSI A-D route with a Leaf
A-D route in this case?  The RFCs don't really say.  I can imagine several
possible answers:

- yes

- no

- it depends on whether the more specific route had LIR set

- it depends on whether the less specific route covers more than one more
  specific route

- it depends on something else

The desired behavior when mixing "no tunnel information" with wildcards was
not thought out when RFC6625 was written.

Another issue has to do with the way the P-tunnel segmentation procedures
are applied to an S-PMSI A-D route whose PTA specifies "no tunnel
information."

The draft doesn't actually mention P-tunnel segmentation, but it does
distinguish between "intra-AS" and "inter-AS" procedures.  It leaves
inter-AS "for further study", so I surmise that the authors think there are
some issues when S-PMSI A-D routes with "no tunnel information" have to
travel inter-AS.  I surmise further that the issues have to do with the
application of the P-tunnel segmentation procedures to S-PMSI A-D routes
with "no tunnel information".

This surmise could be wrong, because (a) segmentation doesn't have to be
applied at inter-AS boundaries, and (b) segmentation can be applied within
within a single AS (see "seamless multicast").  But I think there are some
issues having to do with processing these routes at "segmentation
boundaries", whether or not those boundaries are also AS boundaries.

Generally, when a P-tunnel is segmented, the segments do not all have to be
the same tunnel type.  However, we could decide that when segmenting a "no
tunnel information" P-tunnel, the segments should all be "no tunnel
information" segments, with each segment having LIR set.

(Yes, I know it doesn't make literal sense to talk of segmenting a "no
tunnel information" tunnel, this is just shorthand for applying the P-tunnel
segmentation procedures to S-PMSI A-D routes whose PTAs specify "no tunnel
information".)

Or we could decide that whether a "no tunnel information" PTA should pass
through a segmentation boundary is a matter of policy.

But note that when the ingress PE and egress PEs are separated by
segmenation boundaries, there are no procedures that allow the ingress PE to
track the egress PEs.  The procedures are really designed only to enable the
ingress node of a "segmentation domain" to track the egress nodes of that
domain.  That is all that is needed if the purpose of explicit tracking is
to enable the ingress node to add egress nodes to a particular P-tunnel
segment.

If it is desired to enable PE-PE explicit tracking across segmentation
domains, new procedures would be needed.

I would like to know if the authors think that I have correctly captured the
issues.  Also, if new procedures need to be developed, we should discuss
some use cases, to make sure that any new procedures are really solving the
problems posed by the use cases.




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