[bess] Opsdir last call review of draft-ietf-bess-evpn-usage-08

[Sheng Jiang]

Reviewer: Sheng Jiang
Review result: Ready

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.

This Informational document discusses the usage and applicability of BGP MPLS
based Ethernet VPN (EVPN) in a common deployment scenario. This document is
well written. It is ready with minor issues.

Major issue: no.

Minor issue: no.

Personal comments: although this document claims it focuses on a "simple" and
fairly common deployment  scenario, it is still complicated giving many aspects
of EVPN. It is hard to read giving the many technical details. I am thinking it
may helpful for readers if there was a minimum scenario to be described.
Overall, the document is well written and useful already. So please feel safe
to ignore my personal suggestion.

Regards,

Sheng


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

Re: [bess] RTG-DIR Telechat review of draft-ietf-bess-dci-evpn-overlay

[Alvaro Retana]

Hi!

Sasha: You make a good point: if here are things that this document Updates
rfc7432 on, which are not specific just to the DCI, then we should go ahead
with it.

The current related text reads:

   In particular, the document updates [RFC7432] on several aspects:

   o The Interconnect Ethernet Segment (I-ES), an Ethernet Segment that
 can be associated not only to a set of Ethernet links, as in
 [RFC7432], but also to a set of PWs or other tunnels.

   o The use of the Unknown MAC route in a DCI scenario.

   o The processing of EVPN routes on Gateways with MAC-VRFs connecting
 EVPN-Overlay and EVPN-MPLS networks, or EVPN-Overlay and EVPN-
 Overlay networks.

Jorge:  Are there extensions defined in this document that are not specific
to the DCI case and that should apply to any EVPN scenario?  If so, can we
update the text to only reflect items that are *not* just DCI-specific?

That is the only outstanding item as the document was otherwise approved by
the IESG today.

Thanks!

Alvaro.

On February 21, 2018 at 8:17:10 AM, Alexander Vainshtein (
alexander.vainsht...@ecitele.com) wrote:

PWs as an a “virtual ES” are also used in conjunction with EVPN in the
scenarios that are not directly related to DCI. One example (actually
pointed to me by Jorge during the review process) is the EVPN Virtual
Ethernet Segment

 draft (now expired).



It is, of course, up to you to decide whether this justifies marking the
draft I’ve reviewed as Updating RFC 7432 because it also defined PWs as a
(virtual) ES for EVPN. Alternatively, it is possible to wait until the EVPN
Virtual segment draft is resuscitated and progressed – but this can take
quite some time...
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Slots requests for BESS WG session - IETF 101 - London

[Patrice Brissette (pbrisset)]

Hi Stephane,

I have 2 preso. EVPN Yang and EVPN port-active.

Regards,
Patrice Brissette
From: BESS  on behalf of "stephane.litkow...@orange.com" 

Date: Thursday, February 22, 2018 at 9:42 AM
To: "bess@ietf.org" 
Subject: [bess] Slots requests for BESS WG session - IETF 101 - London


All,



it is time we start building the BESS WG agenda for London.

The IETF agenda (still preliminary) is available at:

https://datatracker.ietf.org/meeting/101/agenda.html



The BESS WG session (2h30) is scheduled on Tuesday, March 20th, 2018 / 
Afternoon session II / 15:50-18:20 (local time)



Please send us your request for a presentation slot, indicating draft name, 
speaker, and desired duration (covering presentation and discussion).



Thank you



Stephane & Matthew


_



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] Slots requests for BESS WG session - IETF 101 - London

[stephane.litkowski]

All,



it is time we start building the BESS WG agenda for London.

The IETF agenda (still preliminary) is available at:

https://datatracker.ietf.org/meeting/101/agenda.html



The BESS WG session (2h30) is scheduled on Tuesday, March 20th, 2018 / 
Afternoon session II / 15:50-18:20 (local time)



Please send us your request for a presentation slot, indicating draft name, 
speaker, and desired duration (covering presentation and discussion).



Thank you



Stephane & Matthew


_

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] I-D Action: draft-ietf-bess-mvpn-expl-track-07.txt

[stephane.litkowski]

Hi Eric,

Thanks a lot for the update.
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.



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.


Brgds,


-Original Message-
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Eric C Rosen
Sent: Tuesday, February 20, 2018 19:58
To: bess@ietf.org
Subject: Re: [bess] I-D Action: draft-ietf-bess-mvpn-expl-track-07.txt

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

_