.
Linda
-Original Message-
From: Adrian Farrel mailto:adr...@olddog.co.uk> >
Sent: Saturday, February 3, 2024 3:54 PM
To: last-c...@ietf.org <mailto:last-c...@ietf.org>
Cc: andrew-i...@liquid.tech <mailto:andrew-i...@liquid.tech> ;
bess-cha...@ietf.org <mailto:bess-ch
g the resolutions in two separate emails. This one addresses the
comments to Section 3.1.2. Will have another email addressing the remaining
comments.
Can you check if the resolutions to your comments inserted below are
acceptable?
Thank you,
Linda
-Original Message-
From: Adrian F
Hi,
I read this document again as part of its second Last Call. I have a
few comments that should ideally be fixed before passing the draft on
to the RFC Editor. (I ran out of steam around Section 6, sorry.)
Thanks,
Adrian
===
I wondered about the implementation status of this document. One mi
t esoteric, but the short answer is that
any of the authors have the right to grant rights on behalf of all the authors
because of the "joint" work nature.
Yours,
Joel
On 10/6/2023 9:19 AM, Adrian Farrel wrote:
Thanks, Joel.
That’s really helpful.
Pedantically, suppose th
the rights, and it is within the authors remit to
do so.
Yours,
Joel
On 10/6/2023 8:54 AM, Adrian Farrel wrote:
Hi Matthew,
I support this being a WG document.
IANAL. I don’t understand the process by which an author who previously said
“no derivative works” for an I-D is able to
Hi Matthew,
I support this being a WG document.
IANAL. I don't understand the process by which an author who previously said
"no derivative works" for an I-D is able to relax that constraint in a new
revision. Maybe simply posting a new revision without the constraint is
enough. Maybe the c
Reviewer: Adrian Farrel
Review result: Has Issues
Hello
I have been selected to do a Routing Directorate early review of this draft..
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-fast-df-recovery. I
reviewed revision -07.
The Routing Directorate will, on request from the working group
Hi,
I'm the document shepherd for draft-ietf-opsawg-yang-vpn-service-pm. It has
completed WG last call in the OPSAWG.
The work may be of interest to BESS and you might want to watch out for the
IETF last call which will be along in due course.
But I'm sure that the authors would welcome any comm
Hi authors of draft-lp-bess-vpn-interworking,
I noticed your draft show up this morning. I haven't had time to read it
yet.
You may want to take a good look at RFC 9125 for some interworking use cases
that could be of help to you.
Best,
Adrian
-Original Message-
From: I-D-Announce On B
PALS and BESS are probably interested as well.
Adrian
-Original Message-
From: L2sm On Behalf Of Joe Clarke (jclarke)
Sent: 24 September 2021 16:17
To: l...@ietf.org
Cc: ops...@ietf.org
Subject: [L2sm] WG LC: L2 Network model (opsawg)
Hello, l2sm WG. We are currently in WG LC for draft
Hi again,
> COMMENT:
>
>
> The -12 does address the discuss point that I raised, thank you!
>
> In re-reading the draft so as to clear my discuss position, one thing
> that occurred to me is that a reader might wonder what mechanisms
> Picking up (belatedly) where I left off in my initial reply...
Thanks, Ben.
>>> Section 5
>>>
>>> for a prefix X, then each GW computes an SR TE path through that site
>>> to X from each of the currently active GWs, and places each in an
>>> MPLS label stack sub-TLV [RFC9012] in the SR Tu
Thanks for what you got to yesterday.
We can take this step by step.
[snip the Discuss]
>>Given that the gateways and ASBRs are connected by tunnels that may
>> run across parts of the network that are not trusted,
>> data center operators using the approach set out in this network
Hi again Roman,
Just a couple of additional comments in line.
Hoping to find a way forward.
Thanks,
Adrian
>> DISCUSS:
>> --
>>
>> RFC8402 tells us:
>>
>> (a)“Segment Routing domain (SR domain): the set of nodes participating
>> in
Hi Ben,
Thanks for the Discuss and detailed Comments.
Responses in line.
All changes are held in the -12 buffer as we close off issues with the other
ADs.
Cheers,
Adrian
> --
> DISCUSS:
>
> Thanks for having the discussion with John
Thanks Murray,
> COMMENT:
> -
>
> Why is the SHOULD in Section 8 only a SHOULD? Why might I legitimately
> not do what it says?
I need to think about this a bit. My first reaction is that it shouldn't even
use 2119 language in that
Dang!
Now sending to the IESG not the Secretariat.
Adrian
-Original Message-
From: Adrian Farrel
Sent: 19 May 2021 22:31
To: iesg-secret...@ietf.org
Cc: 'bess@ietf.org' ; 'bess-cha...@ietf.org'
; 'Gyan Mishra' ;
'draft-ietf-bess-datacenter-gate...@i
know if you think more action is needed.
Many thanks to you all for the time and effort you've put in to reviewing this
document.
Adrian
-Original Message-----
From: internet-dra...@ietf.org
Sent: 19 May 2021 22:21
To: Adrian Farrel ; Eric Rosen ; John
Drake ; Keyur Patel ; Luay Ja
Hi Roman,
> DISCUSS:
> --
>
> RFC8402 tells us:
>
> (a)“Segment Routing domain (SR domain): the set of nodes participating
> in the source-based routing model …
>
> (a.1) “These nodes may be connected to the same physical infrastructu
Hi Rob,
Interesting question.
> COMMENT:
> ---
>
> The draft has a manageability considerations section - thanks - but I would
> like to check whether assignment of the SR domain identifier would expect to
> be
> configured via YANG
Hi Gyan,
Thanks for the work.
> Attached is a txt version -gsm update of version 10
No attachment received.
Best,
Adrian
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
Hi Warren,
Thanks for this. I'll try to unpick it.
> DISCUSS:
> ---
>
> I hope that I'm just misunderstanding something obvious, but I strongly
> support
> John's DISCUSS
So far, so good: we are in discussions with John and believe we
Thanks Alvaro,
> COMMENT:
> --
>
> The concept of an "SR domain identifier" is not part of rfc8402; it is
> casually
> introduced in §3: "A route target ([RFC4360]) is attached to each GW's
> auto-discovery route and has its valu
Hi Erik,
Yes, per other discussions resulting from IESG review and Directorate reviews,
we need to clarify our use of the word "domain".
The context of an "SR domain" in RFC 8402 is "all nodes participating in an SR
system" and that is assumed to include nodes that are not physically adjacent
Hi Eric,
| Thank you for the work put into this document.
|
| I support John Scudder's first DISCUSS point.
Fair enough.
What did you think of my response to John
>> DISCUSS:
>>
>> 1. There’s surprisingly little in this document that seems to be SR-specific
>> (and what there is, has some probl
, we could make this point clear by saying that the peering between GW1 and
GW2 must be within the site.
Cheers,
Adrian
From: John Scudder
Sent: 14 May 2021 22:25
To: Adrian Farrel
Cc: The IESG ; draft-ietf-bess-datacenter-gate...@ietf.org;
bess-cha...@ietf.org; bess@ietf.org; Matthew
Hi Ben,
Apologies and especially to Daniel.
> I don't see any responses to this review in the mailarchive. It looks
like
> it was even sent before the end of the IETF LC, so I'm pretty surprised
> that there was no response. (I'm particularly interested in the last
> question about the security
Hi John,
Thanks for the careful review.
> DISCUSS:
>
> I have several points I’d like to discuss, listed below from most
> general to most specific.
>
> 1. There’s surprisingly little in this document that seems to be SR-specific
> (and what there is, has some problems, see below). Is there some
Hi John,
I'm currently constructing a reply to your points. Extensive review deserves
extensive answers. May take another day or two.
Cheers,
Adrian
-Original Message-
From: John Scudder via Datatracker
Sent: 13 May 2021 22:41
To: The IESG
Cc: draft-ietf-bess-datacenter-gate...@ietf.
Hi Ravi,
Thanks for taking the time and providing your review.
Best,
Adrian
From: Ravi Singh
Sent: 01 May 2021 07:42
To: bess-cha...@ietf.org; draft-ietf-bess-datacenter-gate...@ietf.org
Cc: bess@ietf.org; rtg-...@ietf.org
Subject: RtgDir Early review: draft-ietf-bess-datacenter-gate
.
Title : BGP-LS Filters : A Framework for Network Slicing
and Enhanced VPNs
Authors : John Drake
Adrian Farrel
Luay Jalil
Avinash Lingala
Filename: draft-drake-bess
Hi again Gyan,
I think we’re narrowing down and getting somewhat esoteric for the mailing
lists we’re spamming.
> Similarly other use cases such as with TEAS TS-Transport slice and being able
> to provision TS and capturing the TS Enhanced VPN RT & resource information
> and leveraging BGP-LS
Hi Gyan,
Sorry, I missed this (got caught on a filter cos it was a bit spammed to a lot
of lists :-).
> I have noticed that after reviewing many drafts across many WGs it seems in
> the
> industry that the lines seem to be blurred between a PCE controller, ODL or
> Openflow SDN Controll
Hi again,
Thanks for rapid convergence.
All good.
Adrian
Section 3 notes that the procedure (presumably the procedure defined
in this section) is OPTIONAL. I didn't see anything similar in sections
4 and 5 stating that those procedures are optional. Presumably, since
this document i
Hello Greg,
Thanks for this. I’m cutting down to places where we still need to interact.
Look for [af] and blue text.
Nothing alarming.
Best,
Adrian
Section 3 notes that the procedure (presumably the procedure defined
in this section) is OPTIONAL. I didn't see anything similar in
Reviewer: Adrian Farrel
Review result: Has Issues
Hello,
I have been selected as the Routing Directorate reviewer for this draft. The
Routing Directorate seeks to review all routing or routing-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request
Ben,
Thanks for the update.
> DISCUSS:
>
> I think we may still need some text changes to clarify how the joint list
> of SFIR-RD and SFIR Pool Identifier Extended Communities is constructed
> and interpreted, and potentially need to register an RD Type matching
> the other (TBD6+TBD7) values we
Just coming back to you on this one, Alvaro
> I'm not too keen on the use of treat-as-withdraw, specially because
> the sender doesn't know that something happened. Knowing that the
> communication is direct between the controller/classifier, I would
> like to propose thinking of multiple com
Thanks Murray.
-16 fixes "L3VPN", "NRLI", and "EVPN"
I've also been back to check through Adam's Comment and fixed a few other
bits and pieces.
Best,
Adrian
-Original Message-
From: BESS On Behalf Of Murray Kucherawy via
Datatracker
Sent: 22 June 2020 00:56
To: The IESG
Cc: slitkows.i
Hi Ravi,
I’m doing housekeeping on this draft and find your review. It looks like we
didn’t respond – sorry.
Many thanks for the careful review.
Comments are in line…
Intended Status: Standards track (but is it the right one? Should this be
informational instead, since no new enc
Hi Linda,
Sorry that I missed this question from you…
Adrian:
On page 6, the second Bullet says that
“Each GW constructs an import filtering rule to import any route that carries a
route target with the same SR domain identifier that the GW itself uses”
How about routes associated
l encapsulation.
On Thu, Jun 4, 2020 at 1:35 PM Adrian Farrel mailto:adr...@olddog.co.uk> > wrote:
Hi,
This late-breaking revision just tweaks for the discussion with Boris.
Thanks,
Adrian
-Original Message-
From: BESS mailto:bess-boun...@ietf.org> > On Behalf Of
i
d” to
“forward/forwarded”.
Regards;
Basil
From: Adrian Farrel mailto:adr...@olddog.co.uk> >
Sent: July-28-20 10:07 AM
To: Najem, Basil mailto:basil.na...@bell.ca> >; 'Linda
Dunbar' mailto:linda.dun...@futurewei.com> >;
bess@ietf.org <mailto:bess@ietf.org>
e issue here
Adrian? Can we capture this statement as per your suggestion and remove the
word “route” (or routed) and replace it with “forward” (or forwarded)?
Regards;
Basil
From: Adrian Farrel
Sent: July-28-20 9:19 AM
To: 'Linda Dunbar' ; Najem, Basil
; bess@ietf
on can be routed based on specific performance criteria (e.g.
packets delay, packet lose, jitter) to provide a better experience by choosing
a tunnel over an underlay that meets or exceeds the specified performance
criteria threshold for that application"
Regards;
Basil
packets delay, packet lose, jitter) to provide a better experience by choosing
a tunnel over an underlay that meets or exceeds the specified performance
criteria threshold for that application"
Regards;
Basil
-Original Message-
From: Adrian Farrel
Sent: July-28-20 8:01 AM
To: bess@iet
Hi,
As Linda noted in her agenda slot today, draft-dunbar-bess-bgp-sdwan-usage
version 08 introduced a new paragraph in the Introduction that says:
- The Application Routing can also be based on specific
performance criteria (e.g. packets delay, packet loos, jitter)
to provide
n the
behavior for Extended communities already specified somewhere else.
Just some digging help. :-)
Alvaro.
On July 10, 2020 at 3:56:44 PM, Adrian Farrel (adr...@olddog.co.uk
<mailto:adr...@olddog.co.uk> ) wrote:
Thanks. I can accept either of your suggestions. I'm
Thanks Alvaro!
>> "In an environment where there is concern that rogue Controllers might be
>> introduced to the network and inject false SFPRs or take over and change
>> existing SFPRs, it is RECOMMENDED that each SFF and Classifier be
>> configured with the identities of authorised Controllers.
Hello again, Alvaro.
> > DISCUSS:
>>> -
>>>
>>> (1) Controllers and other nodes.
>>...
>> So, you are right and we are highlighting it in the security section, and
>> we can note the existing mitigations in a BGP-based routing system agai
Authors : Adrian Farrel
John Drake
Eric Rosen
Jim Uttaro
Luay Jalil
Filename: draft-ietf-bess-nsh-bgp-control-plane-15.txt
Pages : 69
Date
Hi Discussing ADs,
I appreciate that authors sat on your Discusses for a long time and that that
means that they are not in a good place from which to ask you to move along.
However 😊
I sent mail addressing your Discusses two weeks ago, and posted a new revision
ten days ago.
Is there anythin
Authors : Adrian Farrel
John Drake
Eric Rosen
Keyur Patel
Luay Jalil
Filename: draft-ietf-bess-datacenter-gateway-07.txt
Pages : 12
Date
Hi,
John and I had a chat today about what we perceive is Stephane's open issue.
What we think the concern is is that we are using RTs in conjunction with
normal (i.e., non-VPN) routes. We do this to allow gateways to filter their
imports based on the RT that applies to the SR domain that it serv
: matthew.bo...@nokia.com; bess@ietf.org; Adrian Farrel
; draft-ietf-bess-datacenter-gate...@ietf.org
Subject: Re: [bess] FURTHER REMINDER Re: WG Last Call, IPR and Implementation
Poll for draft-ietf-bess-datacenter-gateway-04
Hi Adrian!
My comment is below.
Thank you.
SY,
Boris
On
: Adrian Farrel
John Drake
Eric Rosen
Jim Uttaro
Luay Jalil
Filename: draft-ietf-bess-nsh-bgp-control-plane-14.txt
Pages : 68
Date: 2020-06
Hello again,
[snip]
>>> 2) Fig 1, IMO, needs additional information about which AS/ ASes
>>> are used for Ingress and Egress SR Domains (Guess AS1 and AS2
>>> respectively, but it has to be shown). Current version looks a bit
>>> confusing, for example, why we need AS3 on Fig.1?
>>
>> I
Hi Boris,
We waited for a prompt for the chairs to find out what the disposition of the
draft was.
> I read the draft and personally support its publication.
Thanks.
> Here are some comments:
>
> 1) Introduction part has the following statement: "Segment Routing (SR)
> [RFC8402]
> is a popul
Hi Alvaro,
Here is a more considered response to your review...
> DISCUSS:
> -
>
> (1) Controllers and other nodes.
>
> Background: This document defines the new SFC NLRI, which has two distinct
> route types, originated by either a node
Hi Ravi,
Thanks for a thorough and useful review.
Responses in line…
> Summary:
> I have some minor concerns about this document that I think should be
> resolved before publication.
Doing so in -14
> Minor issues:
>
> Section2: During an initial reading, the terminology comes across as overl
Hi Ben,
Many thanks for the detailed review.
Herewith responses to your Discuss and Comments.
> DISCUSS:
> --
>
> Section 3.2.1.3 seems to talk about intermingling SFIR-RDs and
> SFIR Pool Identifiers in a common list, but I do not
Hi again Roman,
Distinct thread from the one on your Discuss...
> COMMENT:
> -
>
> * Section 2.2. Could you please clarify connect between these two
> statements about the SFC architecture:
>
> 1. “The SFIR is advertised by the nod
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
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
Hi Stephane,
> Due to new coming corporate travel restrictions associated to this
> Coronavirus, there will be no chair or secretary attending the
> IETF 107 physically.
That’s a shame, but understandable.
> We will have to cancel the BESS sessions unfortunately.
That does not fol
Hi Roman,
Without delving deeper (yet), why is this document any different from any other
document in which BGP is used? Will you be placing a Discuss on every document
coming out of IDR and BESS until there is a clear statement of how to secure
BGP-based systems?
Thanks,
Adrian
-Original
Hi Alvaro,
I'll think about this a little more when not on vacation, but I want to draw
your attention to two things:
> (1) Controllers and other nodes.
1. The controllers are not SDN controllers. They are not single omnipotent,
all-seeing god boxes. They are boxes that control. They could be
Hello Barry,
Thanks for the comments.
> — Section 1.2 —
>
> o Service Function Overlay Network. The logical network comprised
> of Classifiers, SFFs, and SFIs that are connected by paths or
> tunnels through underlay transport networks.
>
> You use “comprises” correctly four other t
Hi Adam,
Thanks for this.
> Please expand the following acronyms upon first use, in the abstract, and in
> the title; see https://www.rfc-editor.org/materials/abbrev.expansion.txt for
> guidance.
Agreed.
> All of the examples in these sections use IPv4 addresses exclusively. Please
> update the
Thanks for this review.
I see you were looking at the -13 revision which is the most recent.
Per Brian Carpenter's GenArt review of -12 we added some text to clarify
"controller".
Section 1
a
Controller (a centralized network component responsible for planning
and coordinating Service F
Authors : Adrian Farrel
John Drake
Eric Rosen
Jim Uttaro
Luay Jalil
Filename: draft-ietf-bess-nsh-bgp-control-plane-13.txt
Pages : 59
Date
Hi Brian,
Thanks for your time with this.
In line...
> Comments:
> -
>
> I am not a BGP expert and did not check the BGP details. This
> is a pretty complex mechanism so I would have liked to hear of
> at least a lab-scale implementation. I wouldn't be shocked if
> this was diverted to E
Hi,
Do you have agenda space for draft-drake-bess-enhanced-vpn? We’ll be posting
-02 in an hour or so.
The document describes an approach to network slicing that uses BGP-LS to
describe filters of the base network topology. The approach described is
consistent with draft-ietf-teas-enhanc
iceS WG of the IETF.
Title : BGP Control Plane for NSH SFC
Authors : Adrian Farrel
John Drake
Eric Rosen
Jim Uttaro
Luay Jalil
Filename: draft
Enabled Domain Interconnection
Authors : Adrian Farrel
John Drake
Eric Rosen
Keyur Patel
Luay Jalil
Filename: draft-ietf-bess-datacenter-gateway-03.txt
Very happy to have more comments and help to clarify our text.
At this stage the authors believe they have addressed all comments received
during working group last call and from the shepherd’s review. But (of course)
any review that points up a problem or suggests a clarification is a good
Hi Stephane,
Thanks again for the thoroughness of your review and the time it has taken to
herd the necessary cats.
* BGP ERROR HANDLING:
I don’t see the “error handling” behavior associated with this attribute
(discard, treat-as-withdraw…)
>>>
>>> I think the errors are covered by sec
Well, since it's Upload Friday, I posted the new revision, but let me know if
you think more changes are needed.
Adrian
-Original Message-
From: BESS On Behalf Of Adrian Farrel
Sent: 24 April 2019 18:38
To: stephane.litkow...@orange.com;
draft-ietf-bess-nsh-bgp-control-pl...@iet
t the Classifier component of the SFC system. This section seems to
be relevant to the question you are asking.
But this second section seems to have it all covered by modelling exactly the
flowspec function used in BGP flow specification and adding an extended
community for SFC.
So, I think nothing
Thanks again Stephane,
I think we have closure on most (but not all) of your points. I'll post another
revision now because it makes the incremental changes easier to process. But we
can have another go round if any of the unresolved issues merit it.
One thing to push back on from before was th
Hello Stephane,
Thanks for this review. It is very thorough and has helped improve the document.
We have posted an update to the draft, and there are responses to your review,
below.
Thanks,
Adrian
> The document is globally well written with good examples that help the
> understanding.
> How
ft 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 : Gateway Auto-Discovery and Route Advertisement for
Segment Routing Enabled Domain Interconnection
Authors : Adrian F
lable from the on-line Internet-Drafts
directories.
This draft is a work item of the BGP Enabled ServiceS WG of the IETF.
Title : BGP Control Plane for NSH SFC
Authors : Adrian Farrel
John Drake
Eric
Keyur,
Avinash.
Brgds,
-Original Message-
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Adrian Farrel
Sent: Monday, February 25, 2019 18:39
To: bess@ietf.org
Subject: Re: [bess] I-D Action: draft-ietf-bess-nsh-bgp-control-plane-06.txt
All,
Thanks for the comments we received duri
Enabled ServiceS WG of the IETF.
Title : BGP Control Plane for NSH SFC
Authors : Adrian Farrel
John Drake
Eric Rosen
Jim Uttaro
Luay Jalil
Filename
Hi Stephane,
I am not aware of any IPR that has not already been disclosed against this
document.
Thanks,
Adrian
From: BESS On Behalf Of
stephane.litkow...@orange.com
Sent: 21 January 2019 13:06
To: bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: [bess] WGLC, IPR and implementation po
Hey Wim,
Thanks for (not 😉 ) reading.
Yes, MPLS-SFC was certainly in mind, but we wrote the initial document only for
NSH, and so the document is named for that and fully scoped for that.
I believe that draft-ietf-mpls-sfc-encapsulation is “only” an interface
encapsulation of NSH. Thu
Stephane,
Thanks for bringing this back for another last call.
I think that the approach documented in this document is a fine solution for
a somewhat limited SFC deployment. It has the benefits of using existing
techniques and tools, and satisfies the need for a quick deployment solution
f
-Drafts
directories.
This draft is a work item of the BGP Enabled ServiceS WG of the IETF.
Title : BGP Control Plane for NSH SFC
Authors : Adrian Farrel
John Drake
Eric Rosen
Jim Uttaro
Available from your favourite online bookseller.
Or contact me to receive a signed copy by mail.
-Original Message-
From: Satya Mohanty (satyamoh)
Sent: 14 December 2018 23:17
To: Rabadan, Jorge (Nokia - US/Mountain View) ; Adrian
Farrel ; rtg-...@ietf.org;
draft-ietf-bess-evpn-df-ele
hanty (satyamoh)
Sent: 07 December 2018 17:12
To: Adrian Farrel ; rtg-...@ietf.org
Cc: draft-ietf-bess-evpn-df-election-framework@ietf.org; i...@ietf.org;
bess@ietf.org
Subject: Re: Rtgdir last call review of
draft-ietf-bess-evpn-df-election-framework-06
Hi Adrian,
Thank you very much fo
Reviewer: Adrian Farrel
Review result: Has Nits
Hello,
I have been selected as the Routing Directorate reviewer for this draft. The
Routing Directorate seeks to review all routing or routing-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The
|SFT=42|--
--
As shown above, SFIa, SFIb and SFIc are attached to SFF1, SFF5, and SFF6
respectively.
Similarly, it is valid to use load balancing on SFPs or flows in this case.
Cheers,
Yuanlong
From: Adrian Farre
-D Action: draft-ietf-bess-nsh-bgp-control-plane-04.txt
>
>
> 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 : BGP Control Plane for NSH S
Wim asked...
> would you consider adding an MPLS label to the SFIR route in order to
> support https://tools.ietf.org/html/draft-malis-mpls-sfc-encapsulation-01.
I think that the idea of making such an addition is fine, but (and no offence
meant to the authors of draft-malis-mpls-sfc-encapsulation
Hey Yuanlong,
Thanks for your thoughtful comments.
> I had a review of draft-ietf-bess-nsh-bgp-control-plane-03, thank you for this
useful
> document and hope it can progress quickly.
>
> In my opinion, this version still has some ambiguities which need to be
cleaned up:
>
> 1. In Section 3.1
able from the on-line Internet-Drafts
directories.
> This draft is a work item of the BGP Enabled ServiceS WG of the IETF.
>
> Title : Gateway Auto-Discovery and Route Advertisement for
Segment
> Routing Enabled Domain Interconnection
> Authors : John Dr
[mailto:wim.henderi...@nokia.com]
Sent: 18 March 2018 07:26
To: Robert Raszuk; Adrian Farrel
Cc: mpls; SPRING WG List; s...@ietf.org; bess@ietf.org
Subject: Re: [sfc] [mpls] Progress with draft-farrel-mpls-sfc
Indeed, this is exactly my point. If you want an interim solution you want to
use wha
: draft-ietf-bess-nsh-bgp-control-plane-03.txt
>
>
> 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 : BGP Control Plane for NSH SFC
&g
Hi BESS,
draft-ietf-l2sm-l2vpn-service-model is going through working group last call in
L2SM.
Please send your comments to the L2SM list. In exceptional circumstances you may
send your comments via the L2SM chairs.
Thanks,
Adrian
___
BESS mailing lis
1 - 100 of 163 matches
Mail list logo
