Hi,
I’m worrying that MPLS based SFCs may slowdown implementations of NSH.
Vendors have usually a limited bandwidth to implement new features especially
when the dataplane is involved. I would personally prefer to get the resources
allocated to NSH rather than MPLS based SFCs.
This is not just
Dear all,
The draft agenda for the BESS session has been posted:
https://datatracker.ietf.org/meeting/101/materials/agenda-101-bess
If you see any problem with it please let us know.
Presenters,
Please send your slides to the chairs before the meeting session. The deadline
for slides is 48
Hi Eric,
I'm fine with the version 8.
Thanks a lot for the changes.
Speaking as WG chair,
Due to the substantial changes in the document, I will initiate a new short
WGLC for this document soon.
Brgds,
-Original Message-
From: Eric C Rosen [mailto:ero...@juniper.net]
Sent:
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
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)
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
Hi WG,
Based on discussions with the authors, we cancel this adoption poll.
A new one will be issued when the document will be updated.
Brgds,
From: stephane.litkow...@orange.com [mailto:stephane.litkow...@orange.com]
Sent: Monday, February 19, 2018 11:39
To: bess@ietf.org
Cc:
Hi Ali,
The WG adoption of this draft was requested during the IETF 100 (this is even
displayed on the slides !). That’s really strange that as a co-author, you are
not aware of this while you were in the room during the presentation.
Based on this official request, it was added to our
Hello working group,
This email starts a two-week call for adoption on
draft-skr-bess-evpn-pim-proxy-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 5th of
Ok thanks
From: Eric C Rosen [mailto:ero...@juniper.net]
Sent: Wednesday, February 07, 2018 17:57
To: LITKOWSKI Stephane OBS/OINIS;
draft-ietf-bess-mvpn-expl-track.auth...@ietf.org
Cc: bess@ietf.org; bess-cha...@ietf.org
Subject: Re: Shepherd's review of draft-ietf-bess-mvpn-expl-track
On
Hi Eric,
Thanks for your answers. Your proposed changes look fine to me.
Regarding the RD modification, your proposal to reuse the PTA instead of
tweaking the RD looks also better.
Brgds,
From: Eric C Rosen [mailto:ero...@juniper.net]
Sent: Tuesday, February 06, 2018 21:29
To: LITKOWSKI
Hi,
> In that case, two PEs in the same ES supporting type=255 should rely on local
> policy to decide what to.
If type=255 is used, the local policy should be applied and it becomes the job
of the operator to ensure that the policy is the same everywhere.
> And two PEs in the same ES
Hi Jorge,
This perfectly fills my comment.
Speaking as doc shepherd and WG member, I think it could make sense to have a
vendor specific DF election type allocated. This would allow a vendor to
develop a specific algorithm to address a niche use case, not supported by
other vendors.
What do
Hi John,
Speaking as doc shepherd for the ac-df draft, I agree that this make sense and
this will provide more backward compatibility with the behavior defined in
RFC7432.
Brgds,
From: John E Drake [mailto:jdr...@juniper.net]
Sent: Tuesday, January 30, 2018 17:17
To: Rabadan, Jorge (Nokia -
Hi Jorge,
Thanks for your answers.
Pls find more inline [SLI2]
-Original Message-
From: Rabadan, Jorge (Nokia - US/Mountain View)
[mailto:jorge.raba...@nokia.com]
Sent: Tuesday, January 30, 2018 16:20
To: LITKOWSKI Stephane OBS/OINIS; draft-ietf-bess-evpn-ac-df.auth...@ietf.org
Cc:
Hi again,
There is one point that I have missed.
Section 4 uses an old version of the requirement language. Please use the
latest one:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in
Hi,
As shepherd of this document, please find below my comments.
IMO, this is a very useful proposal. The document is quite easy to understand
with a good illustrated example.
Overall comments:
- I would encourage to have an acronym section containing all abbreviations and
the associated
Hello Working Group,
This email starts a Working Group Last Call on
draft-ietf-bess-evpn-ac-df-03 [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
Hi,
Please find below my understanding of the text.
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Xiejingrong
Sent: Friday, January 19, 2018 03:51
To: Eric C Rosen; bess@ietf.org
Subject: Re: [bess] Comments on draft-ietf-bess-mvpn-expl-track-03
Issue clarification:
According to chap
Hi Eric, Andrew
Thanks a lot for the updates done.
Here are more comments.
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.
[Eric] This
101 - 120 of 120 matches
Mail list logo
