Re: [bess] Last Call: (BGP Usage for SD-WAN Overlay Networks) to Informational RFC

[Adrian Farrel]

Hi again, Linda.

 

Here is the response to your second email. Again, comments in line, with
snipping of agreed points.

 

Best,

Adrian

 

From: Linda Dunbar  
Sent: 08 February 2024 01:58
To: adr...@olddog.co.uk; last-c...@ietf.org
Cc: andrew-i...@liquid.tech; bess-cha...@ietf.org; bess@ietf.org;
draft-ietf-bess-bgp-sdwan-us...@ietf.org; matthew.bo...@nokia.com
Subject: RE: Last Call:  (BGP Usage
for SD-WAN Overlay Networks) to Informational RFC

 

Adrian, 

 

Please see below for the resolutions to your remaining comments. 

 

Thank you very much for the detailed comments. 

 

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-cha...@ietf.org> ; bess@ietf.org
<mailto:bess@ietf.org> ; draft-ietf-bess-bgp-sdwan-us...@ietf.org
<mailto:draft-ietf-bess-bgp-sdwan-us...@ietf.org> ; matthew.bo...@nokia.com
<mailto:matthew.bo...@nokia.com> 
Subject: RE: Last Call:  (BGP Usage
for SD-WAN Overlay Networks) to Informational RFC

 

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

 

===



---

 

3.1.2

 

I had a lot of trouble working out what this section is trying to say.

 

   The client service requirements describe the port interface

   requirement at the SD-WAN edge to connect the client network to

   the SD-WAN service.

 

[Linda] The client service requirements describe the SD-WAN edge's ports,
also known as SD-WAN client interface, which connect the client network to
the SD-WAN service.

 

 [AF] OK. Probably Do you intend that "the interface is the set of ports" or
"each port is an interface"? Depending on this you have:

s/known as SD-WAN/collectively known as the SD-WAN/

Or

s/interface/interfaces/ 

 

The requirements describe the requirement?

And what are those requirements?

 

[Linda] those requirements are:

*   The SD-WAN client interface should support IPv4 & IPv6 address
prefixes and Ethernet (as described in [IEEE802.3] standard). 
*   The client service should support the SD-WAN UNI service attributes
at the SD-WAN edge as described in MEF 70.1, Section 11.

[AF] OK. Clear if stated like this. 

 

   The client interface ports can support IPv4 & IPv6 address

   prefixes and Ethernet (as described in [IEEE802.3] standard).

 

How does a port support an address prefix? 

[Linda] The interface should support IPv4/IPv6. 

 

   It is worth noting that this "interface"

 

Which interface?

[Linda] SD-WAN client interface.

 

   is called SD-WAN UNI in

   [MEF 70.1] with a set of attributes (described in Section 11 in

   MEF 70.1); these attributes (in MEF 70.1) describe the expected

   behavior and requirements to support the connectivity to the

   client network.

 

I presume that this is focused on the case that the SD-WAN edge is a PE not
a CPE?

 

[Linda] when provider managed SD-WAN, the SD-WAN edge is PE. For SD-WAN
provided to enterprises, the SD-WAN is CPE.

 

[AF] The thing that "confused" me is when you say that the UNI supports the
connectivity to the client network. In the CPE case, isn't the CPE part of
the client network? Where is the UNI?

 

   The client service should support the SD-WAN UNI service

   attributes at the SD-WAN edge as described in MEF 70.1, Section

   11.

 

What is the "client service"?

[Linda] client service interface.

 

What does "should" mean here? 

 

[AF] I think you haven't answered this, and you have reproduced it in your
new text, above. Does "should" mean "must" or are there acceptable
exceptions (if so, what?)?

 

Isn't it the case that the attributes in MEF 70.1/11 apply at an interface
not at a node?

[Linda] Yes

 

Do these attributes apply to the configuration/management of the client
service interface, or to the marking of packets on the interface, or to the
handling of packets on the interface?

 

[Linda] described in detail in MEF70.1. The MEF people insisted adding the
statement. Too long to reiterate in this draft.

 

[AF] I can accept that if you make the MEF document a normative reference.

 

---

 

3.1.3

 

   For example, a retail business requires the point-of-sales (PoS)

   application to be on a different topology from other applications.

   The PoS application is routed only to the payment processing

   entity at a hub site; other applications can be routed to all

   other sites.

 

The second sentence is true, but does not justify the asserted requirement
in the first sentence.

[Linda] ? The first sentence only says the example of PoS being on 

Re: [bess] Last Call: (BGP Usage for SD-WAN Overlay Networks) to Informational RFC

[Adrian Farrel]

Hi Linda,

 

Thanks for considering all of my comments. I'll respond to your two emails
separately. Comments inline. I snipped the obvious agreements.

 

Cheers,

Adrian

 

From: Linda Dunbar  
Sent: 07 February 2024 00:23
To: adr...@olddog.co.uk; last-c...@ietf.org
Cc: andrew-i...@liquid.tech; bess-cha...@ietf.org; bess@ietf.org;
draft-ietf-bess-bgp-sdwan-us...@ietf.org; matthew.bo...@nokia.com
Subject: RE: Last Call:  (BGP Usage
for SD-WAN Overlay Networks) to Informational RFC

 

Adrian, 

 

Thank you very much for the extensive comments and suggestions. 

I am breaking 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 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-cha...@ietf.org> ; bess@ietf.org
<mailto:bess@ietf.org> ; draft-ietf-bess-bgp-sdwan-us...@ietf.org
<mailto:draft-ietf-bess-bgp-sdwan-us...@ietf.org> ; matthew.bo...@nokia.com
<mailto:matthew.bo...@nokia.com> 
Subject: RE: Last Call:  (BGP Usage
for SD-WAN Overlay Networks) to Informational RFC

 

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 might say
that an Informational I-D has nothing to be implemented, but this document
seems to be telling us which elements of other RFCs to use and combine to
make a working system. Seeing that some of my comments note that the text
appears to recommend using a deprecated code point, and that the BESS wiki
notes "Implementation Status" as one of the working group last call
checklist items, I thought it might be nice if this document has an RFC 7942
section to help us know how solid the processes are.

 

[Linda] There are two implementations of the extension of BGP to control
SD-WAN
(https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-sdwan-edge-d
iscovery  ). 

I will ask Matthews to add the link to the implementation reports. 

 

[AF] OK. Adding the pointer to the implementation report of the IDR document
as a link in the Datatracker for this document would be helpful.

But it doesn't cover the whole picture, does it?

Of course, it is not mandatory for an Informational document, but it would
be really helpful to know who has put a system together as described in this
document, does it include all of the components, what problems were
encountered, has there been any interop?

 

[snip]

 

---

 

The running footer seems to be broken ("xxx, et al.")

[Linda] ? should I remove the footnote (Dunbar, et al)? 

 

[AF] The footer should be there. It should read something like "Dunbar, et
al."

Currently is reads "xxx, et al."

 

[snip]

 

---

 

Why does the document title say "overlay networks" while the Abstract says
"multiple scenarios".

[Linda] specifically: "multiple scenarios of SD-WAN (Software Defined WAN)
overlay networks". 

 

[AF] OK, I see the change in -20.

 

---

 

Why isn't [MEF70.1] a normative reference? It seems that this document leans
on it heavily for the definition of SD-WAN and for other material.

[Linda] Will listing non-IETF standard as normative delay the process? 

 

[AF] Whether it delays the process or not, is not the issue (although I can
see why it might worry you).

Later on, I think you say that there is material in MEF70.1 that you did not
want to repeat, but which is important, etc.

It really is a normative reference.

The good thing, however, is that MEF70.1 seems to be freely available for
download, so I believe it will not change the publication process for your
draft.

 

[snip]

 

---

 

1.

 

 - Some traffic can be forwarded by edge nodes, based on their

   application identifiers instead of destination IP addresses

 

I think this is unintentionally ambiguous. Presumably it is not the
application identifiers of the edge nodes. 

 

I believe you are talking about traffic steering, although "forwarding"

may be an acceptable term. We normally think about forwarding onto a link or
toward a next hop, and steering onto a path.

 

[Linda]. By the way, does IETF have a formal definition of "Steering" vs.
"Forwarding"? 

 

[AF] RFC 9522 has.

   Path steering is the ability to forward packets using more

   information than just knowledge of the next hop.  Examples of path

   steering include IPv4 sour

Re: [bess] Last Call: (BGP Usage for SD-WAN Overlay Networks) to Informational RFC

[Adrian Farrel]

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 might
say that an Informational I-D has nothing to be implemented, but this
document seems to be telling us which elements of other RFCs to use and
combine to make a working system. Seeing that some of my comments note 
that the text appears to recommend using a deprecated code point, and
that the BESS wiki notes "Implementation Status" as one of the working
group last call checklist items, I thought it might be nice if this
document has an RFC 7942 section to help us know how solid the processes
are.

---

Please fix John Drake's contact details.

---

You have a different number of people on the front page and in the
Authors' Addresses section.

---

The RFC Editor is going to ask you whether you can find a different way
of saying "traditional" in the many cases in this document. Mainly, I
think you can just delete the word.

---

The running footer seems to be broken ("xxx, et al.")

---

The document title and abstract should not assume that the reader is
familiar with the abbreviation "SD-WAN"

---

Why does the document title say "overlay networks" while the Abstract
says "multiple scenarios".

---

Why isn't [MEF70.1] a normative reference? It seems that this document
leans on it heavily for the definition of SD-WAN and for other material.

---

1.

s/IP Packets/IP packets/

---

1.

 - Some traffic can be forwarded by edge nodes, based on their
   application identifiers instead of destination IP addresses

I think this is unintentionally ambiguous. Presumably it is not the
application identifiers of the edge nodes. 

I believe you are talking about traffic steering, although "forwarding"
may be an acceptable term. We normally think about forwarding onto a
link or toward a next hop, and steering onto a path.

---

1.

 - Some traffic can be forwarded by edge nodes, based on their
   application identifiers instead of destination IP addresses,
   by placing the traffic onto specific overlay paths based on
   the application-specific policies. An "application identifier"
   in this document refers to one or multiple fields of the IP
   header of the packets.

I think this use of "application identifier" (and, later, "recognizing
applications") is significantly misleading. At best, what you have here
is a "flow identifier". Further, you say that this is done "instead of 
the destination IP address", yet the destination IP address is surely a
"field of the IP header of the packet". (By the way, by the time you get
to Section 3.3, you are talking about flows.)

You go on to say:

   More detailed attributes that can be
   used for identifying applications are described in the Table7
   and Table 8 of [MEF70.1]

Table 7 includes fields that are not part of the IP header. 
  - In general, matching on source and destination port IDs is 
considered an acceptable way of identifying traffic flows. But this
is contrary to what you have previously said and is, in any case, 
problematic with some forms of encryption. 
  - The concept of "Custom match including heuristic/algorithmic
matching" is clearly not intended to relate purely to fields in
the IP header, but includes some form of DPI. It is arguable that an
SD-WAN edge node is part of the customer's network, and that the
customer is allowed to inspect any user's traffic within their 
network. This, however, probably only applies to certain types of
customer network. It is also likely to fail in the presence of
end-to-end encryption.
I do not find this topic discussed further in the draft, and I think
it needs to be specifically excluded, or explained in some detail.
I refer the AD to the discussion of "APN" within the IETF and to the
careful efforts that have been made to attempt to achieve 
application flow identification for different traffic treatments and
for traffic steering at the edge of the network without recourse to
DPI. This is, I think a serious problem with the document.

Table 8 also includes fields that are not part of the IP header.
  - Using the Ethertype of the encapsulating Ethernet frame may be a
tool that can be used, but you would need to make that clear as it
is obviously not part of the IP header. Further, as the note in the
table says, not all implementations will have access to the Ethertype
of the received frame.

It is possible that including a reference to Section 8 of MEF 70.1 might
be helpful here, but I note that that document says:
   Although the term "Application Flow" includes the word "Application"
   there is only a loose connection between the two. 
So, while you could continue to use the term 

Re: [bess] WG Adoption Poll for draft-ietf-bess-bgp-sdwan-uasge-16

[Adrian Farrel]

Nice!

 

From: Joel Halpern  
Sent: 06 October 2023 14:24
To: adr...@olddog.co.uk; 'Matthew Bocci (Nokia)' ; 
bess@ietf.org
Cc: draft-ietf-bess-bgp-sdwan-us...@ietf.org
Subject: Re: [bess] WG Adoption Poll for draft-ietf-bess-bgp-sdwan-uasge-16

 

The rules for joint works are somewhat 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 there was an author on the old draft who is not an author 
on the new draft?

(I think we are into esoteric grounds here, but just wondering.)

 

A

 

From: Joel Halpern  <mailto:j...@joelhalpern.com>  
Sent: 06 October 2023 14:08
To: adr...@olddog.co.uk <mailto:adr...@olddog.co.uk> ; 'Matthew Bocci (Nokia)'  
<mailto:matthew.bo...@nokia.com> ; bess@ietf.org 
<mailto:bess@ietf.org> 
Cc: draft-ietf-bess-bgp-sdwan-us...@ietf.org 
<mailto:draft-ietf-bess-bgp-sdwan-us...@ietf.org> 
Subject: Re: [bess] WG Adoption Poll for draft-ietf-bess-bgp-sdwan-uasge-16

 

Not speaking for the trust, but as someone who has worked in the rights pace 
for IETF for quite some time, if the authors update the rights grant to grant 
the needed rights (by replacing the boilerplate), then the new draft grants the 
needed rights.  They have legal ability to make such a change.  Sure, it is 
still the case that one can not work directly from the old draft.  The current 
(-17) draft appears to grant 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 relax that constraint in a new 
revision. Maybe simply posting a new revision without the constraint is enough. 
Maybe the constraint on the old versions still applies. Would be neat to get an 
opinion from the Trust or IETF Counsel.

 

Cheers,

Adrian

 

From: BESS  <mailto:bess-boun...@ietf.org>  On Behalf Of 
Matthew Bocci (Nokia)
Sent: 05 October 2023 11:45
To: bess@ietf.org <mailto:bess@ietf.org> 
Cc: draft-ietf-bess-bgp-sdwan-us...@ietf.org 
<mailto:draft-ietf-bess-bgp-sdwan-us...@ietf.org> 
Subject: [bess] WG Adoption Poll for draft-ietf-bess-bgp-sdwan-uasge-16

 

WG

 

This email starts a one-week WG adoption poll for 
draft-ietf-bess-bgp-sdwan-uasge-16 [1]

 

A little bit of history: A previous version was adopted, completed WG last 
call, and publication requested as an Informational RFC. v15 of this draft was 
reviewed by the IESG and found to have a restrictive clause in the boilerplate. 
This has now been removed, but since that clause was inconsistent with the 
draft having been adopted as a WG document in the first place, we have been 
asked to go through the process again.

 

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

 

This poll will close on Thursday 12th October.

 

Regards

 

Matthew

 

[1] draft-ietf-bess-bgp-sdwan-usage-16 - SD-WAN edge nodes are commonly 
interconnected by multiple types of underlay networks owned and managed by 
different network providers. 
<https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-sdwan-usage/16/> 






___
BESS mailing list
BESS@ietf.org <mailto: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] WG Adoption Poll for draft-ietf-bess-bgp-sdwan-uasge-16

[Adrian Farrel]

Thanks, Joel.

 

That’s really helpful.

 

Pedantically, suppose there was an author on the old draft who is not an author 
on the new draft?

(I think we are into esoteric grounds here, but just wondering.)

 

A

 

From: Joel Halpern  
Sent: 06 October 2023 14:08
To: adr...@olddog.co.uk; 'Matthew Bocci (Nokia)' ; 
bess@ietf.org
Cc: draft-ietf-bess-bgp-sdwan-us...@ietf.org
Subject: Re: [bess] WG Adoption Poll for draft-ietf-bess-bgp-sdwan-uasge-16

 

Not speaking for the trust, but as someone who has worked in the rights pace 
for IETF for quite some time, if the authors update the rights grant to grant 
the needed rights (by replacing the boilerplate), then the new draft grants the 
needed rights.  They have legal ability to make such a change.  Sure, it is 
still the case that one can not work directly from the old draft.  The current 
(-17) draft appears to grant 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 relax that constraint in a new 
revision. Maybe simply posting a new revision without the constraint is enough. 
Maybe the constraint on the old versions still applies. Would be neat to get an 
opinion from the Trust or IETF Counsel.

 

Cheers,

Adrian

 

From: BESS  <mailto:bess-boun...@ietf.org>  On Behalf Of 
Matthew Bocci (Nokia)
Sent: 05 October 2023 11:45
To: bess@ietf.org <mailto:bess@ietf.org> 
Cc: draft-ietf-bess-bgp-sdwan-us...@ietf.org 
<mailto:draft-ietf-bess-bgp-sdwan-us...@ietf.org> 
Subject: [bess] WG Adoption Poll for draft-ietf-bess-bgp-sdwan-uasge-16

 

WG

 

This email starts a one-week WG adoption poll for 
draft-ietf-bess-bgp-sdwan-uasge-16 [1]

 

A little bit of history: A previous version was adopted, completed WG last 
call, and publication requested as an Informational RFC. v15 of this draft was 
reviewed by the IESG and found to have a restrictive clause in the boilerplate. 
This has now been removed, but since that clause was inconsistent with the 
draft having been adopted as a WG document in the first place, we have been 
asked to go through the process again.

 

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

 

This poll will close on Thursday 12th October.

 

Regards

 

Matthew

 

[1] draft-ietf-bess-bgp-sdwan-usage-16 - SD-WAN edge nodes are commonly 
interconnected by multiple types of underlay networks owned and managed by 
different network providers. 
<https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-sdwan-usage/16/> 





___
BESS mailing list
BESS@ietf.org <mailto: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] WG Adoption Poll for draft-ietf-bess-bgp-sdwan-uasge-16

[Adrian Farrel]

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 constraint on the old versions still applies. Would be
neat to get an opinion from the Trust or IETF Counsel.

 

Cheers,

Adrian

 

From: BESS  On Behalf Of Matthew Bocci (Nokia)
Sent: 05 October 2023 11:45
To: bess@ietf.org
Cc: draft-ietf-bess-bgp-sdwan-us...@ietf.org
Subject: [bess] WG Adoption Poll for draft-ietf-bess-bgp-sdwan-uasge-16

 

WG

 

This email starts a one-week WG adoption poll for
draft-ietf-bess-bgp-sdwan-uasge-16 [1]

 

A little bit of history: A previous version was adopted, completed WG last
call, and publication requested as an Informational RFC. v15 of this draft
was reviewed by the IESG and found to have a restrictive clause in the
boilerplate. This has now been removed, but since that clause was
inconsistent with the draft having been adopted as a WG document in the
first place, we have been asked to go through the process again.

 

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

 

This poll will close on Thursday 12th October.

 

Regards

 

Matthew

 

[1] draft-ietf-bess-bgp-sdwan-usage-16 - SD-WAN edge nodes are commonly
interconnected by multiple types of underlay networks owned and managed by
different network providers.
 

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

[bess] Rtgdir early review of draft-ietf-bess-evpn-fast-df-recovery-07

[Adrian Farrel via Datatracker]

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 chair, perform
an early review of a draft before it is submitted for publication to the IESG.
The early review can be performed at any time during the draft's lifetime as a
working group document. The purpose of the early review depends on the stage
that the document has reached.

I reviewed revision -07 of this draft after the completion of WG last call and
shepherd review, but before the WG makes a publication request. The purpose of
a review at this stage is to improve the quality before AD review and so reduce
the AD workload as wellas improve the output of the working group and the final
quality of any published RFCs.

For more information about the Routing Directorate, please see
https://wiki.ietf.org/en/group/rtg/RtgDir

Document: draft-ietf-bess-evpn-fast-df-recovery-07.txt
Reviewer: Adrian Farrel
Review Date: 2023-05-27
Intended Status: Standards Track

Summary:

I have some minor concerns about this document that I think should be resolved
before it is submitted to the AD.

This document is short and readable. While most of what I found is nits, they
somewhat detract from the clarity of the document. The minor points could do
with small additions to the text to help the reader and smooth the document's
passage through the IESG.

===

Abstract should note that this document updates RFC 8584 and say
(briefly) how. (Note that idnits warned you about this.)

I would put similar text in the Introduction, but that text can have a
pointer to Section 2.2).

I note that the topic of "updates" was raised by matthew in his review,
and that 2.2 is clear about the changes. I note, however, that the
decision to make this an Update happened after WG last call, and I
wonder whether the owrking group is fully on board with the implication
that any future implementation claiming conformance to 8584 will be
required to implement this specification. There is a difference between
an Update and an additional procedure.

---

Abstract

Move "(DF)" to the first use of "Designated Forwarder"

Please expand "EVI" and "PE"

s/via a simple signaling/via simple signaling/

---

Move the requirements language into a new Section 1.1

Please use the correct version of the boilerplate text...

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

---

1.

Please expand "DF", "EVI", and "PE" on first use.

s/applying Highest/applying the Highest/
s/independent of number/independent of the number/
s/via a simple signaling/via simple signaling/
s/on simple one-way signaling/on a simple one-way signaling/

---

1.2

s/in redundancy group/in a redundancy group/

---

1.2

The RFC Editor will ask you to consider another term in place of
"blackholing". You might choose to retain the term, or you might
think that it is OK to say "packets being dropped if the timer is
too long"

There are quite a few similar uses throughout the document.

---

1.2

   upon re-entry of the packet

I think you mean, "upon the packet re-entering the Ethernet Segment"

---

1.3.

This section is a bit messy because it talks about the "proposed
solution" in text that will eventually become an RFC, and because it
makes cryptic references to mechanisms that have not yet been described.

I am not convinced that you actually need this text (why are you trying
to sell the benefits having already told us there is a problem to be
solved?) but if you want to keep the text, I would suggest that you
position it as "design principles" and scale it right back. Something
like...

1.3.  Design Priniciples for a Solution

   The solution presented in this document follows several design
   pronciples as follows.

   *  Complicated handshake signamling mechanisms and state machines are
  avoided in favor of a simple uni-directional signaling approach.

   *  The solution is backwards-compatible (see Section 4).

   *  Existing DF Election algorithms are supported.

   *  The solution is independent of any BGP delays in propagation of
  Ethernet Segment routes (Route Type 4).

   *  The solution is agnostic of the actual time synchronization
  mechanism used.

---

2.

s/participating to a common/participating in a common/
s/at a same pre-announced time/at the same pre-an

[bess] Heads up on draft-ietf-opsawg-yang-vpn-service-pm

[Adrian Farrel]

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 comments you have at any
time.

Best,
Adrian

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

[bess] draft-lp-bess-vpn-interworking

[Adrian Farrel]

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 Behalf Of
internet-dra...@ietf.org
Sent: 03 January 2022 06:35
To: i-d-annou...@ietf.org
Subject: I-D Action: draft-lp-bess-vpn-interworking-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.


Title   : A Label/SID Allocation Method for VPN Interworking
Authors : Yao Liu
  Shaofu Peng
Filename: draft-lp-bess-vpn-interworking-00.txt
Pages   : 9
Date: 2022-01-02

Abstract:
   This document analyzes the SRv6-MPLS service interworking solution
   and offers an MPLS label or SRv6 SID allocation method for label/SID
   saving and better scalability purpose.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-lp-bess-vpn-interworking/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-lp-bess-vpn-interworking-00.html

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

[bess] FW: WG LC: L2 Network model (opsawg)

[Adrian Farrel]

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-ietf-opsawg-l2nm. 
This is a network model (see RFC8969) that works in conjunction with
service models (i.e., L2SM) and underlying device models for configuring
L2 VPNs.  L2SM members, having the view of the upper-level work, should
have some good insights into this work.

The WG LC is ongoing until October 1.  If you could, please read through
this work and comment on opsawg@.

See
https://mailarchive.ietf.org/arch/msg/opsawg/9LVwY142JC9V16TseZdZE4kij84/
for
the initial WGLC on opsawg.

Thanks.

Joe

___
L2sm mailing list
l...@ietf.org
https://www.ietf.org/mailman/listinfo/l2sm

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

Re: [bess] Benjamin Kaduk's No Objection on draft-ietf-bess-datacenter-gateway-12: (with COMMENT)

[Adrian Farrel]

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 are in
> place to prevent an attacker outside of a site from spoofing an
> auto-discovery route with a given site's site identifier.  (The security
> considerations already dutifully considers the case of a node in the
> site that is not a gateway being able to falsify an auto-discovery
> route.)  As far as I can tell this is not an issue because nodes in the
> site will not accept auto-discovery routes that initiate from outside
> the site, based on configured knowledge of whether a given BGP peering
> is internal or external.  The document already makes some allusions to
> this by specifying that the actual tunnel encapsulation with the union
> of all GWs' data is only included in "every route advertised externally
> to that site", implying that the auto-discovery routes are on the
> non-external (i.e., internal) advertisements.  It might (or might not)
> be worth being more explicit about auto-discovery only occuring
> internally within a site, to clarify this mechanism of action.

Per other email. Since I have suggested text I'll make the change.

> NITS
>
> Section 1
>
>   Data centers (DCs) are critical components of the infrastructure used
>   by network operators to provide services to their customers.  DCs
>   (sites) are interconnected by a backbone network, which consists of
>   any number of private networks and/or the Internet, by gateway
>   routers (GWs).  [...]
>
> This currently looks like "interconnected by  (...), by " which
> doesn't seem right.  Maybe end the sentence after "and/or the Internet"
> and finish with "Each DC is connected to the backbone by one or more
> gateway routers (GWs)"?

Yeh, that was garbled.

>   The solution described in this document is agnostic as to whether the
>   transit ASes do or do not have SR capabilities.  the solution uses SR
>   to stitch together path segments between GWs and through the ASBRs.
>
> Start the sentence with a majuscule 'T'.

Ack

>   technique will experience scaling issues.  This all means that the
>   Add-Paths approach is limited to sites connected over a single AS.
>
> I'd consider "effectively limited"; we know that some groups/individuals
> have a high capacity for hitting themselves in the way that recursive
> Add-Path would entail.

Hmmm. Yes.

New version when I'm allowed to post it.

Cheers,
Adrian

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

Re: [bess] Benjamin Kaduk's Discuss on draft-ietf-bess-datacenter-gateway-11: (with DISCUSS and COMMENT)

[Adrian Farrel]

> 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 Tunnel TLV for that GW.
>>>
>>> I don't think I understand why each (egress) GW has to (re)compute
>>> the path through the site to X for each of the GWs at the site -- can't
>>> it just take the sub-TLV it got from the peer and re-propagate it?
>> 
>> Oh, it doesn't have to recompute it *if* it is present (i.e. if it got it 
>> from
>> the peer). But that part of the path might not be present (that is, the 
>> sub-TLV might not be present) because:
>> a. the ingress might not have visibility into the egress site beyond 
>> simple
>>  reachability 
>> b. the ingress might not care 
>> c. the ingress might want to let the egress site make subtle reactive
>> choices according to local conditions
>> IMHO it would be unusual for the tail end of the path to be specified in
>> this way.
>
> (Disclaimer: this is not an important topic and I'm happy to drop it for
> expediency if desired.)  I am not sure that my point came across as
> intended.  The text here seems to be about what the egress GW does when it
> advertises the "union of all tunnel encapsulation information" route
> externally.  My understanding/expectation was that each egress GW would be
> able to just take the bits it got from auto-discovery (internal) routes and
> squish them together.  As you note, the ingress may not care or need the
> details of the path within the egress site from GW to prefix X, and so I
> don't understand why the advertising egress GW would go to the trouble of
> computing a route from the other GWs in its site to prefix X.  If such a
> route was needed, the other GW in the site would be better placed to
> compute such a route and include it in the auto-discovery route anyway.

I think you may have misunderstood Section 5. 
Firstly, the case you are looking at is behind a cascaded "if".
But also, it doesn't say that each GW computes paths from each other gateway to 
the destination. It only says that each GW computes a path from itself to the 
destination. Each GW then encodes that path as MPLS SID stack, puts it in an 
MPLS label stack sub-TLV inside the SR tunnel TLV. And, of course, that means 
that when a GW advertises the reachability on behalf of the other GWs to the 
site, it will pick up those routes and advertise them as well.

>>> Section 6
>>>
>>> [The topic of which sites are allowed to send in the site's native 
>>> encapsulation seems
>>> related to questions of what an "SR Domain" is and what boundary security 
>>> it has.  I
>>> think that the other ADs are basically covering this topic, though, so am 
>>> not sure there
>>> is much more to say here.]
>>>
>>>   If the GWs for a given site are configured to allow remote GWs to
>>>   send them a packet in that site's native encapsulation, then each GW
>>>   will also include multiple instances of a Tunnel TLV for that native
>>>   encapsulation in externally advertised routes: one for each GW and
>>>   each containing a Tunnel Egress Endpoint sub-TLV with that GW's
>>>   address.  [...]
>>>
>>> Does this implicitly require that all the GWs of the site have the same 
>>> configuration
>>> for whether or not to allow native encapsulation from remote GWs?  How would
>>> things degrade if a mixed configuration did happen to occur?
>> 
>> This applies GW by GW since the tunnels lead to a GW, and the path has
>> selected the tunnels. So, the sender knows.
>> 
>> If a gateway is configured to not allow native encapsulation, then it will
>> receive packets in some other encapsulation that it does understand,
>> and it will convert them to the site's native encapsulation. 
>> 
>> Note that the GW is part of the site, so it really (really) needs to
>> understand the native encapsulation in the site!
>> 
>> Note also that (of course?) a GW that receives packets in an
>> encapsulation it doesn't understand (and hasn't advertised that it
>> understands) will drop the packets (just like any other data plane
>> node will discard packets with an unknown encapsulation).
>> 
>> Well, there is a case where a GW advertises that it understands
>> an encapsulation, but actually doesn't understand it. That is at
>> best a bug, and at worst a purchasing error.
>
> Okay.  So if there is an issue here at all (not entirely clear) it's just
> an editorial one about "the GWs for a given site" vs "any GWs for a given
> site", and "each GW" vs "each such GW" (or similar).

I'm pretty sure that the text is clear enough here. 
I suppose it is the site that is configured, and all gateways act the same way.
So we could have
   If a site is configured to allow remote GWs send packets to the site in
   the site's native encapsulation, then each GW to the site will also 
   

Re: [bess] Benjamin Kaduk's Discuss on draft-ietf-bess-datacenter-gateway-11: (with DISCUSS and COMMENT)

[Adrian Farrel]

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 
>> SHOULD consider using gateway-to-gateway encryption to
>
> "SHOULD consider"?  We're not even bold enough to go with just SHOULD?

I find this aspect of IETF Security considerations hard. Maybe I have a 
philosophical problem.
You might tell your child or another vulnerable person that they "SHOULD carry 
their money in a safe place". But with an adult one usually points out the 
risks and says that they "SHOULD consider carrying their money in a safe place."

>>protect the data center traffic.  Additionally, due consideration SHOULD 
>> be given to encrypting end-to-end traffic as it
>>would be for any traffic that uses a public or untrusted network for 
>> transport.
>
> I am thinking that I might be in a similar situation as Warren: my
> recollection from when we processed 8402 is that nodes remotely connected
> to each other would be using secure tunnels that provide at least as much
> protection as the "secure physical network" within the local domain. 

I really don't want to be painted as someone who supports every word of 8402, 
but...

The essence of 8402 is that intervening transit nodes do not need to be 
tunnelled past.

Consider, for example, how SRv6 packets may be forwarded across regular IPv6 
(i.e., not SRv6-capable) routers. The sending SRv6 router sets the IPv6 
destination address to the address of the receiving SRv6 router, updates the 
SRH (which is just an IPv6 extension header), and forwards the packet. The 
transit routers simply forward the packet as an IPv6 packet without even being 
aware that there is an SRH present. Only when the packet arrives at the 
receiving SRv6 router (which sees itself in the IPv6 destination field) is SRv6 
actioned. Thus, there may be a "logical tunnel" between remotely connected SRv6 
nodes, but there is no tunnelling technology used. Thus, the protection is 
weaker than in a secure physical network.

Now, you and I might argue that this gives a strong incentive to use a secure 
tunnelling technology between remotely connected SR nodes. That is, however, 
hard for the sender to enforce for remote (sic) remotely connected nodes. Hence 
the consideration of GW-to-GW encryption. 

The proponents of 8402 might argue that SR is a forwarding technology and so it 
is no different to IP: it is up to the applications to decide whether the 
underlying network is safe. Thus, if a service provider decides to use SR 
inside their network, it has no additional security considerations over the 
same provider using IP inside their network.

> With
> that background, I would have gone with MUSTs here, but I am not at the
> moment finding much in 8402 to strongly support that as a requirement.

Well, I could go with "MUST consider" and "consideration MUST be given". That 
directs thought, but not action.

>>> COMMENT:
>>> 
>>>
>>> The Abstract is perhaps pushing the bounds of reasonable length for an 
>>> abstract. 
>> 
>> The Style Guide recommends 25 lines or fewer. We have 18 lines of text.
>
> Er, which style guide?  I'm not seeing much in RFC 7322 ... and
> https://www.rfc-editor.org/policy.html#policy.abstract (which admittedly
> does say it has been replaced by https://www.rfc-editor.org/styleguide/)
> puts the cap at 20, with 5-10 being "typical".

Oh, I apologise. 
Either my memory is faulty or this section has been updated over the last 
twenty years.
Anyway, "cap at 20" tells us what to do.

[snip]

>> NEW
>>Data centers are attached to the Internet or a backbone network by
>>gateway routers.  One data center typically has more than one gateway
>>for commercial, load balancing, and resiliency reasons.  Other sites,
>>such as access networks, also need to be connected across backbone
>>networks through gateways.
>> 
>>This document defines a mechanism using the BGP Tunnel Encapsulation
>>attribute to allow data center gateway routers to advertise routes to the 
>>prefixes reachable in the site, including advertising them on behalf of 
>>other gateways at the same site.  This allows segment routing to be used
>>to identify multiple paths across the Internet or backbone network 
>>between different gateways.  The paths can be selected for load-balancing,
>>resilience, and quality purposes.   
>> END
>
> Thanks, this is an improvement over the OLD version.

And only 12 lines 

>>> Section 1
>>>
>>>   The solution described in this document is agnostic as to whether the
>>>   transit ASes do or do not have SR capabilities.  the solution uses SR
>>>   to stitch together path segments between GWs and through the ASBRs.
>>>   Thus, there is a 

Re: [bess] Roman Danyliw's Discuss on draft-ietf-bess-datacenter-gateway-10: (with DISCUSS and COMMENT)

[Adrian Farrel]

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 the source-based routing model …
>>
>> (a.1) “These nodes may be connected to the same physical infrastructure
>> (e.g., a Service Provider's network).”
>>
>> (a.2) “They may as well be remotely connected to each other (e.g., an 
>> enterprise VPN or an overlay).”
>>
>> (b) “By default, SR operates within a trusted domain.  Traffic MUST be 
>> filtered at the domain boundaries.”
>>
>> My understanding of this document is that it is an enabling capability
>> to help establish SR domains of the like described in (a.2).  What I see
>> missing is text that provides the confidence suggested by the language
>> of “trusted domain” in (b).
>
> So, recalibrating to the whole "we meant site when we said domain"
> thing in many of the conversations with other ADs...

Note that -11 has moved over to the "site" terminology. I believe this 
substantially helps clarify the contrast between an 8402 "SR domain" (the 
collection of all participating SR nodes), and "site" (the end networks akin to 
VPN sites).

> You're right. This document provides a mechanism for connecting participating
> nodes that are remote.
>
> I never understood, "By default, SR operates within a trusted domain." To me
> that reads like, "If you want to, you can configure your domain to be 
> untrusted"
> as if that is something someone might choose to do when they have the option
> of a trusted domain. But I digress!
>
> I am not sufficiently a security expert to know what language would provide
> confidence. And, actually, I'm not quite sure what the question is. Are you
> asking "What stops a rogue gateway advertising itself, effectively 
> impersonating
> a site in the SR domain?"

So, please look at the Security considerations section in -11. But also have a 
skim of the response to Ben just sent. I think this may also help with your 
Discuss because it adds some clarity on trusted domains. In particular, the 
domains (ASes) between GWs and ASBRs are tunnels, and encryption can be run 
over tunnels. Further, GW-to-GW encryption can be used. And, lastly, end-to-end 
encryption can be used.

> To continue...
>
>> -- Section 1 hints at various VPN technologies perhaps being used  “The 
>> various
>> ASes that provide connectivity between the Ingress and Egress   Domains could
>> each be constructed differently and use different technologies such as IP, 
>> MPLS
>> with global table routing native BGP to the edge, MPLS IP VPN, SR-MPLS IP 
>> VPN,
>> or SRv6 IP VPN.”  However, the security properties of all of those aren’t 
>> clear
>> to a degree that would seem consistent with being a “trusted domain”.  For
>> example, saying “IP” might suggest that naked IP packets with SR headers 
>> (with
>> no additional security primitives) could be dropped onto the open Internet, 
>> or
>> at least through networks not under the control the “data centers” use case
>> suggested by the name of the document.
>
> I would have thought the security properties of the routing protocol (in this 
> case
> BGP) more important than the properties of the core network data plane 
> protocols. 

As above: tunnels and encryption.
But...

> I wonder whether there is a misconception of the applicability of SR in the 
> wider
> Internet, and the definition of "SR domain" from 8402. For example, in SRv6, 
> the
> SR nodes may form part of a trusted domain, but the packets are just IP 
> packets
> that happen to carry an SRH, so the packets can be (and are!) forwarded 
> through
> a native IP network. This is a form of tunnelling (because the SRH is not 
> examined
> except at the addressed destination), but the packets are "out there".
>
> But back to the VPN model. The VPN sites may run a proprietary protocol that
> could be considered dangerous if released to the Internet. The VPN sites form
> a trusted domain because they will not leak that protocol into the Internet.
> However, the VPN shares packets across the Internet by tunnelling them. The 
> VPN can be supported by a whole host of tunnelling protocols (MPLS, IPsec,
> GRE, IP-in-IP, etc.). All of these tunnelling mechanisms rely on:
> - the integrity of the tunnels 
> - the security of the routing protocol used to determine the tunnel end points
> - the security of the signaling protocols used to establish the tunnels
> - the security of the routing protocols used to determine the site membership
> But the core network does not form part of the trust domain.
>
> Except! In a multi-AS case, the ASBRs are tunnel end points (or tunnel 
> stitching
> points) and do participate in the trust model.
>
> Now I have to ask: in what way is what we are suggesting different from the
> multi-AS VPN trust model?
>
>> -- The discussion at

Re: [bess] Benjamin Kaduk's Discuss on draft-ietf-bess-datacenter-gateway-11: (with DISCUSS and COMMENT)

[Adrian Farrel]

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 and updating the document
> already; I benefitted a lot from being able to read the -11 that has
> started rolling in fixes from the prior discussion.  My one new discuss
> point is relatively minor, all things considered, and is really just
> trying to nail down an aspect of internal consistency.  (I also support
> Roman's discuss, but we don't need to rehash that here.)

But, FWIW, I think addressing your Discuss and one of your Comments, will 
further help Roman.

> When we introduce the concept of gateways, we say that they can be
> attached to the Internet or a backbone network.  We then go on to
> provide a mechanism for gateways to advertise to some tunnel ingress
> node the complete set of gateways for a given site.  It seems that we
> do fairly consistently refer to this advertisement as being over "the
> backbone network", but I'm not seeing anything that clearly disclaims
> the applicability of this technique over the Internet itself.  However, I
> think we need to have such a disclaimer, since we do have a clearly
> stated assumption that "the connected set of DCs *and the backbone
> network connecting them* are part of the same SR BGP Link State (LS)
> instance ([RFC7752] and [I-D.ietf-idr-bgpls-segment-routing-epe])"
> (emphasis mine).  If the intent is to only use this mechanism over 
> "in-BGP-LS-instance" backbones and not over the Internet, we should
> explicitly set the scope of applicability and contrast a gateway as a
> generic concept and the gateway scenarios that this mechanism
> applies to.

It's actually very common to interconnect sites using a combination of private 
networks and the Internet 
(https://www.networkworld.com/article/3031279/sd-wan-what-it-is-and-why-you-ll-use-it-one-day.html).
 We use the term "backbone network" as a sort of shorthand and we don't mean to 
preclude use of private networks or of the Internet. We can clarify this 

We will change a sentence in the first paragraph 
OLD
   DCs are attached to the Internet or a backbone network by gateway routers
NEW
  DCs (sites) are interconnected by a backbone network, which consists of any
  number of private networks and/or the Internet, by gateway routers
END

The tunnels that interconnect any pair of ASBRs or GWs appear in the BGP-LS 
instance as links. The transit nodes in the "backbone network" do not show up 
in that BGP-LS instance.

What is important (and we missed) is that the tunnels that run across 
"untrusted networks" should be secure tunnels. We'll make this clear with an 
additional paragraph in the Security considerations as follows:

 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 SHOULD 
consider using gateway-to-gateway encryption to
protect the data center traffic.  Additionally, due consideration 
SHOULD be given to encrypting end-to-end traffic as it
would be for any traffic that uses a public or untrusted network for 
transport.

> COMMENT:
> 
>
> The Abstract is perhaps pushing the bounds of reasonable length for an 
> abstract. 
> Perhaps:
>
> % This document defines a mechanism using the BGP Tunnel Encapsulation
> % attribute to allow datacenter gateway routers to advertise routes to the 
> % prefixes reachable in the site, including advertising them on behalf of 
> % other gateways at the same site.  This allows for multiple paths across 
> % the Internet or backbone (terminating at the different gateways) to be
> % used by segment routing to steer traffic for load-balancing and
> % resiliency purposes.

The Style Guide recommends 25 lines or fewer. We have 18 lines of text.

Perhaps we can compromise a bit. We need to mention the fact that a site may 
have more than one gateway because that is an important part of the problem 
that needs to be solved. That takes us to:

OLD
   Data centers are critical components of the infrastructure used by
   network operators to provide services to their customers.  Data
   centers are attached to the Internet or a backbone network by gateway
   routers.  One data center typically has more than one gateway for
   commercial, load balancing, and resiliency reasons.

   Segment Routing is a protocol mechanism that can be used within a
   data center, and also for steering traffic that flows between two
   data center sites.  In order that one data center site may load
   balance the traffic it sends to another data center site, it needs to
   know the complete set of gateway routers at the remote data center,
   the points of 

Re: [bess] Murray Kucherawy's No Objection on draft-ietf-bess-datacenter-gateway-11: (with COMMENT)

[Adrian Farrel]

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 sentence. Probably "can be protected against".

Cheers,
Adrian



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

Re: [bess] New Version Notification for draft-ietf-bess-datacenter-gateway-11.txt

[Adrian Farrel]

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...@ietf.org' 

Subject: FW: New Version Notification for 
draft-ietf-bess-datacenter-gateway-11.txt

Hi all,

This revision attempts to address John Scudder's Discuss and Comment including 
changes discussed by email and in person (by John Drake). It also addresses the 
updated version of Gyan's GenArt review comments, incorporating most of the 
changes he suggested in his most recent email. Thanks to John (S) and Gyan for 
the amount of time and effort they spent reaching resolutions with the authors 
- a long and somewhat bumpy road, but a better document as a result.

No changes are made for Roman's Discuss (see recent email).

I believe that Warren's Discuss is also addressed partly by answering John's 
Discuss, but also by the change of terminology to "site" from the incorrect "SR 
domain".

As noted in email, this revision fixes one grammar point (a missing comma) and 
fixes the two out-dated references pointed out in Lars' Comment.

Per email, Erik and Alvaro's Comments are addressed by the change in 
domain/site terminology.

I think the actionable parts of Eric's Comment is also handled with the text 
change suggested in email.

Lastly, I think Rob's Comment has been closed through email.


Please let us 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 Jalil 

Subject: New Version Notification for draft-ietf-bess-datacenter-gateway-11.txt


A new version of I-D, draft-ietf-bess-datacenter-gateway-11.txt
has been successfully submitted by Adrian Farrel and posted to the
IETF repository.

Name:   draft-ietf-bess-datacenter-gateway
Revision:   11
Title:  Gateway Auto-Discovery and Route Advertisement for Segment 
Routing Enabled Site Interconnection
Document date:  2021-05-19
Group:  bess
Pages:  13
URL:
https://www.ietf.org/archive/id/draft-ietf-bess-datacenter-gateway-11.txt
Status: 
https://datatracker.ietf.org/doc/draft-ietf-bess-datacenter-gateway/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-bess-datacenter-gateway
Htmlized:   
https://tools.ietf.org/html/draft-ietf-bess-datacenter-gateway-11
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-datacenter-gateway-11

Abstract:
   Data centers are critical components of the infrastructure used by
   network operators to provide services to their customers.  Data
   centers are attached to the Internet or a backbone network by gateway
   routers.  One data center typically has more than one gateway for
   commercial, load balancing, and resiliency reasons.

   Segment Routing is a protocol mechanism that can be used within a
   data center, and also for steering traffic that flows between two
   data center sites.  In order that one data center site may load
   balance the traffic it sends to another data center site, it needs to
   know the complete set of gateway routers at the remote data center,
   the points of connection from those gateways to the backbone network,
   and the connectivity across the backbone network.

   Other sites, such as access networks, also need to be connected
   across backbone networks through gateways.

   This document defines a mechanism using the BGP Tunnel Encapsulation
   attribute to allow each gateway router to advertise the routes to the
   prefixes reachable in the site to which it provides access, including
   advertising them on behalf of each other gateway to the same site.


  


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] FW: New Version Notification for draft-ietf-bess-datacenter-gateway-11.txt

[Adrian Farrel]

Hi all,

This revision attempts to address John Scudder's Discuss and Comment including 
changes discussed by email and in person (by John Drake). It also addresses the 
updated version of Gyan's GenArt review comments, incorporating most of the 
changes he suggested in his most recent email. Thanks to John (S) and Gyan for 
the amount of time and effort they spent reaching resolutions with the authors 
- a long and somewhat bumpy road, but a better document as a result.

No changes are made for Roman's Discuss (see recent email).

I believe that Warren's Discuss is also addressed partly by answering John's 
Discuss, but also by the change of terminology to "site" from the incorrect "SR 
domain".

As noted in email, this revision fixes one grammar point (a missing comma) and 
fixes the two out-dated references pointed out in Lars' Comment.

Per email, Erik and Alvaro's Comments are addressed by the change in 
domain/site terminology.

I think the actionable parts of Eric's Comment is also handled with the text 
change suggested in email.

Lastly, I think Rob's Comment has been closed through email.


Please let us 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 Jalil 

Subject: New Version Notification for draft-ietf-bess-datacenter-gateway-11.txt


A new version of I-D, draft-ietf-bess-datacenter-gateway-11.txt
has been successfully submitted by Adrian Farrel and posted to the
IETF repository.

Name:   draft-ietf-bess-datacenter-gateway
Revision:   11
Title:  Gateway Auto-Discovery and Route Advertisement for Segment 
Routing Enabled Site Interconnection
Document date:  2021-05-19
Group:  bess
Pages:  13
URL:
https://www.ietf.org/archive/id/draft-ietf-bess-datacenter-gateway-11.txt
Status: 
https://datatracker.ietf.org/doc/draft-ietf-bess-datacenter-gateway/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-bess-datacenter-gateway
Htmlized:   
https://tools.ietf.org/html/draft-ietf-bess-datacenter-gateway-11
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-datacenter-gateway-11

Abstract:
   Data centers are critical components of the infrastructure used by
   network operators to provide services to their customers.  Data
   centers are attached to the Internet or a backbone network by gateway
   routers.  One data center typically has more than one gateway for
   commercial, load balancing, and resiliency reasons.

   Segment Routing is a protocol mechanism that can be used within a
   data center, and also for steering traffic that flows between two
   data center sites.  In order that one data center site may load
   balance the traffic it sends to another data center site, it needs to
   know the complete set of gateway routers at the remote data center,
   the points of connection from those gateways to the backbone network,
   and the connectivity across the backbone network.

   Other sites, such as access networks, also need to be connected
   across backbone networks through gateways.

   This document defines a mechanism using the BGP Tunnel Encapsulation
   attribute to allow each gateway router to advertise the routes to the
   prefixes reachable in the site to which it provides access, including
   advertising them on behalf of each other gateway to the same site.


  


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

Re: [bess] Roman Danyliw's Discuss on draft-ietf-bess-datacenter-gateway-10: (with DISCUSS and COMMENT)

[Adrian Farrel]

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 infrastructure
> (e.g., a Service Provider's network).”
>
> (a.2) “They may as well be remotely connected to each other (e.g., an 
> enterprise VPN or an overlay).”
>
> (b) “By default, SR operates within a trusted domain.  Traffic MUST be 
> filtered at the domain boundaries.”
>
> My understanding of this document is that it is an enabling capability
> to help establish SR domains of the like described in (a.2).  What I see
> missing is text that provides the confidence suggested by the language
> of “trusted domain” in (b).

So, recalibrating to the whole "we meant site when we said domain" thing in 
many of the conversations with other ADs...

You're right. This document provides a mechanism for connecting participating 
nodes that are remote.

I never understood, "By default, SR operates within a trusted domain." To me 
that reads like, "If you want to, you can configure your domain to be 
untrusted" as if that is something someone might choose to do when they have 
the option of a trusted domain. But I digress!

I am not sufficiently a security expert to know what language would provide 
confidence. And, actually, I'm not quite sure what the question is. Are you 
asking "What stops a rogue gateway advertising itself, effectively 
impersonating a site in the SR domain?"

To continue...

> -- Section 1 hints at various VPN technologies perhaps being used  “The 
> various
> ASes that provide connectivity between the Ingress and Egress   Domains could
> each be constructed differently and use different technologies such as IP, 
> MPLS
> with global table routing native BGP to the edge, MPLS IP VPN, SR-MPLS IP VPN,
> or SRv6 IP VPN.”  However, the security properties of all of those aren’t 
> clear
> to a degree that would seem consistent with being a “trusted domain”.  For
> example, saying “IP” might suggest that naked IP packets with SR headers (with
> no additional security primitives) could be dropped onto the open Internet, or
> at least through networks not under the control the “data centers” use case
> suggested by the name of the document.

I would have thought the security properties of the routing protocol (in this 
case BGP) more important than the properties of the core network data plane 
protocols. 

I wonder whether there is a misconception of the applicability of SR in the 
wider Internet, and the definition of "SR domain" from 8402. For example, in 
SRv6, the SR nodes may form part of a trusted domain, but the packets are just 
IP packets that happen to carry an SRH, so the packets can be (and are!) 
forwarded through a native IP network. This is a form of tunnelling (because 
the SRH is not examined except at the addressed destination), but the packets 
are "out there".

But back to the VPN model. The VPN sites may run a proprietary protocol that 
could be considered dangerous if released to the Internet. The VPN sites form a 
trusted domain because they will not leak that protocol into the Internet. 
However, the VPN shares packets across the Internet by tunnelling them. The VPN 
can be supported by a whole host of tunnelling protocols (MPLS, IPsec, GRE, 
IP-in-IP, etc.). All of these tunnelling mechanisms rely on:
- the integrity of the tunnels 
- the security of the routing protocol used to determine the tunnel end points
- the security of the signaling protocols used to establish the tunnels
- the security of the routing protocols used to determine the site membership
But the core network does not form part of the trust domain.

Except! In a multi-AS case, the ASBRs are tunnel end points (or tunnel 
stitching points) and do participate in the trust model.

Now I have to ask: in what way is what we are suggesting different from the 
multi-AS VPN trust model?

> -- The discussion at
> https://mailarchive.ietf.org/arch/msg/bess/zY783PgnXSCp6GNSRF4kY0diLYs/ around
> the forwarding plane trust model is also informative.   It is noted that that
> the “transit nodes of the AS are not part of the domain.”  I could agree, but
> only to the degree that the SR packets are tunneled in such as way that
> suggested a trusted domain at least of equal security as (a.1).

So, a tunnel is not as secure as a physical link. Indeed, a router is not as 
secure as a physical link. Yet we route traffic and use tunnels.

I am obviously not seeing the problem!

How do networks stop traffic from being injected into tunnels? Largely 
speaking, they do it by noting that traffic from outside the network is not 
allowed to enter the network using tunnel addresses (or encapsulations). Why is 
what we are describing any different from any type of tunnelling technology?

Or maybe "trusted domain" means an entirely different thing to 

Re: [bess] Robert Wilton's No Objection on draft-ietf-bess-datacenter-gateway-10: (with COMMENT)

[Adrian Farrel]

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?  If so, is there a YANG data model in the works that will
> cover this functionality?  Having an informational reference to the data model
> may be helpful to readers.

It is hard to predict the expectations in this regard.
CLI, TL/1, YANG, DHCP?

I think that in the fullness of time, if the approach described in this 
document takes off, then I would expect to see YANG management available.
At the moment, however, I'm not aware of any work (presumably to augment BGP 
and/or SR models), so nothing to point at.

Compare and contrast with how VPN IDs are configured, and how long we lived 
with VPNs before we had a "standard" way to configure them.

Cheers,
Adrian

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

Re: [bess] [Last-Call] Genart last call review of draft-ietf-bess-datacenter-gateway-10

[Adrian Farrel]

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

Re: [bess] Warren Kumari's Discuss on draft-ietf-bess-datacenter-gateway-10: (with DISCUSS)

[Adrian Farrel]

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 will reach a 
resolution that satisfies him.

> when SR was "approved" it was with the understanding that it
> would only be used within "real" limited domains, and would never be sent
> outside of closed/limited network.

I fear that there may have been some slipperiness in the discussion that led to 
this understanding.
I recall pushing back quite a bit on the definition of "SR domain" as it 
appeared in 8402 during IETF last call. But I didn't see a lot of support for 
my view and concluded I was in the rough.

He definition we ended up with specifically allows for tunnelling of SR over 
non-SR parts of the network. And, indeed, the nature of SRv6 is that packets 
containing the SRH may be forwarded "transparently" by non-SR IPv6 routers. The 
domain is, therefore, defined as the collection of interconnected SR-capable 
nodes. We ended up with:

   Segment Routing domain (SR domain): the set of nodes participating in
   the source-based routing model.  These nodes may be connected to the
   same physical infrastructure (e.g., a Service Provider's network).
   They may as well be remotely connected to each other (e.g., an
   enterprise VPN or an overlay).

This may go against your expectations (it may even go against reasonable 
expectations), but it is what it is.

In the light of this, and with the understanding of how overlays are built and 
used (especially for VPNs), we explicitly looked in this document to provide a 
simple way that SR-capable sites may be interconnected using a concatenation of 
tunnels between SR-capable nodes in the wider network. As you'll see from the 
document, this doesn't involve any changes to SR, but does make use of SR's 
ability to use a SID to identify a node or a tunnel. Our only new stuff is to 
allow BGP to distribute information in a way that handles a site having 
multiple gateways and to cope with multiple possible paths between sites. If an 
ASBR (BGP peer) is unable to process the BGP extensions or is not SR-capable, 
it will not participate.

> The document says: "The solution defined in this document can be seen in the
> broader context of SR domain interconnection in
> [I-D.farrel-spring-sr-domain-interconnect]. ", which says: " Traffic
> originating in one SR domain often terminates in another SR domain, but must
> transit a backbone network that provides interconnection between those
> domains." -- is it unclear to me if this is really what is being proposed...

Again (as per the many discussions during IESG review), s/domain/site/
That was a bad mistake by the authors (who really love the use of the word 
'domain' as applied in all of the TEAS work).
To be clear, all interconnected SR sites form part of the same 8402-SR-domain.

We have fixed the use of site/domain in the working copy (which we hope to post 
later today).

> I'm hoping that I'm really misunderstanding something here -- please educate 
> me.

Do you consider yourself educated now, or merely disciplined? 

Cheers,
Adrian

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

Re: [bess] Alvaro Retana's No Objection on draft-ietf-bess-datacenter-gateway-10: (with COMMENT)

[Adrian Farrel]

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 value set to the SR domain identifier."  This
> is a significant change to the SR architecture.
>
> In line with the general use of the mechanism in this document (from John's
> DISCUSS), I believe it is unnecessary to add anything new to the SR
> architecture.  Instead, the term could be changed to simply "local domain
> identifier" (or something like that).

This ties into other comments on the thread: we should have used the term 
"site" not "domain" as the meaning of "SR domain" is already nailed down in 
8402.
An almost global change of "domain" to "site" will be made in -11.
While this doesn't change the casualness or otherwise of the document, it does 
prevent any changes to the SR architecture.

Cheers,
Adrian

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

Re: [bess] Erik Kline's No Objection on draft-ietf-bess-datacenter-gateway-10: (with COMMENT)

[Adrian Farrel]

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 
but which have tunnels between them, even including regular IP forwarding 
without inspection of the SRH (the IP nodes are not in the domain, but the 
segment end points are).

Our use of "domain" was broken in this view of the world and we are fixing it.
We will use the word "site" to describe the end locations (such as DCs) in a 
way that models the naming for VPNs.

In an 8402 context, all interconnected sites are part of the same SR domain.

Thus, I think, the question of filtering at the domain boundary is unchanged.

Thanks,
Adrian
-Original Message-
From: Erik Kline via Datatracker  
Sent: 18 May 2021 07:24
To: The IESG 
Cc: draft-ietf-bess-datacenter-gate...@ietf.org; bess-cha...@ietf.org; 
bess@ietf.org; Matthew Bocci ; matthew.bo...@nokia.com
Subject: Erik Kline's No Objection on draft-ietf-bess-datacenter-gateway-10: 
(with COMMENT)

Erik Kline has entered the following ballot position for
draft-ietf-bess-datacenter-gateway-10: 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 DISCUSS and COMMENT positions.


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



--
COMMENT:
--

[[ comments ]]

[ section 8 ]

* My understanding is that this will allow a packet from "Ingress" with an
  SRH that includes SRv6 SIDs associated with either GW1 or GW2 in "Egress".

  RFC 8754 (sections 5.1 and 7) discusses the necessity to filter SRH packets
  at the SR domain ingress point.  If my understanding above is correct, I
  think it could be more clear that deliberately not filtering SRH at the
  domain boundaries is a choice being made here which, further, may have
  consequences of the sort described in RFC 5095.

  But maybe I've misunderstood.



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

Re: [bess] Éric Vyncke's No Objection on draft-ietf-bess-datacenter-gateway-10: (with COMMENT)

[Adrian Farrel]

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 problems, see below). Is there some reason you
>> rule out interconnecting domains using other tunneling technologies? I ask 
>> this
>> question first because if the answer were to be “oh huh, we don’t need to 
>> make
>> this SR-specific after all” some of the other things I’m asking about might 
>> go
>> away.
>
> I'm sorry this isn't clear, but the use of other tunnelling technologies is 
> very much
> in scope. As the Introduction says:
>
>   The
>   various ASes that provide connectivity between the Ingress and Egress
>   Domains could each be constructed differently and use different
>   technologies such as IP, MPLS with global table routing native BGP to
>   the edge, MPLS IP VPN, SR-MPLS IP VPN, or SRv6 IP VPN.
>
> SR is used to identify the tunnels and provide end-to-end SR paths because the
> ingress and egress domains are SR domains, and the objective is to provide an
> end-to-end SR path.
>
> So we are not "making this SR aware" so much as enabling "SR-over-foo" using
> SIDs to identify the path segments that are tunnels.
>
> I don't know how to make this clearer except maybe using some red paint. We
> would write...
>
>   The
>   various ASes that provide connectivity between the Ingress and Egress
>   Domains could each be constructed differently and use different
>   technologies such as IP, MPLS with global table routing native BGP to
>   the edge, MPLS IP VPN, SR-MPLS IP VPN, or SRv6 IP VPN.  That is, the
>   Ingress and Egress SR Domains can be connected by tunnels across a
>   variety of technologies.  This document describes how SR identifiers
>   (SIDs) are used to identify the paths between the Ingress and Egress
>   and the techniques in this document apply to routes of all AFI/SAFIs.


| Please find below some non-blocking COMMENT points (but replies
| would be appreciated), and some nits.
|
| == COMMENTS ==
|
| -- Section 3 --
| How will the GW identifiers be unique across all interconnected SR domains ?
| Section 9 is rather hand waving.

There are two issues to be resolved:
1. How will all interconnected SR sites (formerly called domains) use different 
site identifiers?
2. How will all gateways to the same site consistently use the same identifier?

Just like the mechanisms used to assign many other things in networking (IP 
addresses, AS numbers, VPN IDs, ...) there may be many approaches available 
(dedicated protocols, piggy-backing on other protocols, management protocols, 
manual configuration).

Not sure why this spec needs to be responsible for defining those 
distribution/configuration/coordination mechanisms.

Section 9 makes it very clear what result must be achieved, and observes that 
we are not introducing a new problem to the BGP world.

Could we make it clearer that the operator is responsible for getting this 
right?

| -- Section 10 --
| Is there any reason why the doc shepherd is not acknowledged ?

Of course, we love our shepherd. 
Matthew, as WG chair, pushed the right people to do reviews, and also pushed 
the right buttons to advance the document.
As shepherd, Matthew wrote: I reviewed Version 8 of the draft. I have no 
significant comments on the draft. 

The Acknowledgements section historically thanks people whose comments have 
helped shape or improve the contents of the document.

| == NITS ==
|
| -- Section 1 --
| s/against connection of device failure/against connection or device failure/ ?

Ack

| I find the use of "ingress" in "source (ingress)" confusing, should the reader
| assume that it is "source (SR-domain ingress)" ?

Could write "source DC (also known as an ingress DC)"
Ditto destination/egress

Cheers,
Adrian


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

Re: [bess] John Scudder's Discuss on draft-ietf-bess-datacenter-gateway-10: (with DISCUSS and COMMENT)

[Adrian Farrel]

Hi John,

 

Trying to dismantle this…

 

We are saying that a site is integral. You are is asking : what happens if a 
site becomes partitioned so that some prefixes are accessible through one GW 
and some through another.

 

Consider a site with a set of prefixes S

Consider two GWs: GW1 and GW2

Initially GW1 and GW2 discover each other.

So GW1 advertises reachability to S, and by the way GW2 exists

GW2 advertises reachability to S, and by the way GW1 exists

Now the site becomes partitioned so that GW1 can reach S1 and GW2 can reach S2. 
(S = S1 U S2,  S1 n S2 = E)

 

You ask:

1.  What happens to packets for S2 arriving at GW1?
2.  What is the remedy in the protocol?

 

My answer to 1. is that the packets will be black-holed either at GW1 or inside 
the site.

My observation is that:

a.  GW1 cannot reach GW2 inside the site. If it could, then S2 would be 
reachable via GW1
b.  It is contrary to BCP38 for GW1 to forward a packet back into the 
external AS to be routed to GW2

 

My answer to 2. is that when the site becomes partitioned:

*   GW1 will stop advertising the whole of S and will fall back to 
advertising just S1
*   GW2 will stop advertising the whole of S and will fall back to 
advertising just S2
*   Initially, GW1 and GW2 will still advertise each other’s existence, but 
will “soon” un-auto-discover each other

At this point the site is effectively two sites that use the same site 
identifier.

 

How quickly this takes place depends on precisely what the failure case is, how 
fast the failure detection is done, and how fast BGP converges.  

 

*Perhaps* there is a wrinkle *if* the autodetection advertisements are sent 
external to the site. In this case, GW1 would continue to discover GW2 and so 
would readvertise it (and vice versa). This would continue to lead to the 
broken condition you noted. I think we assumed that the peering between GW1 and 
GW2 would be internal to the site (because otherwise it would constitute 
traffic leaving the site and re-entering it (breaking BCP38 again). If it would 
help, 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 Bocci 
Subject: Re: John Scudder's Discuss on draft-ietf-bess-datacenter-gateway-10: 
(with DISCUSS and COMMENT)

 

Having re-read Section 3 carefully (and skimmed the rest) I still think what 
the document says (as opposed to what’s in the authors’ heads?) is the first 
description I give below. Let me know if you want me to walk through my 
reasoning in detail with reference to the document. 

 

—John





On May 14, 2021, at 4:12 PM, John Scudder  wrote:

 Hi Adrian, 

 

Thanks for your reply. Pressed for time at the moment but one partial response:





On May 14, 2021, at 1:04 PM, Adrian Farrel mailto:adr...@olddog.co.uk> > wrote:

 

Agree with you that "stuff happens." I think that what you have described is a 
window not a permanent situation.
When GW2 knows it can't reach X any more, it will stop advertising X, and GW1 
will receive that and will update what it advertises on behalf of GW2.

 

Ah, perhaps I have badly misunderstood the way this works. I had thought it 
went something like this:

 

- GW1 knows it can reach GW2 because of GW2’s auto discovery route

- GW1 knows the set S of internal prefixes it can reach

- GW1 advertises each prefix from S with both GW1 and GW2 in the tunnel 
attribute

 

In the description above, there’s no notion of GW2 telling GW1 what internal 
prefixes GW2 can reach, or GW1 caring.  Now I suppose you are telling me that 
it goes:

 

- GW1 knows it can reach GW2 because of GW2’s auto discovery route

- GW1 knows the full set of prefixes GW2 can reach. _How does it know this?_

- GW1 constructs each advertisement listing only the correct set of gateways in 
the tunnel attribute

 

The key question is the one I’ve highlighted: how does GW1 come to know GW2’s 
internally-reachable prefixes? I didn’t notice any of this in the spec. Maybe 
it was just my sloppy reading, I’ll look again.





Further, if GW1 can no longer receive advertisements from GW2 then it will stop 
advertising on behalf of GW2.

 

Yes, that’s understood, but I was positing a case where just because GW1 can 
reach GW2 stably, and just because GW1 can reach X stably, it does not imply 
GW2 can reach X.

 

—John

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

Re: [bess] [secdir] Secdir last call review of draft-ietf-bess-datacenter-gateway-10

[Adrian Farrel]

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 considerations.)

I think I read as far as...

> Reviewer: Daniel Migault
> Review result: Ready
> 
> Hi,
> 
> Review result: Ready

...and stopped. No issues, no nits, come back to the clarifications later.
Sigh. Well, it is "later" so I'm on target.

> I reviewed this document as part of the Security Directorate's ongoing
effort
> to review all IETF documents being processed by the IESG.  These comments
were
> written primarily for the benefit of the Security Area Directors.
 However, in
> this case these comments mostly reflect some question to clarify my own
> understanding. Document authors, document editors, and WG chairs should
treat
> these comments just like any other IETF Last Call comments.
> 
> Yours,
> Daniel
> 
> Just to clarify my understanding of Fig 1. BGP usually selects the best
route,
> so if AS1-AS2 is the best, none of the traffic will go through AS3.
However
> even in this configuration AS2 will select one of the GW and all traffic
will
> go only to one of the GW1 or GW2. The Add-Path might be able to
distinguishes
> between AS1-AS2 and AS3 but AS1-AS2 cannot be subdivided between two paths
one
> that would terminates in GW1 and another that would terminates at GW2.

Right. 
What you stated is exactly the problem that we needed to resolve with this
document. The document explains the problem.
And, as you note (and the draft notes) Add-Path is only a solution in some
cases, but not in general.

> I am not sure following acronyms may be expanded as well as AFI/SAFI being
> described with text as opposed to their values. I let you decide whether
that
> is needed or not.

You're right. Mysteriously, AFI/SAFI are not listed as well-known at
https://www.rfc-editor.org/materials/abbrev.expansion.txt

1. I'll update the draft
2. I'll ping the RPC

> OLD:
>  An IPv4 or IPv6 NLRI containing one of the GW's loopback addresses
>       (that is, with an AFI/SAFI pair that is one of 1/1, 2/1, 1/4, or
>       2/4).
> 
> NEW
>  An IPv4 or IPv6 Network Layer Reachability Information (NLRI) [RFC4760]
>  containing one of the GW's loopback addresses (that is, with an Address
Family
>  Number (AFI)/ Subsequent Address Family (SAFI) pair that is one of
IPv4/NLRI
>  used for unicast forwarding (1/1), IPv6/NLRI used for unicast forwarding
>  (2/1), IPv4/NLRI with MPLS Labels (1/4), or IPv6/NLRI with MPLS Labels
(2/4)).

OK. Something like that will go in.

> Security consideration:
> 
> When the information is shared between the domains, I am wondering if the
> information is encrypted or if the communication appears in clear text. If
no
> encryption is used, that information is actually not limited to the two
domains
> but to anyone on path can read it. If that is the case, information
provided by
> the Egress SR domain to the Ingress SR Domain seems to me transiting
through
> the backbone which makes the information pretty much public. I am
wondering if
> I am missing something.

Maybe the current text in Section 8 is not clear enough on this point. Or
rather, it in oblique in its approach to this issue.
You are right on exactly this. It is the same problem as in a VPN -
information about the sites at the edge of the network is carried across the
network in BGP messages. Those messages could reveal the information unless
they are protected.

BGP is (of course) carried over TCP, and TCP can be protected. This is being
clarified in answer to one of the points John Scudder raised in his review.

Thanks,
Adrian



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

Re: [bess] John Scudder's Discuss on draft-ietf-bess-datacenter-gateway-10: (with DISCUSS and COMMENT)

[Adrian Farrel]

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 reason you
> rule out interconnecting domains using other tunneling technologies? I ask 
> this
> question first because if the answer were to be “oh huh, we don’t need to make
> this SR-specific after all” some of the other things I’m asking about might go
> away.

I'm sorry this isn't clear, but the use of other tunnelling technologies is 
very much in scope. As the Introduction says:

   The
   various ASes that provide connectivity between the Ingress and Egress
   Domains could each be constructed differently and use different
   technologies such as IP, MPLS with global table routing native BGP to
   the edge, MPLS IP VPN, SR-MPLS IP VPN, or SRv6 IP VPN.

SR is used to identify the tunnels and provide end-to-end SR paths because the 
ingress and egress domains are SR domains, and the objective is to provide an 
end-to-end SR path.

So we are not "making this SR aware" so much as enabling "SR-over-foo" using 
SIDs to identify the path segments that are tunnels.

I don't know how to make this clearer except maybe using some red paint. We 
would write...

   The
   various ASes that provide connectivity between the Ingress and Egress
   Domains could each be constructed differently and use different
   technologies such as IP, MPLS with global table routing native BGP to
   the edge, MPLS IP VPN, SR-MPLS IP VPN, or SRv6 IP VPN.  That is, the
   Ingress and Egress SR Domains can be connected by tunnels across a
   variety of technologies.  This document describes how SR identifiers
   (SIDs) are use to identify the paths between the Ingress and Egress
   and the techniques in this document apply to routes of all AFI/SAFIs.

> 2. There’s no discussion about what trust model you’re assuming. SR
> brings with it its own assumed trust model, laid out in RFC 8402 as “SR
> operates within a trusted domain” (whatever *that* means). On the one
> hand, given you’re tying yourself to SR you presumably are tied to its trust
> model. On the other hand, there are some tantalizing tidbits that suggest
> otherwise. I would be happier if there were some explicit description of
> the trust model you’re presuming. It’s hard to evaluate some aspects of
> the document without knowing if you’re assuming the RFC 8402 closed
> domain model, or something else.

I believe that the term "SR domain" in 8402 is basically defined as "a set of 
nodes that support SR". 
The description in (the ever-so-skimpy section 8 of 8402) says:

   By default, SR operates within a trusted domain.  Traffic MUST be
   filtered at the domain boundaries.

What does "by default" mean in that context? 

I think there are two things to think about:

1. Forwarding plane trust model. Can packets get into the SR system? The answer 
to that remains, "No, because traffic MUST be filtered at the domain 
boundaries." This requires that the domain boundary is the interface between an 
SR-capable node, and a non-SR node. In this document all GWs and ASBRs are part 
of the SR domain connected by tunnels across the transit ASes (although the 
nodes in the transit ASes are not part of that domain). I dare say that 
draft-farrel-spring-sr-domain-interconnect explains this better through 
examples, but the chairs of SPRING told us that that draft had no chance of 
progressing.

2. Control plane trust model. What is the trust model in the BGP system? I'm 
pretty sure that Section 8 of our draft is adequate for this discussion,.

> 3. The use of the term “SR domain” in this document appears inconsistent with
> its definition in RFC 8402. Here’s that definition, from §2:
>
>   Segment Routing domain (SR domain): the set of nodes participating in
>   the source-based routing model.  These nodes may be connected to the
>   same physical infrastructure (e.g., a Service Provider's network).
>   They may as well be remotely connected to each other (e.g., an
>   enterprise VPN or an overlay).  If multiple protocol instances are
>   deployed, the SR domain most commonly includes all of the protocol
>   instances in a network.  However, some deployments may wish to
>   subdivide the network into multiple SR domains, each of which
>   includes one or more protocol instances.  It is expected that all
>   nodes in an SR domain are managed by the same administrative entity.
>
> And notably, later in 8402 §8 we are told that
>
>   By default, SR operates within a trusted domain.  Traffic MUST be
>   filtered at the domain boundaries.
>
> Which specifically means, to take the MPLS instantiation of SR (§8.1):
>
>   SR domain boundary routers MUST filter any external traffic destined
>   to a label associated with a segment within the trusted domain.  This
>   includes labels within the SRGB 

Re: [bess] John Scudder's Discuss on draft-ietf-bess-datacenter-gateway-10: (with DISCUSS and COMMENT)

[Adrian Farrel]

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.org; bess-cha...@ietf.org; 
bess@ietf.org; Matthew Bocci ; matthew.bo...@nokia.com
Subject: John Scudder's Discuss on draft-ietf-bess-datacenter-gateway-10: (with 
DISCUSS and COMMENT)

John Scudder has entered the following ballot position for
draft-ietf-bess-datacenter-gateway-10: 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 DISCUSS and COMMENT positions.


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



--
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 reason you
rule out interconnecting domains using other tunneling technologies? I ask this
question first because if the answer were to be “oh huh, we don’t need to make
this SR-specific after all” some of the other things I’m asking about might go
away.

2. There’s no discussion about what trust model you’re assuming. SR brings with
it its own assumed trust model, laid out in RFC 8402 as “SR operates within a
trusted domain” (whatever *that* means). On the one hand, given you’re tying
yourself to SR you presumably are tied to its trust model. On the other hand,
there are some tantalizing tidbits that suggest otherwise. I would be happier
if there were some explicit description of the trust model you’re presuming.
It’s hard to evaluate some aspects of the document without knowing if you’re
assuming the RFC 8402 closed domain model, or something else.

3. The use of the term “SR domain” in this document appears inconsistent with
its definition in RFC 8402. Here’s that definition, from §2:

   Segment Routing domain (SR domain): the set of nodes participating in
   the source-based routing model.  These nodes may be connected to the
   same physical infrastructure (e.g., a Service Provider's network).
   They may as well be remotely connected to each other (e.g., an
   enterprise VPN or an overlay).  If multiple protocol instances are
   deployed, the SR domain most commonly includes all of the protocol
   instances in a network.  However, some deployments may wish to
   subdivide the network into multiple SR domains, each of which
   includes one or more protocol instances.  It is expected that all
   nodes in an SR domain are managed by the same administrative entity.

And notably, later in 8402 §8 we are told that

   By default, SR operates within a trusted domain.  Traffic MUST be
   filtered at the domain boundaries.

Which specifically means, to take the MPLS instantiation of SR (§8.1):

   SR domain boundary routers MUST filter any external traffic destined
   to a label associated with a segment within the trusted domain.  This
   includes labels within the SRGB of the trusted domain, labels within
   the SRLB of the specific boundary router, and labels outside either
   of these blocks.  External traffic is any traffic received from an
   interface connected to a node outside the domain of trust.

More simply put, 8402 says you can’t send an SR packet from outside an SR
domain, into that domain. But your document is written in terms of a
multiplicity of SR domains, for example this in Section 1:

   Tunnel Encapsulation attribute.  The gateway in the ingress SR domain
   can now see all possible paths to X in the egress SR domain

Maybe a quick fix, assuming you really do subscribe to the RFC 8402 trust
model, is to invent, define, and use the term “SR subdomain” and deem all the
subdomains to comprise one SR domain, in the sense of RFC 8402 §2 — “They may
as well be remotely connected to each other (e.g., an enterprise VPN or an
overlay)” seems to describe your situation pretty well.


--
COMMENT:
--

1. Abstract

   This document defines a mechanism using the BGP Tunnel Encapsulation
   attribute to allow each gateway router to advertise the routes to the
   prefixes in the Segment Routing domains to which it provides access,
   and also to advertise on behalf of each other gateway to the same
   Segment Routing domain.

The last clause has no object. To 

Re: [bess] RtgDir Early review: draft-ietf-bess-datacenter-gateway-10.txt

[Adrian Farrel]

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-gateway-10.txt

 

Hello

I have been selected to do a routing directorate “early” review of this draft.

draft-ietf-bess-datacenter-gateway

The routing directorate will, on request from the working group chair, perform 
an “early” review of a draft before it is submitted for publication to the 
IESG. The early review can be performed at any time during the draft’s lifetime 
as a working group document. The purpose of the early review depends on the 
stage that the document has reached.

 

Document: draft-ietf-bess-datacenter-gateway-10.txt
Reviewer: Ravi Singh
Review Date: 04/30/2021
Intended Status: Standards Track





Summary:

*   No issues found. This documents is ready to proceed to the IESG.

 

Regards

Ravi

 

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

[bess] FW: I-D Action: draft-drake-bess-enhanced-vpn-06.txt

[Adrian Farrel]

Hi,

We updated our draft that describes the use of BGP to achieve network
slicing and enhanced VPNs.

The change at this point is to bring the terminology into line with that
defined in the TEAS WG which has recently adopted
draft-ietf-teas-ietf-network-slice-definition

Reviews would be welcomed.

Thanks,
Adrian

-Original Message-
From: I-D-Announce  On Behalf Of
internet-dra...@ietf.org
Sent: 04 February 2021 09:43
To: i-d-annou...@ietf.org
Subject: I-D Action: draft-drake-bess-enhanced-vpn-06.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.


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-enhanced-vpn-06.txt
Pages   : 23
Date: 2021-02-04

Abstract:
   Future networks that support advanced services, such as those enabled
   by 5G mobile networks, envision a set of overlay networks each with
   different performance and scaling properties.  These overlays are
   known as network slices and are realized over a common underlay
   network.  In the context of IETF technologies, they are known as IETF
   network slices.

   In order to support IETF network slicing, as well as to offer
   enhanced VPN services in general, it is necessary to define a
   mechanism by which specific resources (links and/or nodes) of an
   underlay network can be used by a specific network slice, VPN, or set
   of VPNs.  This document sets out such a mechanism for use in Segment
   Routing networks.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-drake-bess-enhanced-vpn/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-drake-bess-enhanced-vpn-06
https://datatracker.ietf.org/doc/html/draft-drake-bess-enhanced-vpn-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-drake-bess-enhanced-vpn-06


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:
ftp://ftp.ietf.org/internet-drafts/


___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

Re: [bess] [Bier] PCE Controller & SDN Controller & Netconf/Yang NMS Controller - lines blurred and can the names be used ubiquitously meaning the same

[Adrian Farrel]

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 to do the same data gathering & ZTP like controller 
> style
> provisioning. 

Is there a fundamental difference between ZTP & Day N provisioning and path 
computation for traffic engineering provisioning? It’s all determining how to 
configure the network to best carry traffic. 

Gyan> In my mind the fundamental difference would be TE - control plane TEDs and
forwarding plane routing action path computation and instantiation of path 
action
as compare to a NMS type Netconf/Yang configuration snippet push function not
routing or TE related.

 

[Adrian] I think it depends. The protocols are just tools. You could have a 
centralised TE system with a PCE to preform computations, but you can use any 
combinations of protocols to extract information from the network (IGPs, 
BGP-LS, PCEP-LS, Netconf, …) and any combination of protocols to program the 
network devices to install TE paths, reserve resources, and configure traffic 
forwarding rules (PCEP, RSVP-TE, Netconf, …).

 

Cheers,

Adrian

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

Re: [bess] Rtgdir last call review of draft-ietf-bess-mvpn-fast-failover-11

[Adrian Farrel]

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 is not updating any other RFCs, all of these procedures
are optional.

Actually it would be good to clarify how all these procedures fit in
with "legacy" deployments, and how they are all optional procedures. I
think that needs a short statement in the Introduction and a small
section of its own (maybe between 6 and 7).

GIM>> Thank you for the suggestion. I've updated the Introduction in this way:

OLD TEXT:

   Section 4 describes protocol extensions that can speed up failover by
   not requiring any multicast VPN routing message exchange at recovery
   time.

   Moreover, section 5 describes a "hot leaf standby" mechanism, that
   uses a combination of these two mechanisms.  This approach has
   similarities with the solution described in [RFC7431] to improve
   failover times when PIM routing is used in a network given some
   topology and metric constraints.

NEW TEXT:

   Section 4 describes optional protocol extensions that can speed up
   failover by not requiring any multicast VPN routing message exchange
   at recovery time.

   Moreover, Section 5 describes a "hot leaf standby" mechanism that can
   be used to improve failover time in MVPN.  The approach combines
   mechanisms defined in Section 3 and Section 4 has similarities with
   the solution described in [RFC7431] to improve failover times when
   PIM routing is used in a network given some topology and metric
   constraints.

I think that Section 5 is intended to explain how introduced BGP extensions and 
their use described in Section 3 and Section 4 enable operators to provide 
protection for multicast services. Would you suggest adding a new text to the 
section to highlight particular aspects of introducing protection in MVPN?

[af] OK I obviously wasn’t clear. What I’m looking for is something like…

The procedures described in this document are optional to enable an operator to 
provide protection for multicast services. An operator would enable these 
mechanisms using  and it is assumed that these mechanisms would be 
supported by all  in the network for the procedures to work. In the case 
that a BGP implementation does not recognise or is configured to not support 
the extensions defined in this document, it will respond  as described 
in . This would result in .

GIM2>> I think I've got the idea now. Would appending the new paragraph to the 
Introduction address your comment:

NEW TEXT:

   The procedures described in this document are optional to enable an
   operator to provide protection for multicast services in BGP/MPLS IP
   VPNs.  An operator would enable these mechanisms using a method
   discussed in Section 3 in combination with the redundancy provided by
   a standby PE connected to the source of the multicast flow, and it is
   assumed that all PEs in the network would support these mechanisms
   for the procedures to work.  In the case that a BGP implementation
   does not recognize or is configured to not support the extensions
   defined in this document, it will continue to provide the multicast

   service, as described in [RFC6513]. 

 

[af] Perfect

 It is curious (to me) that 3.1.1 describes a way to know that a P-tunnel
is up.  You don't say, however, if being unable to determine that the
P-tunnel is up using this method is equivalent to determining that the
P-tunnel is down. (Previously in 3.1 you have talked about the "tunnel's
state is not known to be down".)

GIM>> This method, as noted in the document, is similar to BGP next-hop 
tracking, may be computationally intensive, and cannot be run frequently. So, 
in periods between checking whether the root address in the x-PMSI Tunnel 
attribute is reachable the state is "not known to be down".

[af] Well, OK. Can you add to say that, “If it is not possible to determine 
whether the state of a tunnel is ‘up’, the state shall be considered as ‘not 
known to be down’, and it may be treated as if it is ‘up’ so that attempts to 
use the tunnel are acceptable.” This is probably “obvious to one skilled in the 
art,” but would help this reader.

GIM2>> Thank you for the contributed text. I've added in before "not known to 
be Down" used in the text (with the yellowish background):

NEW TEXT:

   The procedure described here is an OPTIONAL procedure that is based

   on a downstream PE taking into account the status of P-tunnels rooted
   at each possible Upstream PE, for including or not including each
   given PE in the list of candidate UMHs for a given (C-S, C-G) state.
   If it is not possible to determine whether a P-tunnel's current
   status is Up, the state shall be considered "not known to be Down",
   and it may be treated as if it is Up so that attempts to 

Re: [bess] Rtgdir last call review of draft-ietf-bess-mvpn-fast-failover-11

[Adrian Farrel]

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 sections
4 and 5 stating that those procedures are optional. Presumably, since
this document is not updating any other RFCs, all of these procedures
are optional.

Actually it would be good to clarify how all these procedures fit in
with "legacy" deployments, and how they are all optional procedures. I
think that needs a short statement in the Introduction and a small
section of its own (maybe between 6 and 7).

GIM>> Thank you for the suggestion. I've updated the Introduction in this way:

OLD TEXT:

   Section 4 describes protocol extensions that can speed up failover by
   not requiring any multicast VPN routing message exchange at recovery
   time.

   Moreover, section 5 describes a "hot leaf standby" mechanism, that
   uses a combination of these two mechanisms.  This approach has
   similarities with the solution described in [RFC7431] to improve
   failover times when PIM routing is used in a network given some
   topology and metric constraints.

NEW TEXT:

   Section 4 describes optional protocol extensions that can speed up
   failover by not requiring any multicast VPN routing message exchange
   at recovery time.

   Moreover, Section 5 describes a "hot leaf standby" mechanism that can
   be used to improve failover time in MVPN.  The approach combines
   mechanisms defined in Section 3 and Section 4 has similarities with
   the solution described in [RFC7431] to improve failover times when
   PIM routing is used in a network given some topology and metric
   constraints.

 

I think that Section 5 is intended to explain how introduced BGP extensions and 
their use described in Section 3 and Section 4 enable operators to provide 
protection for multicast services. Would you suggest adding a new text to the 
section to highlight particular aspects of introducing protection in MVPN?

 

[af] OK I obviously wasn’t clear. What I’m looking for is something like…

 

The procedures described in this document are optional to enable an operator to 
provide protection for multicast services. An operator would enable these 
mechanisms using  and it is assumed that these mechanisms would be 
supported by all  in the network for the procedures to work. In the case 
that a BGP implementation does not recognise or is configured to not support 
the extensions defined in this document, it will respond  as described 
in . This would result in .

 

It is curious (to me) that 3.1.1 describes a way to know that a P-tunnel
is up.  You don't say, however, if being unable to determine that the
P-tunnel is up using this method is equivalent to determining that the
P-tunnel is down. (Previously in 3.1 you have talked about the "tunnel's
state is not known to be down".)

GIM>> This method, as noted in the document, is similar to BGP next-hop 
tracking, may be computationally intensive, and cannot be run frequently. So, 
in periods between checking whether the root address in the x-PMSI Tunnel 
attribute is reachable the state is "not known to be down".

 

[af] Well, OK. Can you add to say that, “If it is not possible to determine 
whether the state of a tunnel is ‘up’, the state shall be considered as ‘not 
known to be down’, and it may be treated as if it is ‘up’ so that attempts to 
use the tunnel are acceptable.” This is probably “obvious to one skilled in the 
art,” but would help this reader.

 

By the way, do you ever say that a P-tunnel has just these two statuses
(up and down) because that could make a big difference?

GIM>> I think that the document then needs to discuss what impact detection 
time has on MVPN. For example, if the detection time is in single-digit 
seconds, a two-state model can be used. But would it be a useful model if the 
detection time is in tens of seconds? Should a "not known to be down" state be 
introduced?

 

[af] Yes, that *seems* to be the implication. But is there any different action 
between “up” and “not known to be down”? If you have three states then there is 
(possibly) an implication that tunnels are prioritised by state. I think, 
however, that it is OK to use “not known to be down” as if it was “up”.

 


Note that 3.1.2 etc also establish ways to know that the tunnel is up,
but not ways to determine whether the tunnel is down.

GIM>> In this section the state of a P-tunnel is equated with the state of the 
last link of that tunnel. The document notes that if the link is Up, then the 
P-tunnel is considered down. It is implied, that if it is determined that the 
link is Down, then the state of the P-tunnel is considered Down. Would you 
recommend adding an explanation to the document? 

 

To reiterate, "I don't know if it is up" is not the same as "I know it
is down."

[bess] Rtgdir last call review of draft-ietf-bess-mvpn-fast-failover-11

[Adrian Farrel via Datatracker]

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. The purpose of the review is to provide assistance to the Routing ADs.
For more information about the Routing Directorate, please see
http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would
be helpful if you could consider them along with any other IETF Last Call
comments that you receive, and strive to resolve them through discussion or by
updating the draft.

Document: draft-ietf-bess-mvpn-fast-failover-11.txt
Reviewer: Adrian Farrel
Review Date: 2020-10-18
IETF LC End Date: 2020-10-19
Intended Status: Proposed Standard

==Summary:==

I have some minor concerns about this document that I think should be resolved
before publication.

==Comments:==

This document is fairly easy to read, but demands a thorough understanding of
RFCs 6513 and 6514. That is not unreasonable.

I also hope that the IDR working group has had a good opportunity to review
this work.

==Major Issues:==

None

==Minor Issues:==

Abstract

I think the Abstract should mention explicitly that this document
extends BGP (and how).

---

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 is not updating any other RFCs, all of these procedures
are optional.

Actually it would be good to clarify how all these procedures fit in
with "legacy" deployments, and how they are all optional procedures. I
think that needs a short statement in the Introduction and a small
section of its own (maybe between 6 and 7).

---

It is curious (to me) that 3.1.1 describes a way to know that a P-tunnel
is up.  You don't say, however, if being unable to determine that the
P-tunnel is up using this method is equivalent to determining that the
P-tunnel is down. (Previously in 3.1 you have talked about the "tunnel's
state is not known to be down".)

By the way, do you ever say that a P-tunnel has just these two statuses
(up and down) because that could make a big difference?

Note that 3.1.2 etc also establish ways to know that the tunnel is up,
but not ways to determine whether the tunnel is down.

To reiterate, "I don't know if it is up" is not the same as "I know it
is down."

---

3.1.2

   Using this method when a fast restoration mechanism (such as MPLS FRR
   [RFC4090]) is in place for the link requires careful consideration
   and coordination of defect detection intervals for the link and the
   tunnel.  In many cases, it is not practical to use both protection
   methods at the same time.

OK, I considered them carefully. Now what? :-)

I think you have to give implementation guidance.

---

All of 3.1.x are timid about the use of the mechanisms they describe.

I think that the end of 3.1 should say that an implementation may choose
to use any of these mechanisms to determine the status of the P-tunnel.

This is quite stark, however, in 3.1.3 where you have...

   When signaling state for a P2MP TE LSP is removed (e.g., if the
   ingress of the P2MP TE LSP sends a PathTear message) or the P2MP TE
   LSP changes state from Up to Down as determined by procedures in
   [RFC4875], the status of the corresponding P-tunnel SHOULD be re-
   evaluated.  If the P-tunnel transitions from Up to Down state, the
   Upstream PE that is the ingress of the P-tunnel SHOULD NOT be
   considered a valid UMH.

The use of SHOULD and SHOULD NOT is puzzling. Is this "if this mechanism
is being used, the status SHOULD..." or is it "if a P2MP MPLS-TE tunnel
is being used, this mechanism SHOULD be used"? In the former case, the
SHOULD is presumably a MUST. In the latter case, why is this worthy of
BCP 14 language when:
- this whole document is optional
- the mechanisms in 3.1.x are all optional

But 3.1.4, 3.1.5, 3.1.6, 3.1.7 also use BCP 14 language. I'm pretty sure
you mean "if this mechanism is being used..."

In case you determine to keep any use of "SHOULD" you need to describe
under what circumstances an implementation might diverge from this
strong advice.

---

3.1.6

What should I do if I don't recognise or support the setting of the BFD
Mode field?

---

4.1

   The normal and the standby C-multicast routes must have their Local
   Preference attribute adjusted

Should this be "MUST"?

---

7.1

   IANA is requested to allocate the BGP "Standby PE" community value
   (TBA1) from the Border Gateway Protocol (BGP) Well-known Communities
   registry.

There are three ranges. You need to tell IANA which range to use.
Presumabl

Re: [bess] Benjamin Kaduk's Discuss on draft-ietf-bess-nsh-bgp-control-plane-15: (with DISCUSS and COMMENT)

[Adrian Farrel]

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

I think the clue here is that an RD is an extended community of type 0, 1, or 2 
with extended type always 0 (together, the RD type) while a pool id is a (new) 
extended community of type TBD6 with several extended types defined (1 and 2 in 
this document).

The whole extended community is included in the list, so it is always possible 
to tell the difference between an RD and a pool id.
You read the first two bytes and get 0:0, 1:0, or 2:0 for an RD and TBD6:1, or 
TBD6:2 for a pool id.

I'm adding...

  Note that an SFIR-RD can be distinguished from an SFIR 
Pool Identifier because they are both
 BGP Extended Communities but they have different extended 
community types.

> (I'm also not entirely clear how the IPv6 addresses interact with 8-byte RDs.)

This is in your Comment on section 8.10 and addressed below.
Tl;dr They don't. RDs are encoded according to the operator's choice of 
numbering scheme and do not use v6 addresses.

> COMMENT:
>
> [retaining the note that I support Roman's Discuss]

Well, hoping that we have addressed that in -15, but waiting to hear from Roman.

> New comments on the -15
>
> Section 2.2
>
>   o  The Special Purpose SFT values range is assigned through Standards
>  Action.  Values in that range are used for special SFC operations
>  and do not apply to the types SF that may be placed on the SFC.
>
> I'm not sure I understand what it means to "place a SF on the SFC".
> Also, nit: missing "of"?

Nit is correct.
"Placed on" refers to the fact that an SFC is a computed sequence of SFs that 
form the chain.
Well, this should really say "SFP"
Clarified to...
   ...and do not apply to the types of SF that may form part of the 
SFP.

> o  The First Come First Served range tracks assignments of STF values
>  made by any party that defines an SF type.  Reference through an
>  Internet-Draft is desirable, but not required.
>
> Maybe "Internet-Draft or other stable written specification?"

I think there is nothing to be gained from driving people away from the IETF, 
so it's still our "desire" that an I-D would be used.

> Section 8.10
>
> The IPv6 examples seem to show RDs that are 127-bit IPv6 prefixes, but an
> 8-octet RD doesn't seem to have space for that?

Wow, this really is a mistake or embarrassing proportions. I shall claim clumsy 
editing while in a major grump about having to put in these examples. The fact 
is that *all* that changes in the IPv6 examples is the addresses of the nodes - 
the BGP advertisements are not changed at all and RDs remain as whatever 6 byte 
scheme the operator chooses to use.

I have added some text to help with this (as well as fixing the RDs) so that in 
Section 8 we have...

The SFFs advertise routes to the SFIs they support.  These advertisements
   contain Route Distinguishers that are set according to the network 
operators
   configuration model.  In all of these IPv4 examples we use RDs of type 2 
such that the
   available six octets are partitioned as four octets for the IPv4 address 
of the advertising
   SFF, and two octets that are a local index of the SFI.  This scheme is 
chosen purely for
   convenience of documentation, and an operator is totally free to use any 
other scheme so
   long as it conforms to the definitions of SFIR and SFPR in  and
   .

Thus we see the following SFIRs advertised:

...and in 8.10 we have...

The SFFs advertise routes to the SFIs they support.  These advertisements
   contain Route Distinguishers that are set according to the network 
operators
   configuration model.  Note that in an IPv6 network, the RD is not large 
enough to 
   contain the full IPv6 address as only six octets are available so, in 
all of these IPv6
   examples, we use RDs of type 2 such that the available six octets are 
partitioned as four
   octets for an IPv4 address of the advertising SFF, and two octets that 
are a local index 
   of the SFI.  Furthermore, we have chosen an IPv6 addressing scheme so 
that the low order
   four octets of the IPv6 address match an IPv4 address of the advertising 
node.  This scheme
   is chosen purely for convenience of documentation, and an operator is 
totally free to use
   any other scheme so long as it conforms to the definitions of SFIR and 
SFPR in
and .

Observant readers will notice that this makes the BGP advertisements 
shown in these examples
   exactly the same as in the previous examples.  All that is different is 
that the advertising
   SFFs and Controller have IPv6 addresses.

Thus we see the following SFIRs 

Re: [bess] Alvaro Retana's Discuss on draft-ietf-bess-nsh-bgp-control-plane-13: (with DISCUSS and COMMENT)

[Adrian Farrel]

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 communities as interfering with
> the new one (see §7.7/rfc5575bis).  This would result in this document
> specifying something like this:
>
> OLD>
>   ...: the inclusion of the "Flow Specification for SFC Classifiers" action
>   extended community along with any other action MUST be treated by an
>   implementation of this specification as an error which SHOULD result in the
>   Flow Specification UPDATE message being handled as Treat-as-withdraw
>   according to Section 2.
>
> NEW>
>     The "Flow Specification for SFC Classifiers" extended community
>   interferes with all other Traffic Filtering Actions.  Only the SFC
>   Classifiers action MUST be considered and all others ignored.
>
> If you *really* want to treat-as-withdraw, then here's my suggested
> text to be in line with rfc5575bis:
>
> NEW>
>   ...: a "Flow Specification for SFC Classifiers" Traffic Filtering Action
>   Extended Community advertised with any other Traffic Filtering Action
>   Extended Community MUST be treated as malformed.

We settled on the second of these options.

Best,
Adrian

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

Re: [bess] Murray Kucherawy's No Record on draft-ietf-bess-nsh-bgp-control-plane-15: (with COMMENT)

[Adrian Farrel]

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...@gmail.com; draft-ietf-bess-nsh-bgp-control-pl...@ietf.org;
bess-cha...@ietf.org; bess@ietf.org
Subject: [bess] Murray Kucherawy's No Record on
draft-ietf-bess-nsh-bgp-control-plane-15: (with COMMENT)

Murray Kucherawy has entered the following ballot position for
draft-ietf-bess-nsh-bgp-control-plane-15: No Record

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-nsh-bgp-control-plane/



--
COMMENT:
--

As the IESG has rotated since this went up for a telechat, it's now shy of
the
needed ballot count to pass even when the DISCUSSes are cleared.  I'll
ballot
on this after I do a full review.

A quick comment now on -15:

Thanks for applying the feedback from my current and former co-ADs.
However,
Adam Roach's review requested that "L3VPN", "NRLI", and "EVPN" be expanded
on
first use, but that still hasn't been done.



___
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 Early review: draft-ietf-bess-datacenter-gateway.txt

[Adrian Farrel]

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 encodings are explicitly specified)





Summary:

 

I have some minor concerns about this document that I think should be resolved 
before it is submitted to the IESG.

 

Comments:

1. Draft track: does this need to be "standards track”? No new encodings are 
specified, even though there are requests for new IANA code-points.

 

AF> The document asks for a code point from the “BGP Tunnel Encapsulation 
Attribute Sub-TLVs" registry for which the registration policy for this 
registry is Standards Action. So we have to be a Standards Track document.

 

2. Section 3:

  a. Auto-discovery: setting the route-target to SR-ID: how to avoid 
conflicts in regards to route-target settings: some may represent the SR ID and 
other represent non-SR constructs? Some text in that regard would be helpful.

 

AF> These are not VPN routes so there shouldn’t be any conflict. But I think 
your question might be about what happens if other RTs need to be present on 
the same advertisement. And the answer is, “just do it”.

 

  b. The draft would do well to explicitly state what happens if the 
GWs in a given domain end up getting configured with different SR IDs.

 

AF> We will add a little text.  Basically they would not auto-discover each 
other and a receiver would just get the best route with only the advertising 
node’s tunnel encapsulation information.

 

  c. Is there a specific reason why neither the format for the SR 
tunnel TLV is listed nor a pointer given to a pre-existing definition in 
another doc?

 

AF> We will add a reference to  

 https://datatracker.ietf.org/doc/html/draft-ietf-idr-tunnel-encaps-15#section-2

 

3. Section. 5: could use an example with reference to figure 1.

 

AF> Yup. Several people have asked for examples. We’ll add a pointer to  

 
https://datatracker.ietf.org/doc/html/draft-farrel-spring-sr-domain-interconnect-05
 section 7.

 

4. Section 6: would be useful to describe, or provide pointer to section in the 
tunnel-encaps draft, stating logic for picking a specific encapsulation for a 
given packet.

 

AF> The advertising node can include anything defined in either the Tunnel 
Encapsulation draft or any other subsequent drafts.  As indicated above, we are 
just defining new wrappers.

 

Best,

Adrian

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

Re: [bess] Closing on Stephane's open issue with draft-ietf-bess-datacenter-gateway

[Adrian Farrel]

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 to a VPN and to a SR domain? The VPN and the SR 
might use different RTs. Can you have two different Route Target in one 
advertisement?

 

AF > We certainly don’t want to restrict wider applicability, but our focus is 
only on connecting together SR domains. We weren’t looking to solve the 
multi-homed VPN “problem”.

 

AF > The RT is an extended community. Extended communities are carried in the 
Extended Communities Attribute. The Extended Communities Attribute can carry 
more than one extended community.

 

Best,

Adrian

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

Re: [bess] New version: draft-ietf-bess-datacenter-gateway-07.txt

[Adrian Farrel]

s AS 
could be the X:Y X value and the Y could be the unique domain identifier.

 

AF> I think the use of 0x00 or 0x02 in the high-order octet of the RT Type 
field are most likely, but there is no reason why 0x01 should not be used if 
that is how the AS is managed. And this would not make any difference to how 
the mechanisms in this document work. The scheme you describe is certainly 
plausible.

 

I noticed SAFI 4 BGP-LU is in the list of SAFI.  That is traditionally used for 
inter-as L3 VPN optC or CsC flavors.  In the context of SR as this draft is 
geared towards if you are using SR-TE with binding sid policy across each AS 
hop NNI boundary stitching the steered path you would not need BGP-LU.  Also if 
the AS 2 core is MPLS only then would you need BGP-LU and only if using option 
C.  There are caveats with other inter-as options related to multicast MVPN 
that recommends stacking BGP-LU as well for mLDP inband signaling.

 

Yes. But unless anyone sees a good reason to rule out using SAFI 4, we prefer 
to keep the option open. If no one uses it, I guess that is OK.

 

That  is all the more reason to be crystal clear on the topology of the transit 
ASs in the mix here - AS 2 and AS 1  and if it’s every possible flavor then we 
should state that as well.  

 

I think from a operators standpoint it would make sense to have the draft 
account for all AS2 transport backbone flavors that are possible and account 
for how this solution would work for every flavor as their maybe lots of 
caveats as you did into the weeds with each flavor.  

 

It is certainly our intent to support “all possible flavours” so we will make 
that clear in the document.

 

The auto-discovery route that each GW advertises consists of the
   following:
 
   o  An IPv4 or IPv6 NLRI containing one of the GW's loopback addresses
  (that is, with an AFI/SAFI pair that is one of 1/1, 2/1, 1/4, or
  2/4).

 

Section 3 what seems to be missing in connecting the dots on how this solution 
would work is that you talk about the GWs import of the RTs which is fine but 
what is missing is the BGP interaction to backbone AS2 and all the possible 
variations of the AS2 transport.  I think that will really help explain.

 

It is hard to tell but are we doing ebgp multihop over GRE tunneling over AS2 
and AS1 which is why we don’t talk about that the middle ASs routing details.

 

The BGP behavior except at the gateways is “as normal”. The data packets are 
carried over the intervening ASes using tunnels as described by the tunnel 
encapsulations.

 

Section 5 is the first mention of SR-TE in the draft and starts talking about 
the SR-MPLS label stack.  Both paragraphs are very confusing as more context or 
a detailed stick diagram would help.

 

What may help is an end to end packet walk on the discovery mechanism. 

 

We will work to clarify this text without (re-)defining how SR-TE works.

 

I think leaving out the AS2 AS1 BGP interaction makes it difficult to follow 
and connect the dots on the solution.

 

This really is “business as usual” for tunnel 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 
internet-dra...@ietf.org <mailto:internet-dra...@ietf.org> 
Sent: 04 June 2020 18:33
To: i-d-annou...@ietf.org <mailto:i-d-annou...@ietf.org> 
Cc: bess@ietf.org <mailto:bess@ietf.org> 
Subject: [bess] I-D Action: draft-ietf-bess-datacenter-gateway-07.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   : Gateway Auto-Discovery and Route Advertisement for
Segment Routing Enabled Domain Interconnection
Authors : Adrian Farrel
  John Drake
  Eric Rosen
  Keyur Patel
  Luay Jalil
Filename: draft-ietf-bess-datacenter-gateway-07.txt
Pages   : 12
Date: 2020-06-04

Abstract:
   Data centers are critical components of the infrastructure used by
   network operators to provide services to their customers.  Data
   centers are attached to the Internet or a backbone network by gateway
   routers.  One data center typically has more than one gateway for
   commercial, load balancing, and resiliency reasons.

   Segment Routing is a protocol mechanism that can be used within a
   data center, and also for steering traffic that flows between two
   data center sites.  In order that one data center site may load
   balance the traffic it sends to another data center site, it needs to
   know the complete set of gateway routers at the remote data center,
   the points of connection from those 

Re: [bess] Thought about "Application Routing" in draft-dunbar-bess-bgp-sdwan-usage

[Adrian Farrel]

Hi Linda,

 

Thank you so much for continuing to try to accommodate me. Please consider this 
my last attempt to fix this unless someone else on the mailing list joins in to 
support my opinion.

 

I do not believe the term “application forwarding” is either defined in the 
document or particularly meaningful. It is no better than “application routing” 
in this respect.

 

I think that you are trying to refer to “individual traffic flows associated 
with a specific application” (although you may intend to refer to “individual 
packets”). And you are either trying to describe how traffic is “classified” 
onto paths/tunnels (as in bullet 3) or trying to indicate how packets may be 
handled within the network (possibly bullet 4), or both.

 

You also have the use of an application identifier as a mechanism to classify 
traffic. If you go down that path you must discuss privacy and netneutrality 
even if all you have to say is that this function takes place within a private 
(enterprise) network where all users are assumed to be required to comply with 
the network operator’s usage rules.

 

I’ll stop now.

 

Once again, thanks for trying to make me happy 

 

Best,

Adrian

 

From: Linda Dunbar  
Sent: 30 July 2020 23:34
To: Najem, Basil ; adr...@olddog.co.uk; bess@ietf.org
Cc: draft-dunbar-bess-bgp-sdwan-us...@ietf.org
Subject: RE: Thought about "Application Routing" in 
draft-dunbar-bess-bgp-sdwan-usage

 

Adrian, 

 

Thank you very much for the comments and suggestions. 

Per your suggestions, we have changed the wording to the following. Do you 
think it is clear? 

 

Here are some key characteristics of “SDWAN” networks:

-   Augment of transport, which refers to utilizing overlay paths over 
different underlay networks. Very often there are multiple parallel overlay 
paths between any two SDWAN edges, some of which are private networks over 
which traffic can traverse with or without encryption, others require 
encryption, e.g. over untrusted public networks. 

-   Enable direct Internet access from remote sites, instead hauling all 
traffic to Corporate HQ for centralized policy control. 

-   Some traffic can be forwarded based on their application IDs instead of 
based on destination IP addresses. For example, placing traffic onto specific 
overlay paths based on their application IDs.  

-   The Application forwarding can also be based on specific performance 
criteria (e.g. packets delay, packet loos, jitter) to provide better 
application performance by choosing the right underlay that meets or exceeds 
the specified criteria. 

 

If it is not clear, can you help to wordsmith it? 

 

Linda Dunbar

From: Najem, Basil mailto:basil.na...@bell.ca> > 
Sent: Tuesday, July 28, 2020 9:46 AM
To: adr...@olddog.co.uk <mailto:adr...@olddog.co.uk> ; Linda Dunbar 
mailto:linda.dun...@futurewei.com> >; 
bess@ietf.org <mailto:bess@ietf.org> 
Cc: draft-dunbar-bess-bgp-sdwan-us...@ietf.org 
<mailto:draft-dunbar-bess-bgp-sdwan-us...@ietf.org> 
Subject: RE: Thought about "Application Routing" in 
draft-dunbar-bess-bgp-sdwan-usage

 

Hi Adrian;

 

Given the context in the document, I’d revert back to the original paragraph 
(my proposed text in the thread) and change “route/routed” 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> 
Cc: draft-dunbar-bess-bgp-sdwan-us...@ietf.org 
<mailto:draft-dunbar-bess-bgp-sdwan-us...@ietf.org> 
Subject: [EXT]RE: Thought about "Application Routing" in 
draft-dunbar-bess-bgp-sdwan-usage

 

The issue I am trying to get at is that the text you have in the draft is 
unclear and probably going to explode.

*   We have an approximate solution for that

 

The secondary issue is whether you are talking about routing/forwarding within 
the network, or placing the traffic onto tunnels at the edge.

*   You are pretty clear on what you mean, and I am fine with that since it 
fits with my understanding of VPN.
*   Possibly Linda is thinking about how those tunnels are maintained and 
operated to meet the service levels that they offer. That would be (I think) 
out of scope for a BGP VPN

 

Maybe we can polish the paragraph in question to become…

 

Better user experience can be provided by placing traffic flows for an 
application onto tunnels over an underlay network that meet or exceed the 
specified performance criteria (e.g., packets delay, packet lose, jitter) for 
those traffic flows.

 

Cheers,

Adrian

 

From: Najem, Basil mailto:basil.na...@bell.ca> > 
Sent: 28 July 2020 14:28
To: adr...@olddog.co.uk <mailto:adr...@olddog.co.uk> ; 'Linda Dunbar' 
mailto:linda.dun...@futurewei.com> >; 
bess@ietf.org <mailto:bess@ietf.org>

Re: [bess] Thought about "Application Routing" in draft-dunbar-bess-bgp-sdwan-usage

[Adrian Farrel]

The issue I am trying to get at is that the text you have in the draft is 
unclear and probably going to explode.

*   We have an approximate solution for that

 

The secondary issue is whether you are talking about routing/forwarding within 
the network, or placing the traffic onto tunnels at the edge.

*   You are pretty clear on what you mean, and I am fine with that since it 
fits with my understanding of VPN.
*   Possibly Linda is thinking about how those tunnels are maintained and 
operated to meet the service levels that they offer. That would be (I think) 
out of scope for a BGP VPN

 

Maybe we can polish the paragraph in question to become…

 

Better user experience can be provided by placing traffic flows for an 
application onto tunnels over an underlay network that meet or exceed the 
specified performance criteria (e.g., packets delay, packet lose, jitter) for 
those traffic flows.

 

Cheers,

Adrian

 

From: Najem, Basil  
Sent: 28 July 2020 14:28
To: adr...@olddog.co.uk; 'Linda Dunbar' ; 
bess@ietf.org
Cc: draft-dunbar-bess-bgp-sdwan-us...@ietf.org
Subject: RE: Thought about "Application Routing" in 
draft-dunbar-bess-bgp-sdwan-usage

 

Let’s get back to what SD-WAN is doing: it can steer/forward the application 
traffic based on specified performance criteria value requirement. This 
criteria is set by the subscriber (user) to ensure a better experience (by 
choosing the best tunnel over an underlay). Not sure what’s the 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.org
Cc: draft-dunbar-bess-bgp-sdwan-us...@ietf.org
Subject: [EXT]RE: Thought about "Application Routing" in 
draft-dunbar-bess-bgp-sdwan-usage

 

Thanks to both Linda and Basil,

 

My response is a little unthought as I am currently following two simultaneous 
sessions (sorry about that), but it seems to me that the answers from the two 
of you seem to be slightly at odds.

 

Basil is talking about steering whole traffic flows onto tunnels to be carried 
over the network; Linda is talking about routing individual packets within the 
network.

 

I would still caution you to avoid tying too tightly to the term “application”. 
A single application may generate multiple flows with different performance 
criteria and you will treat the flows differently. Conversely, two applications 
may generate flows that have identical performance criteria.

 

Thanks,

Adrian

 

From: Linda Dunbar mailto:linda.dun...@futurewei.com> > 
Sent: 28 July 2020 14:05
To: Najem, Basil mailto:basil.na...@bell.ca> >; 
adr...@olddog.co.uk <mailto:adr...@olddog.co.uk> ; bess@ietf.org 
<mailto:bess@ietf.org> 
Cc: draft-dunbar-bess-bgp-sdwan-us...@ietf.org 
<mailto:draft-dunbar-bess-bgp-sdwan-us...@ietf.org> 
Subject: RE: Thought about "Application Routing" in 
draft-dunbar-bess-bgp-sdwan-usage

 

Adrian, 

 

You said: 

As will be seen from the Application Aware Networking (APN) effort, the concept 
of traffic flows being routed according to the identity of the application is 
made complicated by various privacy and security concerns, not to mention 
issues of registering application identities.

 

The "Application" doesn't necessary mean all the bits in the payload. The 
"Application" can be any criteria that Client has indicated to Network 
Operators, for example the IPsec SA header bits, the TCP/UDP port number, the 
Source Addresses, etc. 

The network will not alter the forwarding behavior unless there is the request 
from the client to inform the network to forward their traffic based on its 
provided criteria.

 

This draft, which was written 2 years ago, is indeed to show that BGP can be 
effectively used to “do something similar to APN: that is, to classify the 
service that a particular application-sourced flow wants to receive from the 
network”. 

 

Since SDWAN is over different types of underlay networks, with different 
performance and security aspects, clients may want their specific traffic to 
traverse specific underlay networks, or specific peers. 

 

Yes, indeed that the goal is to “ the packets are 'coloured' for routing and 
treatment in the network.”

 

There is another draft in IDR to describe the encoding “Color” or “IPsec SA 
ID”: https://datatracker.ietf.org/doc/draft-dunbar-idr-sdwan-edge-discovery/

 

Welcome your comments to that draft. 

 

I will attend the APN side meeting on Thurs to understand more. 

 

 

Linda Dunbar

 

-Original Message-
From: Najem, Basil mailto:basil.na...@bell.ca> > 
Sent: Tuesday, July 28, 2020 7:10 AM
To: adr...@olddog.co.uk <mailto:adr...@olddog.co.uk> ; bess@ietf.org 
<mailto:bess@ietf.org> 
Cc: draft-dunbar-bess-bgp-sdw

Re: [bess] Thought about "Application Routing" in draft-dunbar-bess-bgp-sdwan-usage

[Adrian Farrel]

Thanks to both Linda and Basil,

 

My response is a little unthought as I am currently following two simultaneous 
sessions (sorry about that), but it seems to me that the answers from the two 
of you seem to be slightly at odds.

 

Basil is talking about steering whole traffic flows onto tunnels to be carried 
over the network; Linda is talking about routing individual packets within the 
network.

 

I would still caution you to avoid tying too tightly to the term “application”. 
A single application may generate multiple flows with different performance 
criteria and you will treat the flows differently. Conversely, two applications 
may generate flows that have identical performance criteria.

 

Thanks,

Adrian

 

From: Linda Dunbar  
Sent: 28 July 2020 14:05
To: Najem, Basil ; adr...@olddog.co.uk; bess@ietf.org
Cc: draft-dunbar-bess-bgp-sdwan-us...@ietf.org
Subject: RE: Thought about "Application Routing" in 
draft-dunbar-bess-bgp-sdwan-usage

 

Adrian, 

 

You said: 

As will be seen from the Application Aware Networking (APN) effort, the concept 
of traffic flows being routed according to the identity of the application is 
made complicated by various privacy and security concerns, not to mention 
issues of registering application identities.

 

The "Application" doesn't necessary mean all the bits in the payload. The 
"Application" can be any criteria that Client has indicated to Network 
Operators, for example the IPsec SA header bits, the TCP/UDP port number, the 
Source Addresses, etc. 

The network will not alter the forwarding behavior unless there is the request 
from the client to inform the network to forward their traffic based on its 
provided criteria.

 

This draft, which was written 2 years ago, is indeed to show that BGP can be 
effectively used to “do something similar to APN: that is, to classify the 
service that a particular application-sourced flow wants to receive from the 
network”. 

 

Since SDWAN is over different types of underlay networks, with different 
performance and security aspects, clients may want their specific traffic to 
traverse specific underlay networks, or specific peers. 

 

Yes, indeed that the goal is to “ the packets are 'coloured' for routing and 
treatment in the network.”

 

There is another draft in IDR to describe the encoding “Color” or “IPsec SA 
ID”: https://datatracker.ietf.org/doc/draft-dunbar-idr-sdwan-edge-discovery/

 

Welcome your comments to that draft. 

 

I will attend the APN side meeting on Thurs to understand more. 

 

 

Linda Dunbar

 

-Original Message-
From: Najem, Basil  
Sent: Tuesday, July 28, 2020 7:10 AM
To: adr...@olddog.co.uk; bess@ietf.org
Cc: draft-dunbar-bess-bgp-sdwan-us...@ietf.org
Subject: RE: Thought about "Application Routing" in 
draft-dunbar-bess-bgp-sdwan-usage

 

Thanks Adrian for your comment.

 

How about changing the paragraph to something like:

 

"The application 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

 

 

 

-Original Message-

From: Adrian Farrel mailto:adr...@olddog.co.uk> > 

Sent: July-28-20 8:01 AM

To: bess@ietf.org <mailto:bess@ietf.org> 

Cc: draft-dunbar-bess-bgp-sdwan-us...@ietf.org 
<mailto:draft-dunbar-bess-bgp-sdwan-us...@ietf.org> 

Subject: [EXT]Thought about "Application Routing" in 
draft-dunbar-bess-bgp-sdwan-usage

 

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 better application performance by choosing the right

   underlay that meets or exceeds the specified criteria.

 

Firstly, s/loos/loss/ 

 

But I am concerned by the concept of "application routing" and I note that the 
term is not used elsewhere in the document nor is the concept expanded upon.

 

As will be seen from the Application Aware Networking (APN) effort, the concept 
of traffic flows being routed according to the identity of the application is 
made complicated by various privacy and security concerns, not to mention 
issues of registering application identities.

 

Fortunately, I suspect that this draft wants to do something similar to APN: 
that is, to classify the service that a particular application-sourced flow 
wants to receive from the network. This may be considerably more complex than 
DSCP, but the concept is the same that either a tunnel/pipe/flow is negotiated 
and established for use by the application, or the packets are 'coloured' for 
routing and treatment in the network.

 

Re: [bess] Thought about "Application Routing" in draft-dunbar-bess-bgp-sdwan-usage

[Adrian Farrel]

Thanks for engaging.

I'm going to be picky!

The application is not routed. It sits there running on a host. I think it is 
the application's traffic that is routed, and I am assuming you mean specific 
traffic flows to/from an application because a single application may have:
- flows to/from multiple destinations
- multiple flows to/from a single destination
And each of these flows may request different performance criteria.

So, maybe...

A traffic flow for an application can be routed based on specific performance 
criteria (e.g., packets delay, packet lose, jitter) to provide a better user 
experience by choosing tunnels over an underlay network that meet or exceed the 
specified performance criteria threshold for that traffic flow.

I am still slightly worried about the term "routed" in this context. Routing is 
how we forward a packet from one router to the next. I think you are perhaps 
more likely describing "steering" or "directing" since you are putting the 
whole flow into a tunnel.

Best,
Adrian

-Original Message-
From: Najem, Basil  
Sent: 28 July 2020 13:10
To: adr...@olddog.co.uk; bess@ietf.org
Cc: draft-dunbar-bess-bgp-sdwan-us...@ietf.org
Subject: RE: Thought about "Application Routing" in 
draft-dunbar-bess-bgp-sdwan-usage

Thanks Adrian for your comment.

How about changing the paragraph to something like:

"The application 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



-Original Message-
From: Adrian Farrel  
Sent: July-28-20 8:01 AM
To: bess@ietf.org
Cc: draft-dunbar-bess-bgp-sdwan-us...@ietf.org
Subject: [EXT]Thought about "Application Routing" in 
draft-dunbar-bess-bgp-sdwan-usage

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 better application performance by choosing the right
   underlay that meets or exceeds the specified criteria.

Firstly, s/loos/loss/ 

But I am concerned by the concept of "application routing" and I note that the 
term is not used elsewhere in the document nor is the concept expanded upon.

As will be seen from the Application Aware Networking (APN) effort, the concept 
of traffic flows being routed according to the identity of the application is 
made complicated by various privacy and security concerns, not to mention 
issues of registering application identities.

Fortunately, I suspect that this draft wants to do something similar to APN: 
that is, to classify the service that a particular application-sourced flow 
wants to receive from the network. This may be considerably more complex than 
DSCP, but the concept is the same that either a tunnel/pipe/flow is negotiated 
and established for use by the application, or the packets are 'coloured' for 
routing and treatment in the network.

I would suggest two things:
1. Be a lot more clear about what is meant by "application routing" possibly 
even using a different term 2. Have a look at the APN work - side meeting on 
Thursday; see https://github.com/APN-Community/IETF108-Side-Meeting-APN for all 
the details

Best,
Adrian

--
External Email: Please use caution when opening links and attachments / 
Courriel externe: Soyez prudent avec les liens et documents joints

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

[bess] Thought about "Application Routing" in draft-dunbar-bess-bgp-sdwan-usage

[Adrian Farrel]

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 better application performance by choosing the right
   underlay that meets or exceeds the specified criteria.

Firstly, s/loos/loss/ 

But I am concerned by the concept of "application routing" and I note that the 
term is not used elsewhere in the document nor is the concept expanded upon.

As will be seen from the Application Aware Networking (APN) effort, the concept 
of traffic flows being routed according to the identity of the application is 
made complicated by various privacy and security concerns, not to mention 
issues of registering application identities.

Fortunately, I suspect that this draft wants to do something similar to APN: 
that is, to classify the service that a particular application-sourced flow 
wants to receive from the network. This may be considerably more complex than 
DSCP, but the concept is the same that either a tunnel/pipe/flow is negotiated 
and established for use by the application, or the packets are 'coloured' for 
routing and treatment in the network.

I would suggest two things:
1. Be a lot more clear about what is meant by "application routing" possibly 
even using a different term
2. Have a look at the APN work - side meeting on Thursday; see 
https://github.com/APN-Community/IETF108-Side-Meeting-APN for all the details

Best,
Adrian

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

Re: [bess] Alvaro Retana's Discuss on draft-ietf-bess-nsh-bgp-control-plane-13: (with DISCUSS and COMMENT)

[Adrian Farrel]

Thanks!

 

That may explain why we have what we have.

 

A

 

From: Alvaro Retana  
Sent: 10 July 2020 21:06
To: adr...@olddog.co.uk; The IESG 
Cc: bess-cha...@ietf.org; bess@ietf.org; 
draft-ietf-bess-nsh-bgp-control-pl...@ietf.org; sfc-cha...@ietf.org
Subject: RE: Alvaro Retana's Discuss on 
draft-ietf-bess-nsh-bgp-control-plane-13: (with DISCUSS and COMMENT)

 

rfc5575bis, when it came out of the WG had a section about error handling 
including treat-as-withdraw.  As we processed and cleaned the document up we 
ended up not defining specific effort handling for FS, but relying on 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 going to do some 
archaeology to remind myself where the treat-as-withdraw came from. I have some 
memory that it was IDR that pushed us to have this (and other) error actions, 
but I may well be misremembering. Depending on what I discover, I will pick one 
or the other of the suggestions and re-post. 

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

Re: [bess] Alvaro Retana's Discuss on draft-ietf-bess-nsh-bgp-control-plane-13: (with DISCUSS and COMMENT)

[Adrian Farrel]

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. Thus, the
>> announcement of an SFPR by any other BGP peer would be rejected."
>>
>> Would that be good?
>
> I don't think that the initial qualification ("in an environment...")
> is needed; the action is RECOMMENDED, so the operator can decide
> when/if they want to follow it.  Otherwise it looks good to me.

OK

"Where there is concern..."

>> How about:
>>
>> Note that implementation of this section of this specification will be
>> Controllers or Classifiers communicating with each other directly for the
>> purpose of instructing the Classifier how to place packets onto an SFP. In
>> order that the implementation of Classifiers can be kept simple and to
>> avoid the confusion between the purpose of different extended communities,
>> a Controller MUST NOT include other action extended communities at the same
>> time as a "Flow Specification for SFC Classifiers" extended community: the
>> inclusion of the "Flow Specification for SFC Classifiers" action extended
>> community along with any other action MUST be treated by an implementation
>> of this specification as an error which SHOULD result in the Flow
>> Specification UPDATE message being handled as Treat-as-withdraw according to
>> Section 2.
>
> s/action extended communities/Traffic Filtering Action Extended Communities

Ack

> 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 communities as interfering with
> the new one (see §7.7/rfc5575bis).  This would result in this document
> specifying something like this:
>
> OLD>
>   ...: the inclusion of the "Flow Specification for SFC Classifiers" action
>   extended community along with any other action MUST be treated by an
>   implementation of this specification as an error which SHOULD result in the
>   Flow Specification UPDATE message being handled as Treat-as-withdraw
>   according to Section 2.
>
> NEW>
>     The "Flow Specification for SFC Classifiers" extended community
>   interferes with all other Traffic Filtering Actions.  Only the SFC
>   Classifiers action MUST be considered and all others ignored.
>
> If you *really* want to treat-as-withdraw, then here's my suggested
> text to be in line with rfc5575bis:
>
> NEW>
>   ...: a "Flow Specification for SFC Classifiers" Traffic Filtering Action
>   Extended Community advertised with any other Traffic Filtering Action
>   Extended Community MUST be treated as malformed.

Thanks. I can accept either of your suggestions. I'm going to do some 
archaeology to remind myself where the treat-as-withdraw came from. I have some 
memory that it was IDR that pushed us to have this (and other) error actions, 
but I may well be misremembering. Depending on what I discover, I will pick one 
or the other of the suggestions and re-post.

Cheers,
Adrian

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

Re: [bess] Alvaro Retana's Discuss on draft-ietf-bess-nsh-bgp-control-plane-13: (with DISCUSS and COMMENT)

[Adrian Farrel]

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 against
>> rogue players.
>
> You didn't explicitly say so, but it looks like this may be the added text:
>
>   Similarly, there is a vulnerablity if a rogue or subverted controller
>   announces SFPs especially if that controller "takes over" an existing
>   SFP and changes its contents.  This is corresponds to a rogue BGP
>   speaker entering a routing system, or even to a Route Reflector
>   becoming subverted.  Protection mechanisms, as above, include
>   securing BGP sessions and protecting software loads on the
>   controllers.
>
> [nit] s/vulnerablity/vulnerability

Thanks

> Authentication helps, but it doesn't stop an authenticated subverted
> node from taking over control of an SFP.
>
> Maybe I haven't been clear with my concern.  I am concerned about
> authorization of the BGP speaker to even act as a controller -- this
> is akin to route origin validation: should a BGP speaker even be
> generating SFPRs?  In "normal" BGP a mitigation against invalid
> origination is ingress filtering -- in this case, a mitigation might
> be for the operator to receive (using an access list, for example)
> SFPRs originated by only some nodes.

So, to be clear, you are worried about what happens to the routing 
infrastructure if one node gets subverted, and you believe that a combination 
of something akin to route origin validation and ingress filtering would help. 

Obviously (?) it is intended (and even stated) that SFPRs are originated only 
by controllers, and as we say, "We assume that the Controllers have BGP 
connectivity to all SFFs and all Classifiers within each service function 
overlay network." That means that we are not relying on BGP peer-to-peer relay 
of SFPR advertisements, but they are injected to the SFFs direct. Thus, your 
concern is mitigated by making sure that the SFF/controller relationship is 
known and authenticated, except for the case when the controller has been 
subverted.

I don't, in this case, see how route origin validation or ingress filtering 
would help us. A subverted controller in this case is like having two NMSes (or 
two SDN controllers) in a network with both intended to be able to manage the 
network in parallel: what do you do if one is subverted?

I think, here, we are discussing the wrong approach to a solution. A protocol 
solution cannot protect against the subversion of a component that is otherwise 
authorised to act.

We can, however, make sure that only nodes that are authorised to be 
controllers are allowed to speak as controllers. An approach here would be to 
configure each SFF with the identities of the controllers that it accepts. 
(This, for example, is what is usually done with NMSes. Note that in the PCE 
world, a PCC can be configured with the identities of he PCEs or it can 
discover them).  I think we might add...

"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.  Thus, the announcement of an 
SFPR by any other BGP peer would be rejected."

Would that be good?

>>> (2) New Flow Specification Traffic Filtering Action
>...
>> I said:
>> : Hmmm, we don't tent to explain why "MUST NOT" in our specifications.
>> : The reasoning here is that it would be highly confusing to mix and match
>> : SFC Classification with BGP routing. Perhaps I am wrong about that
>> : confusion.
>> : I think that when you program an SFC classifier, that is a single peer-to-
>> : peer communication targeted at an SFC Classifier.
>> : A 5575-only node will not be a classifier.
>>
>> You responded:
>> | I raised this point as a DISCUSS because the text is at odds with other
>> | standards track documents. That is the reason I'm asking for an
>> | explanation.
>
> You missed the second part of my response (to the last couple of sentences):
>
> You>
>   I think that when you program an SFC classifier, that is a single
>   peer-to-peer communication targeted at an SFC Classifier.
>   A 5575-only node will not be a classifier.
>
> Me>
>   That is the type of operational considerations that I would like to see
>   the document include.
>
> That's all I'm looking for.  By "isolating" the communication from
> potential rfc5575bis-only nodes you eliminate my concern.

OK, we can work something out.

How about:

 Note that implementation of this section of this specification will be
 Controllers or Classifiers communicating with each other directly for 
the purpose of instructing the
 Classifier how to place packets onto an SFP.  In order that the 

Re: [bess] I-D Action: draft-ietf-bess-nsh-bgp-control-plane-15.txt

[Adrian Farrel]

BESS,

This revision adopts the text and registry change as just discussed on list
with Ketan.

Thanks,
Adrian

-Original Message-
From: I-D-Announce  On Behalf Of
internet-dra...@ietf.org
Sent: 15 June 2020 13:05
To: i-d-annou...@ietf.org
Cc: bess@ietf.org
Subject: I-D Action: draft-ietf-bess-nsh-bgp-control-plane-15.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 the Network Service Header
in Service Function Chaining
Authors : Adrian Farrel
  John Drake
  Eric Rosen
  Jim Uttaro
  Luay Jalil
Filename: draft-ietf-bess-nsh-bgp-control-plane-15.txt
Pages   : 69
Date: 2020-06-15

Abstract:
   This document describes the use of BGP as a control plane for
   networks that support Service Function Chaining (SFC).  The document
   introduces a new BGP address family called the SFC Address Family
   Identifier / Subsequent Address Family Identifier (SFC AFI/SAFI) with
   two route types.  One route type is originated by a node to advertise
   that it hosts a particular instance of a specified service function.
   This route type also provides "instructions" on how to send a packet
   to the hosting node in a way that indicates that the service function
   has to be applied to the packet.  The other route type is used by a
   Controller to advertise the paths of "chains" of service functions,
   and to give a unique designator to each such path so that they can be
   used in conjunction with the Network Service Header defined in RFC
   8300.

   This document adopts the SFC architecture described in RFC 7665.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-nsh-bgp-control-plane/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bess-nsh-bgp-control-plane-15
https://datatracker.ietf.org/doc/html/draft-ietf-bess-nsh-bgp-control-plane-
15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-nsh-bgp-control-plane-15


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:
ftp://ftp.ietf.org/internet-drafts/


___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

[bess] Discusses on draft-ietf-bess-nsh-bgp-control-plane

[Adrian Farrel]

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 anything the authors can do to help with this?

Thanks,
Adrian

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

[bess] New version: draft-ietf-bess-datacenter-gateway-07.txt

[Adrian Farrel]

Hi,

This late-breaking revision just tweaks for the discussion with Boris.

Thanks,
Adrian

-Original Message-
From: BESS  On Behalf Of internet-dra...@ietf.org
Sent: 04 June 2020 18:33
To: i-d-annou...@ietf.org
Cc: bess@ietf.org
Subject: [bess] I-D Action: draft-ietf-bess-datacenter-gateway-07.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   : Gateway Auto-Discovery and Route Advertisement for
Segment Routing Enabled Domain Interconnection
Authors : Adrian Farrel
  John Drake
  Eric Rosen
  Keyur Patel
  Luay Jalil
Filename: draft-ietf-bess-datacenter-gateway-07.txt
Pages   : 12
Date: 2020-06-04

Abstract:
   Data centers are critical components of the infrastructure used by
   network operators to provide services to their customers.  Data
   centers are attached to the Internet or a backbone network by gateway
   routers.  One data center typically has more than one gateway for
   commercial, load balancing, and resiliency reasons.

   Segment Routing is a protocol mechanism that can be used within a
   data center, and also for steering traffic that flows between two
   data center sites.  In order that one data center site may load
   balance the traffic it sends to another data center site, it needs to
   know the complete set of gateway routers at the remote data center,
   the points of connection from those gateways to the backbone network,
   and the connectivity across the backbone network.

   Segment Routing may also be operated in other domains, such as access
   networks.  Those domains also need to be connected across backbone
   networks through gateways.

   This document defines a mechanism using the BGP Tunnel Encapsulation
   attribute to allow each gateway router to advertise the routes to the
   prefixes in the Segment Routing domains to which it provides access,
   and also to advertise on behalf of each other gateway to the same
   Segment Routing domain.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-datacenter-gateway/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bess-datacenter-gateway-07
https://datatracker.ietf.org/doc/html/draft-ietf-bess-datacenter-gateway-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-datacenter-gateway-07


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:
ftp://ftp.ietf.org/internet-drafts/


___
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

[bess] Closing on Stephane's open issue with draft-ietf-bess-datacenter-gateway

[Adrian Farrel]

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

An option was to use the Route Origin extended community instead.

RFC 4360, which introduces both the Route Target and the Route Origin
extended communities and gives some guidance. Loosely expressed, the RT says
which routers should import, the RO says which routers have advertised. In
both cases, the text suggests that "One possible use of the community is
specified in RFC4364" which implies that there are other acceptable uses.

4364 implies that the RO is used "to uniquely identify the set of routes
learned from a particular site." That is (my words), to apply a filter on
top of the RT to prevent re-import by a site of routes that match the RT and
that were advertised by other entry points to the site. Indeed, the RO would
seem to be used (in the 4364 case) only when the RT is also in use.

We appreciate that the distinction is pretty delicate, but we think we are
right to use RT in this case because we are filtering to import, not to
avoid importing. Furthermore, if we used the RO then, to be consistent with
4364, we would still be using the RT anyway.

That, we think, disposes of the "RT or RO?" question.

Now, we can go back to the original formulation of the question: is it OK to
use RT with "non-VPN IP addresses"? Well, we consulted around a bit
privately amongst some BGP experts, and we couldn't find anyone to say it
was actually a problem. And (of course) no one raised the issue in WG last
call - but Matthew might claim that is because the document was only lightly
reviewed, and Stephane might claim that this is because he had already
raised the point. Obviously, some of the authors know a bit about BGP, and
Eric was a lead author on 4364 and drove a lot of the details of what we
wrote.

Two points in closing:
- If someone can show that we break something, we will have to fix it.
- If the chairs want to run this point past IDR and BESS explicitly, that
would be fine.

Hope this helps.

Best,
Adrian

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

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

[Adrian Farrel]

OK Boris, I get it (thanks to John for hitting me with an appropriately 
socially distanced piece of timber!).

 

Yes, we should consider the SR domains as ASes. Yes, I’ll add this note. Yes, 
I’ll update figure 1.

 

Best,

Adrian

 

From: Boris Hassanov  
Sent: 03 June 2020 20:35
To: 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 Monday, June 1, 2020, 11:16:17 PM GMT+3, Adrian Farrel  
wrote: 

 

 

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'm looking at the figure and I don't understand your confusion: sorry.
>> The ASes are not used for Ingress and Egress SR Domains. The two

>> domains are marked separately.
>> Packets are routed from the Ingress SR domain to the Egress SR

>> domain through the Gateways (also marked) and across the ASes

>> that provide connectivity.

>  

> BKH>  The text after Fig.1 says about limitations of BGP Add-Path

> especially in Inter-AS case with ASBRs in regards to GW identity,

> but Fig.1 also have AS3, it makes some dissonance with that

> message, IMO. That is why I was confused. May be I was just too

> focused on details :)

 

I’m not sure. Maybe if we had numbered the ASes differently so that the obvious 
least AS-hops (“shortest”) path was through AS1, and AS2/AS3 was the path that 
would lose the GW identities?

 

But I still don’t see the problem you are raising, and I really want to.

 

The figure shows that there are multiple possible routes from ingress domain to 
egress domain:

*   GW-AS3-GW2
*   GW-AS1-[choice of ASBRs]-AS2-GW1
*   GW-AS1-[choice of ASBRs]-AS2-GW2

The text notes that:

*  Add-Paths enables the presentation of {AS3} and {AS1, AS2} as paths 

*  Add-Paths loses the identities and so choice of GW1 and GW2 in the {AS1, 
AS2} case

 

 BKH> I think, that t would be better to clarify the relationship between 
Ingress and Egress SR domains with AS1,AS2,AS3 from BGP point of view on FIg 1. 
Are they  just part of AS3 (so IBGP between GW and PE of AS3) or  separate ASes 
(EBGP), it will be much easier to understand the further steps in regards to 
why Add Path is not suitable there.

 

 

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

Re: [bess] I-D Action: draft-ietf-bess-nsh-bgp-control-plane-14.txt

[Adrian Farrel]

Hi Bess,

You may have seen me responding to various IESG Discusses and Comments, and
to the Routing Directorate review for this draft.

This revision makes all of the associated changes. There is a fairly high
level of change, but we believe that the changes are not very substantive.

Please take some time to look at the diffs and shout if anything is alarming
or unclear.

Many thanks,
Adrian

-Original Message-
From: I-D-Announce  On Behalf Of
internet-dra...@ietf.org
Sent: 02 June 2020 09:05
To: i-d-annou...@ietf.org
Cc: bess@ietf.org
Subject: I-D Action: draft-ietf-bess-nsh-bgp-control-plane-14.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 the Network Service Header
in Service Function Chaining
Authors : 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-02

Abstract:
   This document describes the use of BGP as a control plane for
   networks that support Service Function Chaining (SFC).  The document
   introduces a new BGP address family called the SFC Address Family
   Identifier / Subsequent Address Family Identifier (SFC AFI/SAFI) with
   two route types.  One route type is originated by a node to advertise
   that it hosts a particular instance of a specified service function.
   This route type also provides "instructions" on how to send a packet
   to the hosting node in a way that indicates that the service function
   has to be applied to the packet.  The other route type is used by a
   Controller to advertise the paths of "chains" of service functions,
   and to give a unique designator to each such path so that they can be
   used in conjunction with the Network Service Header defined in RFC
   8300.

   This document adopts the SFC architecture described in RFC 7665.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-nsh-bgp-control-plane/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bess-nsh-bgp-control-plane-14
https://datatracker.ietf.org/doc/html/draft-ietf-bess-nsh-bgp-control-plane-
14

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-nsh-bgp-control-plane-14


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:
ftp://ftp.ietf.org/internet-drafts/


___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

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

[Adrian Farrel]

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'm looking at the figure and I don't understand your confusion: sorry.
>> The ASes are not used for Ingress and Egress SR Domains. The two

>> domains are marked separately.
>> Packets are routed from the Ingress SR domain to the Egress SR

>> domain through the Gateways (also marked) and across the ASes

>> that provide connectivity.

> 

> BKH>  The text after Fig.1 says about limitations of BGP Add-Path

> especially in Inter-AS case with ASBRs in regards to GW identity,

> but Fig.1 also have AS3, it makes some dissonance with that

> message, IMO. That is why I was confused. May be I was just too

> focused on details :)

 

I’m not sure. Maybe if we had numbered the ASes differently so that the obvious 
least AS-hops (“shortest”) path was through AS1, and AS2/AS3 was the path that 
would lose the GW identities?

 

But I still don’t see the problem you are raising, and I really want to.

 

The figure shows that there are multiple possible routes from ingress domain to 
egress domain:

*   GW-AS3-GW2
*   GW-AS1-[choice of ASBRs]-AS2-GW1
*   GW-AS1-[choice of ASBRs]-AS2-GW2

The text notes that:

*   Add-Paths enables the presentation of {AS3} and {AS1, AS2} as paths
*   Add-Paths loses the identities and so choice of GW1 and GW2 in the 
{AS1, AS2} case

 

>>> 3) If new Tunnel Encapsulation is defined as SR Tunnel, will 
>>>  ietf-idr-tunnel-encaps be updated accordingly?  15th version
>>>  does not have it so far

>>
>> I don't believe that other document needs to be updated.
>> The code point has already been assigned for this draft. You can see

>> it at 
>> https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#tunnel-types

> 

> Adrian, sorry, one last question:

> Part 3. SR Domain GW AD

>...

> To avoid the side effect of applying the Tunnel Encapsulation
> attribute to any packet that is addressed to the GW itself, the GW
> SHOULD use a different loopback address for the two cases.

> Am I correct that these two cases do mean: 

> 1) Loopback for AD route 

> 2) Loopback for other purposes (i.e. receiving packets addressed

>   to the GW itself) ?

> So GW should advertise 2 different loopbacks, one with Tunnel

> Encapsulation attribute and another without it.

 

Yes, you got it.

 

Best,

Adrian

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

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

[Adrian Farrel]

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 popular protocol mechanism for use within a DC...". I would love to see 
> SR as
>  popular mechanism within DC worldwide, but such statement requires either  a 
>  reference to some cases/examples of SR-baced DCs or, IMO, has to be changed
>  to something like "...become a popular mechanism..." 

Depends on the meaning of popular 

Changed text in Abstract to...
   Segment Routing is a protocol mechanism that can be used within a data 
center,
   and also for steering traffic that flows between two data center sites.
...and in the Introduction to...
   Segment Routing (SR) [RFC8402] is a protocol mechanism that can be used 
within
   a DC, and also for steering traffic that flows between two DC sites.

>
> 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'm looking at the figure and I don't understand your confusion: sorry.
The ASes are not used for Ingress and Egress SR Domains. The two domains are 
marked separately.
Packets are routed from the Ingress SR domain to the Egress SR domain through 
the Gateways (also marked) and across the ASes that provide connectivity.

> 3) If new Tunnel Encapsulation is defined as SR Tunnel, will 
>  ietf-idr-tunnel-encaps be updated accordingly?  15th version
>  does not have it so far

I don't believe that other document needs to be updated.
The code point has already been assigned for this draft. You can see it at 
https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#tunnel-types

Best,
Adrian


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

Re: [bess] Alvaro Retana's Discuss on draft-ietf-bess-nsh-bgp-control-plane-13: (with DISCUSS and COMMENT)

[Adrian Farrel]

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 hosting an SFI or a Controller.  Each
> route type has a specific function and it is reasonable to expect that the
> originators represent different nodes in the network, with different 
> functions,
> location, etc..  BGP Capabilities Advertisement doesn't have a route type
> granularity; instead, a BGP speaker known to support the SFC NLRI could
> originate any type of route.
>
> The facts above open the possibility that any node in the network can 
> originate
> an SFPR and take over an SFP.  §3.2.2 does a very good job of explaining the
> potential existence of multiple Controllers and even offers the appropriate 
> tie
> breaker to take control of the SFP: "MUST use the SFPR with the numerically
> lowest SFPR-RD".
>
> The document proposes no mitigation to the possibility of any node (a rogue
> node, for example) issuing SFPRs.  The assumption (§2.2) of "BGP connectivity
> between the Controllers and all SFFs" introduces also the ability to locate a
> rogue controller anywhere; I interpret "BGP connectivity" to include the
> presence of a router reflector (for example), which then allows distribution 
> of
> SFPRs without going through a central policy point.
>
> On one hand I think this condition is a feature (the Controller can be
> anywhere), but the case of a rogue node that wants to act as a controller is
> not considered.
>
> To address this issue, I would like to see text that (1) acknowledges the 
> issue
> (maybe in the security considerations section), and (2) discusses operational
> considerations for the placement, control, filtering, etc. of Controllers and
> the corresponding UPDATES from them and/or other nodes in the network.  IOW,
> the considerations around proper initial setup of the system should be clear.

1. The controllers are not SDN controllers. They are not single omnipotent, 
all-seeing god boxes. They are boxes that control. They could be dedicated 
devices, management systems, distributed servers, or network devices. They are, 
simply put, BGP speakers. 

2. The challenges and concerns that you raise are not dissimilar to the general 
attack vectors in a routing system, and should be thought of in the same way. 
What happens if a "rogue" router starts issuing bogus routes?

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 against rogue 
players.

> (2) New Flow Specification Traffic Filtering Action
>
> §7.4 (Flow Spec for SFC Classifiers) defines a new Traffic Filtering Action to
> be used with the Flow Specification NLRI.  rfc5775bis allows for any
> combination of Traffic Filtering Actions to be present, but this document says
> that "other action extended communities MUST NOT be present".  I believe that
> specifying the use of treat-as-withdraw is ok as a case of Traffic Filtering
> Action Interference -- I just say "ok" because it is not clear to me (nor
> explained anywhere) why other Traffic Filtering Actions cannot be used; for
> example, I could imagine rate-limiting the traffic into an SFP.
>
> What concerns me more (and the reason for this DISCUSS point) is that
> rfc5575-only implementations will not consider the new Traffic Filtering
> Action, but could, depending on the components encoded in the NLRI, take
> actions based on other Traffic Filtering Actions.  The result can then be an
> inconsistent application of Traffic Filtering Actions in the network -- for
> example, some nodes may want to drop the matching traffic (traffic-rate of 0),
> while others may want to have the same traffic entering an SFP.
>
> What are the operational considerations of using the new Traffic Filtering
> Action in a network where "legacy" (rfc5575bis-only) nodes exist?  Is there a
> potential migration path?  What might be the impact?  How can correct 
> operation
> be verified?

I said:
: Hmmm, we don't tent to explain why "MUST NOT" in our specifications.
: The reasoning here is that it would be highly confusing to mix and match
: SFC Classification with BGP routing. Perhaps I am wrong about that
: confusion.
: I think that when you program an SFC classifier, that is a single peer-to-
: peer communication targeted at an SFC Classifier.
: A 5575-only node will not be a classifier.

You responded:
| I raised this point as a DISCUSS because the text is at odds with other
| standards track documents.  That is the reason I'm asking for an explanation.

An SFC overlay network consists of SFIs, SFFs, Controllers, and Classifiers. 
The fact that we re-use RFC 5575 in our Classifiers
does not mean that an RFC 5575-only node is a Classifier. I.e., a service 
provider that is installing an SFC overlay 

Re: [bess] RtgDir review: draft-ietf-bess-nsh-bgp-control-plane-13

[Adrian Farrel]

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 overly 
> repetitive
> and a bit pedantic….which takes away from the readability a bit when one is 
> reading
> the sections in the order listed. Content of RFC7665/8300 are also 
> contributors to this.
> Eg: "In fact, each SI is mapped to one or more SFs that are implemented by 
> one or
> more Service Function Instances (SFIs) that support those specified SFs. "  : 
> almost
> sounds like legalese when someone who has not grasped the complete picture of
> the draft.
>
> Wrote up the above as I was reading that section for the first time.
> However, after finishing the review…started to appreciate this.

We've changed this to...
Within the context of a specific SFP, an SI references a set of one or more 
SFs.  Each
of those SFs may be supported by one or more Service Function Instances (SFIs).
...although we are slightly worried that we may have lost some precision.

> In having read the sections in order, I think the readability would have been 
> greatly enhanced if I had read section 8 first, else once just gets lost in 
> all the details.
> It would be worthwhile suggesting in the text that once the reader has read 
> through
> section 2, it would help to read section 8 before reviewing the intervening 
> sections.
>
> [JD]  Fine w/ me 
 
We have put in the forward pointer.

> 2. Section 3.2.1: page 16:
> "[RFC7606]
>   revises BGP error handling specifically for the for UPDATE message,"
> 
> ->
> "[RFC7606]
>   revises BGP error handling specifically for the UPDATE message,”

Ack

> 3. Page 17:
>  a. Was the intention for treating error 4 any different from errors, 
> [1,2,6,7]?
> If not, why the need to call out 4 separately?

4 should be treated the same as 1, 2, 6, and 7 
Fixed

>  b. "Unknown SFIR-RD found in a Hop TLV." :
> The format of the Hop TLV in section 3.2.1.2 contains no reference to an
> RD. So, was the intention instead to refer to the SFIR-RD list of one of the
> SFT TLVs inside the Hop TLV?

8 should be “Unknown SFIR-RD found in an SFT TLV” 

> 4.
> Section 3.2.1.2: "At least one sub-TLV MUST be present. "
> Where are these sub-TLVs defined?
> In this regard,
>  a. Section 3.2.1.3 says "The SFT TLV MAY be included in the list of sub-TLVs
>  of the Hop TLV.":
>  b. Section 3.2.1.4 says "The MPLS Swapping/Stacking TLV (Type value 4) is a 
> zero length sub-TLV that is OPTIONAL in the Hop TLV "
>
> In the absence of specific mention of details of sub-TLVs in section 3.2.1.2,
> is a reader to assume that SFT TLVs & the MPLS swap/stack TVLs are the
> only possible subTLVs under a hop-TLV (as intended in this revision of the
> ID)?
> This aspect becomes clear later, when one gets to reading the description
> of the subsequently mentioned TLVs. Might be worth alluding to this in 
> 3.2.1.2.

3.2.1.2 now reads
"At least one sub-TLV MUST be present. This document defines the SFT Sub-TLV 
(see Section 3.2.1.3) and the MPLS Swapping/Stacking Sub-TLV (see Section 
3.2.1.4): other sub-TLVs may be defined in future."

> 5.
>"In the normal case the SPI remains unchanged and the SI will have been 
> decremented to indicate the next SF along the path.": will SI really be
> decremented instead of just setting it to the appropriate value? As per
> this draft, set to an appropriate lower value…

Contemplated changing this to...
 “and the SI set to the value for the next hop in the SFP”.

However, in discussion way back, the SFC WG was pretty adamant about using the 
term "decremented" and we would like to remain consistent with their usage.

> 6.
> What exactly does the following mean? "Also, as described in [RFC8300],
> an SFF receiving an SI that is unknown in the context of the SPI can reduce
> the value to the next meaningful SI value in the SFP indicated by the SPI.
> If no such value exists or if the SFF does not support this function, the SFF
> drops the packet and should log the event: such logs are also subject to
> rate limits."

s/this function/reducing the SI/

> 7. 
> Figure 1: showing the SFIs hosted on SFF2 and SFF3 in the same
> conceptual block (just because they share the same type) is a bit
> confusing when the diagram is showing a logical view of the physical
> layout of the elements of the solution.

We re-read the associated text and thought it was clear. 

The blocking is not "just because they share the same type" but is indicative 
of them sharing the same type.

> 8.
> Section 3.1:the following is an ambiguous sentence & I suggest
> rewording to clarify:
> "Note that it is assumed that each SFF has one or more globally
> unique SFC Context Labels and that the context label space and
> the SPI address space are disjoint." 
> This sounds like that the "context label space" and the "SPI
> 

Re: [bess] Benjamin Kaduk's Discuss on draft-ietf-bess-nsh-bgp-control-plane-13: (with DISCUSS and COMMENT)

[Adrian Farrel]

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 see how it's
> defined to intermingle the (six-octet) Pool Identifier Value with
> the (eight-octet) RDs.

That's because we include the entire extended community not just the value 
field.  The first two octets indicate whether the extended community is an RD 
or SFIR Pool Identifier. Each entry has to be read and processed so there is no 
question of needing to know the length to step over it.

> Section 3.1 seems to allow multiple SFIRs associated with a given
> RD, but the rest of the document seems to assume that any RD
> has at most one associated SFIR (as is stated explicitly for SFPRs).
> (A few specific mentions in the COMMENT.)

Right. There is NOT a 1:1 mapping between an SFIR and an RD. But we have some 
legacy text that is not clear on that point and we are scrubbing it.

Note that Section 3.1 describes two cases, advertising a single SFIR to 
represent more than one SFI of a given SFT and advertising an SFIR for each SFI 
of a given SFT.

> Within my own limited understanding, it seems like this document is
> expanding the boundaries of the SFC Architecture in ways not envisioned
> by RFC 7665 or 8300, and the shepherd writeup is pretty quiet on to what
> extent this architectural change is accepted by the WG (as opposed to
> being contained to just the BGP control plane mechanism).  I'd like to
> get a positive affirmation from someone more familiar with the
> discussions that this is moving the architecture in the right direction
> with respect to things like:
> - the introduction of the Service Function Type intermediate
>   classification
> - the more prominent treatment of looping, jumping, and branching as
>  operations within a single SFP without reclassification by using the
>  "Change Sequence" SFT entries to indicate these behaviors within the
>  SFP definition itself (I note that RFC 7665 does not mention "jump" at all)
> - the introduction of "gaps" in the SI sequence of a given SFP

Note that "classification" and "reclassification" are slightly fudged (my 
opinion) in the 8300 architecture. They may be performed by a separate 
component, but that is a functional component that can be built into any other 
component of the system. Thus, an SF might reasonably have a reclassifier that 
makes decisions to continue forwarding a packet or to send it to a penalty box. 
All of the functions of looping, jumping, and branching (the penalty box 
example is a branch) are done through reclassification.

We took particular care to socialise this work with the SFC working group 
presenting it to the WG at IETF meetings. The BESS working group last call was 
also copied to the SFC list. We did receive some comments that helped improve 
the work, but no complaints about infringing the architecture.

I guess the SFC chairs can confirm this if you're still worried.

> With respect to SFT in particular, it sounds like this is intended to
> help with scalability, which makes the genart reviewer's comment about
> lack of implementation experience particularly poingant.  It seems like
> SFIR pools perform a similar role, though of course not identical; I
> didn't get a clear sense of why pools without SFTs are insufficient.

SFT allows for an SFF to not need to advertise more than one instance of an SF 
of that type, which is a scalability thing. But, more importantly, it allows a 
controller to not need to specify a specific SFI at an SFF just saying "any SFI 
of this type" making the work of the controller a bit easier, and leaving local 
load balancing choices to the SFF.

The pool is a more diffused tool. All SIs still need to be advertised so that 
they can be included in the pool. The pool tells two SFFs to make a choice:
- an SFF may have to choose between multiple local SFIs in the same pool
- an SFF may have to choose between multiple next hop SFFs to satisfy the next 
hop pool

Pools also reduce the re-advertisement of SFPRs which would otherwise occur 
when the SFIR-RD list changes (so that is a scalability thing, I suppose).

Note that it is not a requirement that all SFIs in a pool are of the same type. 
For example, there might be FooCorp's firewall and BarCorp's firewall with 
different SFT values but in the same pool.

See sections 1.2, 2.2, and 3.1 for additional info.

> COMMENT:
> -
>
> I support Roman's Discuss.

I copied you on the response to that with proposed new text for section 9.

> Section 2.1
>
>   In fact, each SI is mapped to one or more SFs that are implemented by
>   one or more Service Function Instances (SFIs) that support those
>   specified SFs.  Thus an SI may represent a choice of SFIs of one or
>   more 

[bess] Roman Danyliw's Comments on draft-ietf-bess-nsh-bgp-control-plane-13

[Adrian Farrel]

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 node hosting the service function
>instance”
>
> 2. “We assume BGP connectivity between the Controller and all SFFs
>  within each service function overlay network”
>
> Is the node referenced in statement (1) the SFF.  If not, it seems like they
> need to be added to statement #2 as entities that have BGP connectivity.

Yes, 1) refers to the SFF. We will add "... (i.e., the SFF)"

> * Section 2.2.  Per Figure 1, where is the “Controller” in this reference 
> model?

Per the previous quote 2) it would be impractical to show the controllers in 
Figure 1 with connectivity to each SFF. Furthermore, the figure is the SFC 
(forwarding plane) architecture not the SFC control plane architecture.

But the paragraph immediately before the figure starts "Note that, for 
convenience and clarity..." so this is a good place for us to make the clear 
how the controllers fit in.

> * Section 3.1.  Per “If two SFIRs are originated from different administrative
> domains …”, are these administrative domains still in a “within a single
> provider's operational domain” per Section 2.2.?

Yes. Clarified in the text.

> * Section 3.1.1.  Per the SFIR Pool Identifier Value being “globally unique”,
> is that globally unique per Controller? Per overlay network?

Per overlay network. Clarified in the text.
Makes note to *never* use "globally unique" again ☹

> * Section 4.3.  Per the summary notation of “RT, {SFPR-RD, SPI}, m * {SI, {n *
> {SFT, p * SFIR-RD} } }”, it isn’t clear to me what this expression is
> summarizing.  Also, what does the “*” mean?

It is a multiplier. We think that everyone (else) has understood this so far, 
but have added a clarifying note.

> * Section 4.5.1. Per “Therefore, while this document requires that the SI
> values in an SFP are monotonic decreasing, it makes no assumption that the SI
> values are sequential.”, should this “requires” be a RFC2119 MUST or REQUIRED?

I think this text is commentary and using 2119 language would be inappropriate.
You can find the actual requirements language in section 4.3.

> * Section 6.  Per “Therefore, the use of NSH metadata may be required in order
> to prevent infinite loops”, what is this meta-data?

We'll add a reference to the SFC WG definition of metadata (RFC 8300).

> * Section 7.2.  Per “In such cases it can be important or necessary that all
> packets from a flow continue to traverse the same instance of a service
> function so that the state can be leveraged and does not need to be
> regenerated.”, how is this requirement signaled through the SFIRs for the
> computation of SFPs?

It is expected that a controller that computes an SFP has knowledge of the 
functions that need to be included on the path. Such knowledge includes the 
ordering of functions (it's not just a set of functions, but a sequence), the 
alternative implementations of functions (as conveyed by different SFTs), and 
the statefulness of functions. Note that it is not really an implementation 
choice whether a function is stateful - much more it is dependent on the 
function being performed (I think a bidirectional firewall may be a good 
example).

So, having said all that, the SFIRs do not specifically indicate "this SF (or 
this SI) is stateful."

> * Editorial Nits:
> - Section 2.2. s/channelled/channeled/
> - Section 4.5.1. s/bevahior/behavior/

Thanks

> - Section 7.1.  Per “As noted in Section 3.2.1.1 SFPRs reference each other
> one SFPR advertisement will be received before the other.”, this sentence
> didn’t parse for me.

Missing "if" or "when"

> - Section 8.9.1. Typo.  s/is is/is/

Thanks

Best,
Adrian

___
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

[Adrian Farrel]

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 24th 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> 
https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw

 

 

___
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

[Adrian Farrel]

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 24th 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] IETF 107 BESS meeting will be cancelled

[Adrian Farrel]

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 follow from the previous statement. Remote chairing, proxy 
chairing, etc., etc. are possibilities.

Consider that interim meetings are usually virtual these days, and work fine.

 

> For your information, we received only 2 slots requests for now,

> while in general the agenda was almost full.

 

Now, that is a good reason not to have a 3.5 hours of meetings 

But also, it should be easy to have 20 minutes of meeting (virtual or 
otherwise) to accommodate those 2 slots.

Wednesday morning in Canada would even fit within the chairs’ domestic time 
zones.

 

If, on the other hand, you were going to reject the 2 slot requests leaving an 
empty agenda, that’s a different matter.

 

> We, chairs, will keep you posted soon on the way we will proceed

> to do a sync-up before next IETF physical meeting.

 

Thanks. That is much appreciated.

 

Best,

Adrian

 

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

Re: [bess] Roman Danyliw's Discuss on draft-ietf-bess-nsh-bgp-control-plane-13: (with DISCUSS and COMMENT)

[Adrian Farrel]

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 Message-
From: Roman Danyliw via Datatracker  
Sent: 18 December 2019 19:15
To: The IESG 
Cc: draft-ietf-bess-nsh-bgp-control-pl...@ietf.org; bess-cha...@ietf.org; 
slitkows.i...@gmail.com; bess@ietf.org
Subject: Roman Danyliw's Discuss on draft-ietf-bess-nsh-bgp-control-plane-13: 
(with DISCUSS and COMMENT)

Roman Danyliw has entered the following ballot position for
draft-ietf-bess-nsh-bgp-control-plane-13: 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-nsh-bgp-control-plane/



--
DISCUSS:
--

* Section 9 cites a number of references (which cite additional references) on
BGP security.  My summary of the highlights is:

(1) RFC4271 => TCP MD5 (RFC2385) is a MUST
(2) RFC4271 => consider RFC 3562 for key management guidance
(3) ietf-idr-tunnel-encaps => caution on Tunnel Encapsulation attribute
(4) rfc4364 => TCP MD5 is a non-rfc2119 “should”
(5) rfc4364 => don’t make connections with untrusted peers
(6) RFC7432 => references the utility of TCP-AO (RFC5925)

- Could the text articulate more clearly de-conflict (1), (4) and (6) – what is
the recommended approach?

- a discuss-discuss – Given the green field nature of this specification (the
shepherd’s report notes no implementation) and the assumed SFC deployment model
(not the internet; a single provider’s operational domain where key management
should be easier), could a more robust transport security option such as BGP
over IPSec be RECOMMENDED?


--
COMMENT:
--

* Section 2.2.  Could you please clarify connect between these two statements
about the SFC architecture:

1. “The SFIR is advertised by the node hosting the service function instance”

2. “We assume BGP connectivity between the Controller and all SFFs within each
service function overlay network”

Is the node referenced in statement (1) the SFF.  If not, it seems like they
need to be added to statement #2 as entities that have BGP connectivity.

* Section 2.2.  Per Figure 1, where is the “Controller” in this reference model?

* Section 3.1.  Per “If two SFIRs are originated from different administrative
domains …”, are these administrative domains still in a “within a single
provider's operational domain” per Section 2.2.?

* Section 3.1.1.  Per the SFIR Pool Identifier Value being “globally unique”,
is that globally unique per Controller? Per overlay network?

* Section 4.3.  Per the summary notation of “RT, {SFPR-RD, SPI}, m * {SI, {n *
{SFT, p * SFIR-RD} } }”, it isn’t clear to me what this expression is
summarizing.  Also, what does the “*” mean?

* Section 4.5.1. Per “Therefore, while this document requires that the SI
values in an SFP are monotonic decreasing, it makes no assumption that the SI
values are sequential.”, should this “requires” be a RFC2119 MUST or REQUIRED?

* Section 6.  Per “Therefore, the use of NSH metadata may be required in order
to prevent infinite loops”, what is this meta-data?

* Section 7.2.  Per “In such cases it can be important or necessary that all
packets from a flow continue to traverse the same instance of a service
function so that the state can be leveraged and does not need to be
regenerated.”, how is this requirement signaled through the SFIRs for the
computation of SFPs?

* Editorial Nits:
- Section 2.2. s/channelled/channeled/

- Section 4.5.1. s/bevahior/behavior/

- Section 7.1.  Per “As noted in Section 3.2.1.1 SFPRs reference each other one
SFPR advertisement will be received before the other.”, this sentence didn’t
parse for me.

- Section 8.9.1. Typo.  s/is is/is/


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

Re: [bess] Alvaro Retana's Discuss on draft-ietf-bess-nsh-bgp-control-plane-13: (with DISCUSS and COMMENT)

[Adrian Farrel]

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 dedicated 
devices, management systems, distributed servers, or network devices. They are, 
simply put, BGP speakers. 

2. The challenges and concerns that you raise are not dissimilar to the general 
attack vectors in a routing system, and should be thought of in the same way. 
What happens if a "rogue" router starts issuing bogus routes?

So, you are right that this can be highlighted in the security section, and we 
can note the existing mitigations in a BGP-based routing system against rogue 
players. But I doubt that anything "special" is needed.

> (2) New Flow Specification Traffic Filtering Action

Hmmm, we don't tent to explain why "MUST NOT" in our specifications.
The reasoning here is that it would be highly confusing to mix and match SFC 
Classification with BGP routing. Perhaps I am wrong about that confusion.
I think that when you program an SFC classifier, that is a single peer-to-peer 
communication targeted at an SFC Classifier.
A 5575-only node will not be a classifier.

> (3) Use of the Control Plane
>
> This last point is not specifically for the authors, but for the
> Responsible AD and the Chairs for the sfc WG (cc'd).

Nevertheless, one of the authors will answer.

I do not agree that knowledge of SFTs is essential to the construction of SFPs. 
I think it is very helpful, but I note that an initial system would have good 
knowledge of the location and capabilities of SFIs in the network, specifically 
because the "orchestrator" has created and located them. Thus, the creator of 
the SFP also knows the locations and types of the SFIs.

What this draft does is open the door for future more dynamic approaches.
What might be surprising would be if the FCFS registry of SFT values had been 
populated prior to creation of the registry 

Best,
Adrian

===

(1) Controllers and other nodes.

Background: This document defines the new SFC NLRI, which has two distinct
route types, originated by either a node hosting an SFI or a Controller.  Each
route type has a specific function and it is reasonable to expect that the
originators represent different nodes in the network, with different functions,
location, etc..  BGP Capabilities Advertisement doesn't have a route type
granularity; instead, a BGP speaker known to support the SFC NLRI could
originate any type of route.

The facts above open the possibility that any node in the network can originate
an SFPR and take over an SFP.  §3.2.2 does a very good job of explaining the
potential existence of multiple Controllers and even offers the appropriate tie
breaker to take control of the SFP: "MUST use the SFPR with the numerically
lowest SFPR-RD".

The document proposes no mitigation to the possibility of any node (a rogue
node, for example) issuing SFPRs.  The assumption (§2.2) of "BGP connectivity
between the Controllers and all SFFs" introduces also the ability to locate a
rogue controller anywhere; I interpret "BGP connectivity" to include the
presence of a router reflector (for example), which then allows distribution of
SFPRs without going through a central policy point.

On one hand I think this condition is a feature (the Controller can be
anywhere), but the case of a rogue node that wants to act as a controller is
not considered.

To address this issue, I would like to see text that (1) acknowledges the issue
(maybe in the security considerations section), and (2) discusses operational
considerations for the placement, control, filtering, etc. of Controllers and
the corresponding UPDATES from them and/or other nodes in the network.  IOW,
the considerations around proper initial setup of the system should be clear.

(2) New Flow Specification Traffic Filtering Action

§7.4 (Flow Spec for SFC Classifiers) defines a new Traffic Filtering Action to
be used with the Flow Specification NLRI.  rfc5775bis allows for any
combination of Traffic Filtering Actions to be present, but this document says
that "other action extended communities MUST NOT be present".  I believe that
specifying the use of treat-as-withdraw is ok as a case of Traffic Filtering
Action Interference -- I just say "ok" because it is not clear to me (nor
explained anywhere) why other Traffic Filtering Actions cannot be used; for
example, I could imagine rate-limiting the traffic into an SFP.

What concerns me more (and the reason for this DISCUSS point) is that
rfc5575-only implementations will not consider the new Traffic Filtering
Action, but could, depending on the components encoded in the NLRI, take
actions based on other Traffic Filtering Actions.  The result can then be an
inconsistent application of Traffic Filtering Actions in the network -- for
example, some nodes may want to 

Re: [bess] Barry Leiba's No Objection on draft-ietf-bess-nsh-bgp-control-plane-13: (with COMMENT)

[Adrian Farrel]

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 times in the document, but this one 
> is
> incorrect: “comprised of” should instead be either “comprising” or “composed
> of”.  I only bother mentioning it because it’s right the four other times.

I just consulted an English copy editor who says "comprised of" is correct. 
Let's leave this to the RPC to apply house style.

> — Section 3.1 —
>
>   The Service Function Type identifies the functions/features of
>   service function can offer, e.g., classifier, firewall, load
>   balancer, etc.
>
> Should this be “a service function”, rather than “of service function”?  And a

Yes. Good catch.

> nit: you don’t need both “e.g.” and “etc.” together: either one will do on its
> own.



> — Section 3.2.1 —
>
>   o  The errors listed above are treated as follows:
>
>  1., 2., 6., 7.:  The attribute MUST be treated as malformed and
> the "treat-as-withdraw" approach used as per [RFC7606].
>
>  3.:  Unknown TLVs SHOULD be ignored, and message processing SHOULD
> continue.
>
>  4.:  Treated as a malformed message and the "treat-as-withdraw"
> approach used as per [RFC7606]
>
> Why is 4 not included in the 1,2,6,7 group?  It seems odd to separate it and
> not to make it “MUST”, like the others.

IDR was very specific about how we treated error cases. We tried to comply with 
what they wanted to see.

4 cannot be parsed further and already has 7606 describing it, so it was 
appropriate to pull it out separately. In practice, item 4 is not defining new 
behaviour: such issues will be treated as malformed by definition so (arguably) 
using 2119 language is inappropriate as we are not defining this behaviour.

But, making 4 say "MUST be treated as described in RFC 7606" seems reasonable.

> — Section 9 —
>
>   Service Function Chaining provides a significant attack opportunity:
>   packets can be diverted from their normal paths through the network,
>   can be made to execute unexpected functions, and the functions that
>   are instantiated in software can be subverted.
>
> The second item in the list appears to lack a subject:  can be made to
> execute unexpected functions.

Ah, yes. Originally it was going to be three things applying to packets. We 
will fix it.

Cheers,
Adrian

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

Re: [bess] Adam Roach's No Objection on draft-ietf-bess-nsh-bgp-control-plane-13: (with COMMENT)

[Adrian Farrel]

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 them to use IPv6 exclusively, or to use a mix of IPv4 and IPv6. See
> https://www.iab.org/2016/11/07/iab-statement-on-ipv6/ for further details.


Would the IESG like to do a statement on that so that they don't rely on the 
IAB to direct the content of IETF documents?

I'm in general agreement with you on the use of IPv6 in documents.

I don't want to mix and match through the current examples, because there is a 
flow of continuity between them. But adding some IPv6 examples would be very 
fine.

We have been seeking someone to supply some worked examples: sadly not so many 
people seem keen to help. (Let's not waste time wondering why.)

That leaves us a little stranded, so if you have suggestions or volunteers, 
please put them in touch.

Best,
Adrian

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

Re: [bess] Opsdir last call review of draft-ietf-bess-nsh-bgp-control-plane-13

[Adrian Farrel]

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 Function Chaining within the network)
Section 2.1
   An essential component of this solution is the
   Controller.  This is a network component responsible for planning
   SFPs within the network.  It gathers information about the
   availability of SFIs and SFFs, instructs the control plane about the
   SFPs to be programmed, and instructs the Classifiers how to assign
   traffic flows to individual SFPs.

I don't think this Controller is an "SDN Controller" according to the two 
references you suggest. Indeed, the assumption in this document is that an 
active control plane is in use which is somewhat against the assumptions of the 
documents you point to. You could say that this Controller is more akin to a 
stateful PCE, but I don't even want to make that comparison in this document 
because the use of a PCE normally implies the presence of PCEP.

In short, I think that the text we have to describe a Controller, combined with 
the various explanations throughout the document that say what a Controller 
does, are enough to make the term contained within this document.


You're right about the downrefs.

7665 is, I think, established as a permissible downref. It has been used 
multiple times, although it is not listed at 
https://trac.ietf.org/trac/iesg/wiki/DownrefRegistry

8596 caught me by surprise. I don't understand why it is not Standards Track. 
It uses 2119 language and describes how to implement/interop.

I think I'll leave this to the AD to worry about!


Best,
Adrian

-Original Message-
From: Sheng Jiang via Datatracker  
Sent: 16 December 2019 08:17
To: ops-...@ietf.org
Cc: last-c...@ietf.org; bess@ietf.org; 
draft-ietf-bess-nsh-bgp-control-plane@ietf.org
Subject: Opsdir last call review of draft-ietf-bess-nsh-bgp-control-plane-13

Reviewer: Sheng Jiang
Review result: Has Issues

Reviewer: Sheng Jiang
Review result: Has Issues

Reviewer: Sheng Jiang
Review result: Has Issues

Hi, OPS-DIR, Authors,

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 standard track document describes the use of BGP as a control plane for
networks that support SFC with newly defined BGP Parameters, BGP AF/SAF, BGP
Path Attribute , SFP Attribute TLVs Type Registry, SFP Association Type
Registry and Service Function Type Registry.

This document is clear and well written.

Minor issues:

However, I do have an issue with the terminology controller in this document.
Although the community seems knowing the SDN controller concepts well. There is
no well-defined terminology for it. Therefore, this document are missing the
most fundamental reference. The below three RFCs are potential references for
the terminology, but still not the best suitable one, and they are all
Informational RFCs, which is Downref in this context:

RFC 7426: Software-Defined Networking (SDN): Layers and Architecture Terminology
RFC 8455: Terminology for Benchmarking Software-Defined Networking (SDN)
Controller Performance RFC 8456: Benchmarking Methodology for Software-Defined
Networking (SDN) Controller Performance

And this document has already had two Downref RFC 7665, RFC 8596

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

Re: [bess] I-D Action: draft-ietf-bess-nsh-bgp-control-plane-13.txt

[Adrian Farrel]

Hey WG,

Brian Carpenter did a GenArt review.
Martin did his review as AD.
IANA pointed out a couple of nits.

We addressed the comments and posted.

A

-Original Message-
From: BESS  On Behalf Of internet-dra...@ietf.org
Sent: 13 December 2019 21:01
To: i-d-annou...@ietf.org
Cc: bess@ietf.org
Subject: [bess] I-D Action: draft-ietf-bess-nsh-bgp-control-plane-13.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
Authors : Adrian Farrel
  John Drake
  Eric Rosen
  Jim Uttaro
  Luay Jalil
Filename: draft-ietf-bess-nsh-bgp-control-plane-13.txt
Pages   : 59
Date: 2019-12-13

Abstract:
   This document describes the use of BGP as a control plane for
   networks that support Service Function Chaining (SFC).  The document
   introduces a new BGP address family called the SFC AFI/SAFI with two
   route types.  One route type is originated by a node to advertise
   that it hosts a particular instance of a specified service function.
   This route type also provides "instructions" on how to send a packet
   to the hosting node in a way that indicates that the service function
   has to be applied to the packet.  The other route type is used by a
   Controller to advertise the paths of "chains" of service functions,
   and to give a unique designator to each such path so that they can be
   used in conjunction with the Network Service Header defined in RFC
   8300.

   This document adopts the SFC architecture described in RFC 7665.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-nsh-bgp-control-plane/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bess-nsh-bgp-control-plane-13
https://datatracker.ietf.org/doc/html/draft-ietf-bess-nsh-bgp-control-plane-
13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-nsh-bgp-control-plane-13


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:
ftp://ftp.ietf.org/internet-drafts/

___
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] Genart last call review of draft-ietf-bess-nsh-bgp-control-plane-12

[Adrian Farrel]

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

At the moment I don't have access to a lab, so I won't comment about that.
I will note four things:
1. I don't consider the mechanism to be "pretty complex", but "rather simple". 
It may be that the difference is whether you have to pick up all of BGP to 
understand this draft or whether it comes as a small increment.
2. Obviously (?) the document has had eyes from a number of BGP experts 
especially a very careful review by the document shepherd. It was shared with 
IDR and caught comments from one of the IDR chairs.
3. It's an IBGP mechanism not an EBGP mechanism, so the exposure to the 
stability of the Internet is reduced.
4. The BESS chairs ran a poll on the list to determine whether to progress as 
is in advance of implementations.

> Minor issues:
> -
> Actually these are mainly questions:

Questions are good.

> There are numerous references, starting in the Abstract, to the
> "Controller" but it isn't defined or described in any one place.
> I expected to find it in RFC8300, but no. So what is the Controller?

Right. This is a good catch. A "controller" is a centralised component 
responsible for determining SFPs and maybe more. It is akin to an SDN 
controller. We definitely need to add text for this.

It is not an 8300 concept. Indeed, 8300 is principally focused on the 
forwarding plane.
Furthermore, the control plane and orchestration aspects of SFC are a bit 
sketchy in 7665.
draft-ietf-sfc-control-plane might have been a good source of information, but 
the SFC WG appears to have given up on it.

So, yes, we need a short definition in 1.2, and a paragraph in 2.2.

> RFC8300 requires NSH+original_packet to be encapsulated in a Transport
> Encapsulation. In section 2.1 we find:
>
>>  Note that the presence of the NSH can make it difficult for nodes in
>>  the underlay network to locate the fields in the original packet that
>>  would normally be used to constrain equal cost multipath (ECMP)
>>  forwarding.  Therefore, it is recommended that the node prepending
>>  the NSH also provide some form of entropy indicator that can be used
>>  in the underlay network.  How this indicator is generated and
>>  supplied, and how an SFF generates a new entropy indicator when it
>>  forwards a packet to the next SFF are out of scope of this document.
>
> I would have expected that text to state that the entropy indicator is
> a property of the Transport Encapsulation required by RFC8300. (Isn't
> the Service Function Overlay Network in fact the embodiment of the
> Transport Encapsulation?) 

Well, yes and no.
The entropy indicator is carried in the transport encapsulation, and is used by 
the transport (underlay) network.
But it is a property of the payload. In particular, it is a property of what is 
encapsulated by the NSH.
The mechanism that encapsulates for the transport would normally have 
visibility into the payload to create the entropy indicator (hashing on 
specific fields), but the inclusion of the NSH makes that harder. Hence the 
recommendation that the entropy indicator is provided by the mechanism that 
prepends the NSH.

I think the text says this and that those skilled in the art (you have to 
understand the use of the entropy indicators and the inclusion of the NSH) will 
get this.

> In section 2.2 we find:
>
>>  When choosing the next SFI in a path, the SFF uses the SPI and SI as
>>  well as the SFT to choose among the SFIs, applying, for example, a
>>  load balancing algorithm or direct knowledge of the underlay network
>>  topology as described in Section 4.
>
> I'm probably missing something, but doesn't that risk a conflict with
> the statement above about the entropy indicator? How would this choice
> of path be guaranteed congruent with the choice of path by the underlay
> network? Or doesn't that matter?

No, this is a choice of SFIs, not a choice of paths between SFFs.
The former is determining the path in the overlay, the latter (using the 
entropy indicator) is selecting the path through the underlay.

>> 4.4.  Classifier Operation
>>
>>  As shown in Figure 1, the Classifier is a component that is used to
>>  assign packets to an SFP.
>>
>>  The Classifier is responsible for determining to which packet flow a
>>  packet belongs (usually by inspecting the packet header),...
>
> Would it be better to state explicitly that the method of classification
> is out of scope for this document? There is a whole world of complexity
> in that "(usually...)".

Yes, happy to say it is out of scope.

>> 4.5.  Service Function Forwarder Operation
>
> This section left me a bit puzzled. We've got the original packet,
> the classifier puts an NSH in front, we've got 

Re: [bess] IETF 106 presentation - please send request

[Adrian Farrel]

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-enhanced-vpn and builds on BGP VPNs and BGP-LS 
(using any forwarding plane including SR), hence we bring it to BESS.

 

Thanks,

Adrian

 

From: BESS  On Behalf Of Mankamana Mishra (mankamis)
Sent: 18 October 2019 23:25
To: bess@ietf.org
Subject: [bess] IETF 106 presentation - please send request

 

All, 

Preliminary agenda for IETF 106 is out. Please send me request to schedule 
presentation for IETF106.  Please provide name of speaker , time & draft. 

 

Mankamana 

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

[bess] New version of draft-ietf-bess-nsh-bgp-control-plane

[Adrian Farrel]

Hi again,

Finally got around to a very minor change resulting from Stephane's shepherd
review. Sorry for the delay.

The effect of the change is that attributes (that have not been correlated)
can't simply be timed out.

Best,
Adrian

-Original Message-
From: BESS  On Behalf Of internet-dra...@ietf.org
Sent: 20 August 2019 12:30
To: i-d-annou...@ietf.org
Cc: bess@ietf.org
Subject: [bess] I-D Action: draft-ietf-bess-nsh-bgp-control-plane-12.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
Authors : Adrian Farrel
  John Drake
  Eric Rosen
  Jim Uttaro
  Luay Jalil
Filename: draft-ietf-bess-nsh-bgp-control-plane-12.txt
Pages   : 59
Date: 2019-08-20

Abstract:
   This document describes the use of BGP as a control plane for
   networks that support Service Function Chaining (SFC).  The document
   introduces a new BGP address family called the SFC AFI/SAFI with two
   route types.  One route type is originated by a node to advertise
   that it hosts a particular instance of a specified service function.
   This route type also provides "instructions" on how to send a packet
   to the hosting node in a way that indicates that the service function
   has to be applied to the packet.  The other route type is used by a
   Controller to advertise the paths of "chains" of service functions,
   and to give a unique designator to each such path so that they can be
   used in conjunction with the Network Service Header defined in RFC
   8300.

   This document adopts the SFC architecture described in RFC 7665.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-nsh-bgp-control-plane/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bess-nsh-bgp-control-plane-12
https://datatracker.ietf.org/doc/html/draft-ietf-bess-nsh-bgp-control-plane-
12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-nsh-bgp-control-plane-12


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:
ftp://ftp.ietf.org/internet-drafts/

___
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

[bess] New version of draft-ietf-bess-datacenter-gateway

[Adrian Farrel]

Hi Bess,

This revision is mainly a keep-alive, but I did fix an (embarrassing) bug in
the name of the IANA registry.

Thanks,
Adrian

-Original Message-
From: BESS  On Behalf Of internet-dra...@ietf.org
Sent: 20 August 2019 12:09
To: i-d-annou...@ietf.org
Cc: bess@ietf.org
Subject: [bess] I-D Action: draft-ietf-bess-datacenter-gateway-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   : Gateway Auto-Discovery and Route Advertisement for
Segment Routing Enabled Domain Interconnection
Authors : Adrian Farrel
  John Drake
  Eric Rosen
  Keyur Patel
  Luay Jalil
Filename: draft-ietf-bess-datacenter-gateway-03.txt
Pages   : 12
Date: 2019-08-20

Abstract:
   Data centers are critical components of the infrastructure used by
   network operators to provide services to their customers.  Data
   centers are attached to the Internet or a backbone network by gateway
   routers.  One data center typically has more than one gateway for
   commercial, load balancing, and resiliency reasons.

   Segment Routing is a popular protocol mechanism for use within a data
   center, but also for steering traffic that flows between two data
   center sites.  In order that one data center site may load balance
   the traffic it sends to another data center site, it needs to know
   the complete set of gateway routers at the remote data center, the
   points of connection from those gateways to the backbone network, and
   the connectivity across the backbone network.

   Segment Routing may also be operated in other domains, such as access
   networks.  Those domains also need to be connected across backbone
   networks through gateways.

   This document defines a mechanism using the BGP Tunnel Encapsulation
   attribute to allow each gateway router to advertise the routes to the
   prefixes in the Segment Routing domains to which it provides access,
   and also to advertise on behalf of each other gateway to the same
   Segment Routing domain.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-datacenter-gateway/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bess-datacenter-gateway-03
https://datatracker.ietf.org/doc/html/draft-ietf-bess-datacenter-gateway-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-datacenter-gateway-03


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:
ftp://ftp.ietf.org/internet-drafts/

___
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] Poll to progress draft-ietf-bess-nsh-bgp-controlplane without implementation

[Adrian Farrel]

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 
review, and we would love to see it.

 

Thanks,

Adrian

 

From: BESS  On Behalf Of stephane.litkow...@orange.com
Sent: 03 June 2019 08:25
To: Susan Hares ; bess@ietf.org
Subject: Re: [bess] Poll to progress draft-ietf-bess-nsh-bgp-controlplane 
without implementation

 

Hi Sue,

 

Thanks.

This part is still under review and is not closed. If you have any particular 
comments, feel free to send the details. It would be great if you could also 
help the authors on the flowspec part of the draft if you think that it is not 
fully clear.

 

Brgds,

 

Stephane

 

 

From: Susan Hares [mailto:sha...@ndzh.com] 
Sent: Thursday, May 30, 2019 17:53
To: LITKOWSKI Stephane OBS/OINIS; bess@ietf.org
Subject: RE: [bess] Poll to progress draft-ietf-bess-nsh-bgp-controlplane 
without implementation

 

Stephane: 

 

[RFC5575bis author hat on] 

In progressing the draft without an implementation, please review carefully to 
the error handling text that Adrian just added. 

 

Sue 

 

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Tuesday, April 23, 2019 7:55 AM
To: bess@ietf.org
Subject: Re: [bess] Poll to progress draft-ietf-bess-nsh-bgp-controlplane 
without implementation

 

Hi,

 

We have a good amount of support to progress the document with implementations.

We (chairs) are now waiting for the next I-D update to move forward.

 

Brgds,

 

 

From: Jeff Tantsura [mailto:jefftant.i...@gmail.com] 
Sent: Friday, April 05, 2019 19:55
To: LITKOWSKI Stephane OBS/OINIS; Sami Boutros
Cc: bess@ietf.org
Subject: Re: [bess] Poll to progress draft-ietf-bess-nsh-bgp-controlplane 
without implementation

 

yes/support

 

Cheers, 

Jeff

On Apr 5, 2019, 10:53 AM -0700, Sami Boutros 
, wrote:

Support, Please progress the document.
 
Thanks,
 
Sami
 
Hi WG,
 
draft-ietf-bess-nsh-bgp-controlplane has passed WGLC and its finishing the 
shepherd's review phasis (I-D update required). It is in a good shape to 
progress further. However we are not aware of any implementation. As per our 
Implementation Requirement Policy, we need to poll the WG to know if WG agrees 
to progress the document without implementation.
 
This email starts a 2 weeks poll closing on 04/18/2019.
 
Please raise your support or any concern regarding the progress of this 
document without implementation.
If you are aware of any implementation, please also state it.
 
 
https://datatracker.ietf.org/doc/draft-ietf-bess-nsh-bgp-control-plane/
 
Brgds,
 
Stephane & Matthew

 

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

_
 
Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.
 
This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.
_
 
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 

Re: [bess] Shepherd's review of draft-ietf-bess-nsh-bgp-control-plane-06

[Adrian Farrel]

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 section 6 of RFC 4271, but we need to
>>> point to it.
>>>
>>> [SLI] You have added " Malformed SFP attributes, or those that in error in
>>> some way, MUST be handled as described in Section 6 of [RFC4271]"
>>> This is not enough ad RFC7606 allows for a more "graceful" process of 
>>> errors and it's up to each new attribute to have its own behavior in term
>>> of error processing. RFC7606 has some guidelines.
>>
>> This one will take a little more time to work up some text.
>> We'll get back to you.
>>
>> [SLI2] This is an important thing to address, and the IESG or Routing 
>> Directorate
>> may catch that as well.
>
> OK, a chunk more text. Does this work for you?
>
>   Section 6 of [RFC4271] describes the handling of malformed BGP
>   attributes, or those that are in error in some way.  [RFC7606]
>   revises BGP error handling specifically for the for UPDATE message,
>   provides guidelines for the authors of documents defining new
>   attributes, and revises the error handling procedures for a number of
>   existing attributes.  This document introduces the SFP attribute and
>   so defines error handling as follows:
>
>   o  When parsing a message, an unknown Attribute Type code or a length
>  that suggests that the attribute is longer than the remaining
>  message is treated as a malformed message and the "treat-as-
>  withdraw" approach used as per [RFC7606].
>
>   o  When parsing a message that contains an SFP attribute, the
>  following cases constitute errors:
>
>  1.  Optional bit is set to 0 in SFP attribute.
>
>  2.  Transitive bit is set to 0 in SFP attribute.
>
>  3.  Unknown TLV type field found in SFP attribute.
>
>  4.  TLV length that suggests the TLV extends beyond the end of the
>  SFP attribute.
>
>  5.  Association TLV contains an unknown SFPR-RD.
>
>[SLI] That's a bit weird to find this here as the Association TLV hasn't been 
>introduced.
> Wouldn't it be better to add a dedicated Error Handling section (e.g. 3.2.3) 
> after all the encodings ?

I think we introduced it in the text at the top of the page (i.e. a few 
paragraphs earlier). It reads OK to me and it is better to group together the 
format handling issues in one place and with the text that describes the 
presence rules.

>  6.  No Hop TLV found in the SFP attribute.
>
>  7.  No SFT TLV found in a Hop TLV.
>
> [SLI] That's strange, as section 3.2.1.3 says that the SFT TLV MAY be 
> included, so optional...

Ah, this should read "No sub-TLV found in a Hop TLV".
Per 3.2.1.2 "At least one sub-TLV MUST be present."

> 8.  Unknown SFIR-RD found in a Hop TLV.
>
>   o  The errors listed above are treated as follows:
>
>  1., 2., 6., 7.:  The attribute MUST be treated as malformed and
> the "treat-as-withdraw" approach used as per [RFC7606].
>
>  3.:  Unknown TLVs SHOULD be ignored, and message processing SHOULD
> continue.
>
>  4.:  Treated as a malformed message and the "treat-as-withdraw"
> approach used as per [RFC7606]
>
>  5., 8.:  The absence of an RD with which to corollate is nothing
> more than a soft error.  The receiver SHOULD store the
> information from the SFP attribute until a corresponding
> advertisement is received.  An implementation MAY time-out such
> stored SFP attributes to avoid becoming over-loaded.
>
> [SLI] That's not really an error, there may be a lot of transient situations
>  where some routes haven't been learned yet leading to such situation. 
> I don't think that we need to time-out (even optionally) as timing out may
> create inconsistencies in the controlplane. What you could suggest is 
> alarming to let the user know that something wrong is happening.

Timing this out is a housekeeping thing. Without it there can be a bleed of 
router resources. Might not be large, but over time (and with a bugged 
implementation somewhere else in the network) it could add up.

But:
1. We should give guidance on the time-out. A largish time-out of the order of 
30 minutes would be fine.
2. Yes, there should be a user notification when this happens.

So...

  5., 8.:  The absence of an RD with which to corollate is nothing
 more than a soft error.  The receiver SHOULD store the
 information from the SFP attribute until a corresponding
 advertisement is received.  An implementation MAY time-out such
 stored SFP attributes to avoid becoming over-loaded.  The time-out
 value should be configurable and measured in minutes; a default
 value of 30 minutes is suggested.  Whenever an implementation
 removes a stored SFP attribute, it 

Re: [bess] Shepherd's review of draft-ietf-bess-nsh-bgp-control-plane-06

[Adrian Farrel]

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...@ietf.org
Cc: bess@ietf.org
Subject: Re: [bess] Shepherd's review of 
draft-ietf-bess-nsh-bgp-control-plane-06

Hi Stephane,

I finally carved some time...

* NEXTHOP encoding:
>>> How is the nexthop encoded in the NLRI ?
>>
>> A bit confused about this question.
>
> [SLI] I'm talking about the nexthop field of the MP_REACH_NLRI attribute, 
> you must set a nexthop field even if it is not used for forwarding and you
> need to set how it is encoded.
>
> Ah, that!
> Yes, it's just a loopback address of the advertising SFF.
> Added a paragraph for that.
>[SLI2] Thanks for the new text, I'm just wondering if it is enough detailed or 
>not,
> especially as IPv4 or IPv6 NH could be involved.
> Looking at mvpn RFCs, they are using similar wording, so I suppose we could 
> let it this way.

OK, I'm leaving this without further changes.

* 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 section 6 of RFC 4271, but we need to
>> point to it.
>
> [SLI] You have added " Malformed SFP attributes, or those that in error in
> some way, MUST be handled as described in Section 6 of [RFC4271]"
> This is not enough ad RFC7606 allows for a more "graceful" process of 
> errors and it's up to each new attribute to have its own behavior in term
> of error processing. RFC7606 has some guidelines.
>
> This one will take a little more time to work up some text.
> We'll get back to you.
>
> [SLI2] This is an important thing to address, and the IESG or Routing 
> Directorate
> may catch that as well.

OK, a chunk more text. Does this work for you?

   Section 6 of [RFC4271] describes the handling of malformed BGP
   attributes, or those that are in error in some way.  [RFC7606]
   revises BGP error handling specifically for the for UPDATE message,
   provides guidelines for the authors of documents defining new
   attributes, and revises the error handling procedures for a number of
   existing attributes.  This document introduces the SFP attribute and
   so defines error handling as follows:

   o  When parsing a message, an unknown Attribute Type code or a length
  that suggests that the attribute is longer than the remaining
  message is treated as a malformed message and the "treat-as-
  withdraw" approach used as per [RFC7606].

   o  When parsing a message that contains an SFP attribute, the
  following cases constitute errors:

  1.  Optional bit is set to 0 in SFP attribute.

  2.  Transitive bit is set to 0 in SFP attribute.

  3.  Unknown TLV type field found in SFP attribute.

  4.  TLV length that suggests the TLV extends beyond the end of the
  SFP attribute.

  5.  Association TLV contains an unknown SFPR-RD.

  6.  No Hop TLV found in the SFP attribute.

  7.  No SFT TLV found in a Hop TLV.

  8.  Unknown SFIR-RD found in a Hop TLV.

   o  The errors listed above are treated as follows:

  1., 2., 6., 7.:  The attribute MUST be treated as malformed and
 the "treat-as-withdraw" approach used as per [RFC7606].

  3.:  Unknown TLVs SHOULD be ignored, and message processing SHOULD
 continue.

  4.:  Treated as a malformed message and the "treat-as-withdraw"
 approach used as per [RFC7606]

  5., 8.:  The absence of an RD with which to corollate is nothing
 more than a soft error.  The receiver SHOULD store the
 information from the SFP attribute until a corresponding
 advertisement is received.  An implementation MAY time-out such
 stored SFP attributes to avoid becoming over-loaded.


* FLOWSPEC traffic steering:
>>> NEW COMMENT:
>>> Section 5:
>>> "Note that each FlowSpec update MUST be tagged with the route target
>>>  of the overlay or VPN network for which it is intended."
>> [SLI] You should be more clear that VPN-IPv4 and VPN-IPv6 Flowspec
>> families must be used, it's not just a matter of RTs.
>
> A couple of the authors have discussed this a bit and we are puzzled.
>
> RFC 5575 section 8 discusses the applicability of Flowspecs to VPNs.
> https://www.iana.org/assignments/flow-spec/flow-spec.xhtml#flow-spec-2 
> does not list any VPN Flowspecs.
> draft-ietf-pce-pcep-flowspec makes observations about VPN identification
> and applicability to Flowspecs.
> draft-ietf-idr-flowspec-l2vpn has a redefinition of SAFI 

Re: [bess] Shepherd's review of draft-ietf-bess-nsh-bgp-control-plane-06

[Adrian Farrel]

3 must be used
>   and there is no RT attached. The trick here is that you need to set in the
>   action: - the SFC you want the traffic to be steered on as well as the VPN
>   to look the SFC for (Like a redirect RT + SFC steering). If there is no VPN
>   redirection, the SFC is considered to be available in the global routing 
> table.
> - traffic is coming from an L2VPN, this is similar to the L3VPN case.
> - same considerations applies to IPv6 and VPNv6.

OK, I think we need to separate two things.
Section 5 is concerned with how to select among possible next hops on an SFP. 
That is, the packet is already classified and assigned to an SFP, but some 
load-balancing choices have to be made. So I don't think Section 5 is the place 
for this discussion.
However, Section 7.4 is about classifying traffic onto SFPs. Specifically, it 
is about how to indicate, using BGP, which traffic flows should be assigned to 
which SPF at 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 else is needed for this issue.

Thanks,
Adrian


-Original Message-
From: Adrian Farrel [mailto:adr...@olddog.co.uk] 
Sent: Wednesday, March 06, 2019 16:06
To: LITKOWSKI Stephane OBS/OINIS; draft-ietf-bess-nsh-bgp-control-pl...@ietf.org
Cc: bess@ietf.org
Subject: RE: Shepherd's review of draft-ietf-bess-nsh-bgp-control-plane-06

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 the use of "portal" or "gateway". We 
were using "portal" and you asked us to change to "gateway". I initially 
thought that would be OK, but on reflection we think that "gateway" has 
specific connotations in networking where it means an interworking function 
between two different protocols and this is most definitely not what is 
intended. So, because "portal" is a synonym, we prefer to go back to using that.

   Thus the SFF can be seen as a portal in the underlay network through
   which a particular SFI is reached.

Cheers,
Adrian

> New comment:
>
> " When the SFF receives the packet and the NSH back from the SFI it
>   MUST select the next SFI"
>
> [SLI] Even if I agree that this is the intended behavior, it is not the
> purpose of this document to set the dataplane behavior of NSH. I
> think keeping the "MUST" as lower case is fine.

Ah yes.
I got carried away.

>>> The Figure 1 is not really used in this section as part of the existing
>>> text. I would be better to have a companion text that explains the
>>> figure.
>>
>> Wow! Yes. That's embarrassing.
>
> [SLI] The provided text is good. Just few comments:
>
> - the figure wraps on two pages, I missed the SFa in the figure as it is
>   located on the other page. It would be great if you could make it fit
>   on one page.

Hmmm, yes.
I will make the figure small enough to fit on one page, but I won't handle 
pagination at this stage: the RFC Editor will resolve that in the final 
formatting.

> - don't you need tunnels between SFF2 and SFF3 and between SFF1 
>   and SFF4 (full mesh). I agree that tunnel may be established on demand
>   if an SFC is using two SFFs, but here we don't have this information.

You *could* certainly have a those tunnels. But in practice there is unlikely 
to be a full mesh. This is a bit like a content distribution problem: a 
multi-layer network engineering solution is needed to place the SFs and decide 
which SFFs need to be connected with tunnels. Furthermore, if an SFC will never 
need to take SFs in a particular order, then tunnels wouldn't be needed.

> As the figure is already complex, adding tunnels may overload it. Maybe
> we could add a text telling that to simplify the figure only some tunnels
> between SFFs are represented.

Right, no need to complicate the figure.
I'll add...
  Note that, for convenience and clarity,  
shows only a few tunnels between
 SFFs.  There could be a full mesh of such tunnels, or more likely, a 
selection of tunnels connecting
 key SFFs to enable the construction of SFPs and to balance load and 
traffic in the network.

> - the example of SFC looks strange to me as SFd may be used twice
>   in the chain why not using " SFa, an SF of type SFTx, and SFe" ?

Bad text, well caught.
Text should read...

  Suppose an SFC needs to include SFa,
  an SF of type SFTx, and SFc.

> - There is a sentence telling th

Re: [bess] Shepherd's review of draft-ietf-bess-nsh-bgp-control-plane-06

[Adrian Farrel]

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 the use of "portal" or "gateway". We 
were using "portal" and you asked us to change to "gateway". I initially 
thought that would be OK, but on reflection we think that "gateway" has 
specific connotations in networking where it means an interworking function 
between two different protocols and this is most definitely not what is 
intended. So, because "portal" is a synonym, we prefer to go back to using that.

   Thus the SFF can be seen as a portal in the underlay network through
   which a particular SFI is reached.

Cheers,
Adrian

> New comment:
>
> " When the SFF receives the packet and the NSH back from the SFI it
>   MUST select the next SFI"
>
> [SLI] Even if I agree that this is the intended behavior, it is not the
> purpose of this document to set the dataplane behavior of NSH. I
> think keeping the "MUST" as lower case is fine.

Ah yes.
I got carried away.

>>> The Figure 1 is not really used in this section as part of the existing
>>> text. I would be better to have a companion text that explains the
>>> figure.
>>
>> Wow! Yes. That's embarrassing.
>
> [SLI] The provided text is good. Just few comments:
>
> - the figure wraps on two pages, I missed the SFa in the figure as it is
>   located on the other page. It would be great if you could make it fit
>   on one page.

Hmmm, yes.
I will make the figure small enough to fit on one page, but I won't handle 
pagination at this stage: the RFC Editor will resolve that in the final 
formatting.

> - don't you need tunnels between SFF2 and SFF3 and between SFF1 
>   and SFF4 (full mesh). I agree that tunnel may be established on demand
>   if an SFC is using two SFFs, but here we don't have this information.

You *could* certainly have a those tunnels. But in practice there is unlikely 
to be a full mesh. This is a bit like a content distribution problem: a 
multi-layer network engineering solution is needed to place the SFs and decide 
which SFFs need to be connected with tunnels. Furthermore, if an SFC will never 
need to take SFs in a particular order, then tunnels wouldn't be needed.

> As the figure is already complex, adding tunnels may overload it. Maybe
> we could add a text telling that to simplify the figure only some tunnels
> between SFFs are represented.

Right, no need to complicate the figure.
I'll add...
  Note that, for convenience and clarity,  
shows only a few tunnels between
 SFFs.  There could be a full mesh of such tunnels, or more likely, a 
selection of tunnels connecting
 key SFFs to enable the construction of SFPs and to balance load and 
traffic in the network.

> - the example of SFC looks strange to me as SFd may be used twice
>   in the chain why not using " SFa, an SF of type SFTx, and SFe" ?

Bad text, well caught.
Text should read...

  Suppose an SFC needs to include SFa,
  an SF of type SFTx, and SFc.

> - There is a sentence telling that the figure illustrates loadbalancing,
>   however I think that the sentence " A number of SFPs can be
>   constructed using any instance of SFb or using SFd." is not enough
>   to describe the loadbalancing. Who is doing the loadbalancing ?

OK. Now reads...

  This figure demonstrates how load balancing can be achieved by 
creating several SFPs that satisfy
 the same SFC.  Suppose an SFC needs to include SFa, an SF of type 
SFTx, and SFc.  A number of SFPs
 can be constructed using any instance of SFb or using SFd.  Load 
balancing may be applied at two
 places:
 
   The Classifier may distribute different flows onto different SFPs 
to share the load in the
  network and across SFIs.
   SFF-2 may distribute different flows (on the same SFP) to 
different instances of SFb to share
  the processing load.
 

>>> “The Service Function Type identifies a service function”. I don’t
>>> think we can really say that, it identifies the type of service the SF
>>> is providing but not the SF itself.
>>
>> Yes
>
> [SLI] The new text sounds strange.  Even if it is correct, it sounds as a 
> repetition:
> " The Service Function Type identifies a service function type".
> Could we use something like : "The Service Function Type identifies the
> functions/features of service function can offer".

OK

>>> How is the nexthop encoded in the NLRI ?
>>
>> A bit confused about this question.
>
> [SLI] I'm talking about the nexthop field of the MP_REACH_NLRI attribute, 
> you must set a nexthop field even if it is not used for forwarding and you
> need to set how it is encoded.

Ah, that!
Yes, it's just a loopback address of the advertising SFF.
Added a paragraph for that.

>>> I don’t see the “error 

Re: [bess] Shepherd's review of draft-ietf-bess-nsh-bgp-control-plane-06

[Adrian Farrel]

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.
> However it requires some refinements in the normative language used: some 
> statement
> should be normative but are not using upper case words.

Yes. I found 16 'must' to convert to 'MUST'. Some lowercase remains, but I 
believe they are correct.

> Abstract:
> - Please expand “BGP” on first use

'BGP' is well known according to 
https://www.rfc-editor.org/materials/abbrev.expansion.txt

> - Please give a reference associated to “Network Service Header”

OK. Obviously we cannot give a citation in the Abstract, but we can use plain 
text.

> Introduction:
> - When “classifier” is used as an example of SF, do you refer to the 
> classifier used to steer
>the traffic onto an SFC ? If yes, I don’t think it could be considered as 
> an SF.

Ah, no. Hmm. Tricky.
A SF could be responsible for classifying traffic into different buckets for 
different uses. This is a very similar function to an 'SFC Classifier' 
(responsible for classifying traffic onto different SFCs).
I can't think of a way to remove this confusion except by deleting this 
example. Instead, I have boosted the list of examples by borrowing from RFC 
7498.

> - I think the “conventional” approach described in the intro is really old 
> school and
>  even before SFC, we had some means, like dynamic routing protocols and other
>  mechanisms like separate routing tables, to steer the traffic through a set 
> of services.
>  I agree that there is also some drawback associated with such approaches 
> like the
>  operational complexity of provisioning.

OK. I *think* the change here is s/Conventionally/Historically/  and change the 
tense to past.

> Section 1.2:
> It would be good to give a definition for the additional terms that are
> defined in this document.

OK

> Section 2.1:
> 
> As the section is focused on dataplane, it would be good to rename it 
> as “Reminder on NSH dataplane” or something like that. It does not
> provide a functional overview of the controlplane which is what was
> expected based on the title.

Yeah, the CP is in 2.2.
We go for "Overview of Service Function Chaining"

> “A special Service Function, called a Classifier, is located at each
>   ingress point to a service function overlay network.  It assigns the
>   packets of a given packet flow to a specific Service Function Path.“
>
> Again, based on my understanding, the Classifier cannot really be
> considered as an SF , at least this is a component out of the SFC 
> which steers the traffic onto an SFC.

Well, rather than have a philosophical debate, I have changed 
OLD
A special Service Function, called a Classifier,
NEW
A special functional element, called a Classifier,
END

> “An unknown or invalid SPI SHALL be treated as an error and the SFF
>   MUST drop the packet.  Such errors SHOULD be logged, and such logs
>   MUST be subject to rate limits.”
>
> I found strange to have such statement in this document which is focused
> on the controlplane while this statement is a dataplane statement. Isn’t it
> part of RFC8300 Section 3 : 
> “3.  Update the NSH: SFs MUST decrement the service index by one.  If
>   an SFF receives a packet with an SPI and SI that do not
>   correspond to a valid next hop in a valid SFP, that packet MUST
>   be dropped by the SFF.”
>
> The next paragraph deals also with normative dataplane statement which 
> is IMO out of scope of this document.

You're right. There is no place for normative text in section 2.1.
Dropped to lower case, and added "as required by RFC 8300".

> Section 2.2
>
> “The SFIR describes a particular instance of a
>particular Service Function”. 
>
> Would it be good to talk about “Service Function Instance” rather than
> instance of a Service Function ? That’s understandable, of course, 
> however I think it’s good to reuse the exact terminology. 

It just reads better 

Moving to...

“The SFIR describes a particular instance of a particular Service Function 
(i.e., an SFI)..."

> • I think the SFT definition is appearing a bit late in this section and in 
> the document 
>  as it has been referenced already multiple times before.

This is now in 1.2.
The only previous mention of SFT is in the bullet list for the SFPR definition 
two paragraphs higher.
But I have jiggled 2.2 to bring SFT to the top.

> “Service Function Type (SFT) that
   is the category of SF that is supported by an SFF”. 
>
> Don’t you mean SFI rather than SFF ?

Nope.
SFFs support attached SFIs.
An SFI is an instance of an SF.
An SF has a type that is its SFT.

> “Thus the SFF can be seen as a portal…”. Would “gateway” 
> be more suitable rather than “portal” ?

Oh, have I been writing too many fairy stories?

It's pretty much synonymous, 

Re: [bess] I-D Action: draft-ietf-bess-datacenter-gateway-02.txt

[Adrian Farrel]

Hi,

We let this draft expire, which is bad of us because it is a WG draft.

I have woken it up, cleaned some nits, updated the references, fixed some
author coordinates, and added a little Manageability text.

The authors think this is pretty complete. We're wondering whether to apply
for the FCFS codepoint now or let it run.

Thanks,
Adrian

-Original Message-
From: I-D-Announce  On Behalf Of
internet-dra...@ietf.org
Sent: 26 February 2019 19:01
To: i-d-annou...@ietf.org
Cc: bess@ietf.org
Subject: I-D Action: draft-ietf-bess-datacenter-gateway-02.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   : Gateway Auto-Discovery and Route Advertisement for
Segment Routing Enabled Domain Interconnection
Authors : Adrian Farrel
  John Drake
  Eric Rosen
  Keyur Patel
  Luay Jalil
Filename: draft-ietf-bess-datacenter-gateway-02.txt
Pages   : 12
Date: 2019-02-26

Abstract:
   Data centers are critical components of the infrastructure used by
   network operators to provide services to their customers.  Data
   centers are attached to the Internet or a backbone network by gateway
   routers.  One data center typically has more than one gateway for
   commercial, load balancing, and resiliency reasons.

   Segment Routing is a popular protocol mechanism for use within a data
   center, but also for steering traffic that flows between two data
   center sites.  In order that one data center site may load balance
   the traffic it sends to another data center site, it needs to know
   the complete set of gateway routers at the remote data center, the
   points of connection from those gateways to the backbone network, and
   the connectivity across the backbone network.

   Segment Routing may also be operated in other domains, such as access
   networks.  Those domains also need to be connected across backbone
   networks through gateways.

   This document defines a mechanism using the BGP Tunnel Encapsulation
   attribute to allow each gateway router to advertise the routes to the
   prefixes in the Segment Routing domains to which it provides access,
   and also to advertise on behalf of each other gateway to the same
   Segment Routing domain.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-datacenter-gateway/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bess-datacenter-gateway-02
https://datatracker.ietf.org/doc/html/draft-ietf-bess-datacenter-gateway-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-datacenter-gateway-02


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:
ftp://ftp.ietf.org/internet-drafts/

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

Re: [bess] I-D Action: draft-ietf-bess-nsh-bgp-control-plane-07.txt

[Adrian Farrel]

Fixed up Eric's email address.

Adrian

-Original Message-
From: BESS  On Behalf Of internet-dra...@ietf.org
Sent: 26 February 2019 18:38
To: i-d-annou...@ietf.org
Cc: bess@ietf.org
Subject: [bess] I-D Action: draft-ietf-bess-nsh-bgp-control-plane-07.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
Authors : Adrian Farrel
  John Drake
  Eric Rosen
  Jim Uttaro
  Luay Jalil
Filename: draft-ietf-bess-nsh-bgp-control-plane-07.txt
Pages   : 55
Date: 2019-02-26

Abstract:
   This document describes the use of BGP as a control plane for
   networks that support Service Function Chaining (SFC).  The document
   introduces a new BGP address family called the SFC AFI/SAFI with two
   route types.  One route type is originated by a node to advertise
   that it hosts a particular instance of a specified service function.
   This route type also provides "instructions" on how to send a packet
   to the hosting node in a way that indicates that the service function
   has to be applied to the packet.  The other route type is used by a
   Controller to advertise the paths of "chains" of service functions,
   and to give a unique designator to each such path so that they can be
   used in conjunction with the Network Service Header.

   This document adopts the SFC architecture described in RFC 7665.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-nsh-bgp-control-plane/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bess-nsh-bgp-control-plane-07
https://datatracker.ietf.org/doc/html/draft-ietf-bess-nsh-bgp-control-plane-
07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-nsh-bgp-control-plane-07


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:
ftp://ftp.ietf.org/internet-drafts/

___
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] I-D Action: draft-ietf-bess-nsh-bgp-control-plane-06.txt

[Adrian Farrel]

Thanks Stephane,

I understand.

It may be hard to track down Eric: I understand he has retired.

I will ask Ron Bonica if he can reach him, but otherwise I would note:
- We an move him to the Contributors section to avoid Auth-48 issues
- As an author on the document he has already confirmed that he has
  complied with BCP 78 and 79
- There is Juniper IPR already disclosed
- John Drake has given you IPR assurances and, as a Juniper employee,
  It is likely that he has done the same IPR search that Eric would have
  done.

Let's see whether we can wake up Jim, Stuart, Keyur, and Avinash.

Thanks,
Adrian

-Original Message-
From: stephane.litkow...@orange.com  
Sent: 26 February 2019 08:37
To: adr...@olddog.co.uk; bess@ietf.org
Subject: RE: [bess] I-D Action: draft-ietf-bess-nsh-bgp-control-plane-06.txt

Hi Adrian,

Yes it is ready, we will proceed with the shepherd's review. However, we
don't have any sign of implementation or roadmap yet, we (chairs) will have
to ask the WG to determine a consensus to progress the document without an
implementation (as per our implementation policy).

In addition, I missing the IPR poll reply from: Jim, Eric, Stuart, 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 during WG last call.

John and I have also re-reviewed the entire text.

We made a small number of little changes resulting from these activities.

Chairs: I think we are ready to move forward.

Best,
Adrian

-Original Message-
From: I-D-Announce  On Behalf Of
internet-dra...@ietf.org
Sent: 25 February 2019 17:20
To: i-d-annou...@ietf.org
Cc: bess@ietf.org
Subject: I-D Action: draft-ietf-bess-nsh-bgp-control-plane-06.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
Authors : Adrian Farrel
  John Drake
  Eric Rosen
  Jim Uttaro
  Luay Jalil
Filename: draft-ietf-bess-nsh-bgp-control-plane-06.txt
Pages   : 55
Date: 2019-02-25

Abstract:
   This document describes the use of BGP as a control plane for
   networks that support Service Function Chaining (SFC).  The document
   introduces a new BGP address family called the SFC AFI/SAFI with two
   route types.  One route type is originated by a node to advertise
   that it hosts a particular instance of a specified service function.
   This route type also provides "instructions" on how to send a packet
   to the hosting node in a way that indicates that the service function
   has to be applied to the packet.  The other route type is used by a
   Controller to advertise the paths of "chains" of service functions,
   and to give a unique designator to each such path so that they can be
   used in conjunction with the Network Service Header.

   This document adopts the SFC architecture described in RFC 7665.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-nsh-bgp-control-plane/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bess-nsh-bgp-control-plane-06
https://datatracker.ietf.org/doc/html/draft-ietf-bess-nsh-bgp-control-plane-
06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-nsh-bgp-control-plane-06


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:
ftp://ftp.ietf.org/internet-drafts/

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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


_

Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.

This message and its attachments may 

Re: [bess] I-D Action: draft-ietf-bess-nsh-bgp-control-plane-06.txt

[Adrian Farrel]

All,

Thanks for the comments we received during WG last call.

John and I have also re-reviewed the entire text.

We made a small number of little changes resulting from these activities.

Chairs: I think we are ready to move forward.

Best,
Adrian

-Original Message-
From: I-D-Announce  On Behalf Of
internet-dra...@ietf.org
Sent: 25 February 2019 17:20
To: i-d-annou...@ietf.org
Cc: bess@ietf.org
Subject: I-D Action: draft-ietf-bess-nsh-bgp-control-plane-06.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
Authors : Adrian Farrel
  John Drake
  Eric Rosen
  Jim Uttaro
  Luay Jalil
Filename: draft-ietf-bess-nsh-bgp-control-plane-06.txt
Pages   : 55
Date: 2019-02-25

Abstract:
   This document describes the use of BGP as a control plane for
   networks that support Service Function Chaining (SFC).  The document
   introduces a new BGP address family called the SFC AFI/SAFI with two
   route types.  One route type is originated by a node to advertise
   that it hosts a particular instance of a specified service function.
   This route type also provides "instructions" on how to send a packet
   to the hosting node in a way that indicates that the service function
   has to be applied to the packet.  The other route type is used by a
   Controller to advertise the paths of "chains" of service functions,
   and to give a unique designator to each such path so that they can be
   used in conjunction with the Network Service Header.

   This document adopts the SFC architecture described in RFC 7665.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-nsh-bgp-control-plane/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bess-nsh-bgp-control-plane-06
https://datatracker.ietf.org/doc/html/draft-ietf-bess-nsh-bgp-control-plane-
06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-nsh-bgp-control-plane-06


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:
ftp://ftp.ietf.org/internet-drafts/

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

___
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

[Adrian Farrel]

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 poll for
draft-ietf-bess-nsh-bgp-control-plane

 

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

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

[Adrian Farrel]

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. Thus if we support NSH (we do, and we describe it), and 
if we support identifying the interface “tunnel type” (we do because this is a 
standard extension for BGP and we talk about it in the draft), I think we have 
that document covered.

 

I haven’t read draft-guichard-spring-nsh-s (yet), but it might be a bit 
premature to include an applicability discussion of that work before it is 
adopted by SPRING.

 

BUT, I certainly have no objection to someone (you?) starting one or more 
applicability documents.

 

Ciao,

Adrian

 

Oh! John just sent almost the same email!

 

From: BESS  On Behalf Of Henderickx, Wim (Nokia - 
BE/Antwerp)
Sent: 22 January 2019 17:00
To: stephane.litkow...@orange.com; bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: Re: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-nsh-bgp-control-plane

 


I need to get into more details, but the current draft is written with 
draft-ietf-mpls-sfc-04 dataplane in mind. I believe that the draft can be 
useful with other dataplanes like: draft-ietf-mpls-sfc-encapsulation and 
draft-guichard-spring-nsh-s


So I would like the see the BGP control plane extensions here to become more 
generic to support multiple data-planes options. I need to go in more detail, 
but from high level this is my feedback here. I don’t want to stop/block this 
work as I believe this is a very useful proposal, but if we make it more 
generic it can serve a bigger purpose.

 

So I would like to see the following:

1.  Protocol draft
2.  Use case drafts for the different data planes.

 

My 2 cents.

 

From: BESS mailto:bess-boun...@ietf.org> > on behalf of 
Stephane Litkowski mailto:stephane.litkow...@orange.com> >
Date: Monday, 21 January 2019 at 08:06
To: "bess@ietf.org  " mailto:bess@ietf.org> >
Cc: "bess-cha...@ietf.org  " mailto:bess-cha...@ietf.org> >
Subject: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-nsh-bgp-control-plane

 

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

Re: [bess] short WGLC for draft-ietf-bess-service-chaining

[Adrian Farrel]

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
for SFC.

 

I am not convinced that this solution is scalable to complex chains or large
networks with very many chains, but that is not the point. We have other
solutions (as Andy notes) for those problems. Those other solutions may also
be more generic and widely applicable, ultimately covering the problem space
addressed by this draft, but that is not the point either.

 

Furthermore, as this solution is already shipping (if I understand various
claims correctly), it is worthwhile publishing.

 

The current version seems "good enough".

 

Thanks,

Adrian

 

From: BESS  On Behalf Of
stephane.litkow...@orange.com
Sent: 11 January 2019 08:37
To: bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: [bess] short WGLC for draft-ietf-bess-service-chaining

 

Hi,

 

The draft-ietf-bess-service-chaining [1] document failed its WGLC with
substantial comments received.

The document has been updated beginning of December and we would like to
know if people are now happy with the content of the new version.

 

This email starts a poll of 1 week to gather additional comments or
support/agreement.

This work is an old one and we should close it asap.

 

The poll runs until *** Friday 18th January 

 

Brgds,

 

 

[1] https://datatracker.ietf.org/doc/draft-ietf-bess-service-chaining/

 

 

 

  

 

Stephane Litkowski 
Network Architect 
Orange/SCE/EQUANT/OINIS/NET

Orange Expert Future Networks

phone:
 +33 2 23 06 49 83
NEW !
mobile:
 +33 6 71 63 27 50
NEW !
  stephane.litkow...@orange.com 

 


_
 
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-nsh-bgp-control-plane-05.txt

[Adrian Farrel]

Hello all and Happy New Year,

This version replaces the expired draft, fixes a few nits, adds a few
clarifications, and backs out a couple of small and unnecessary changes
introduced in -04.

The authors think that this version is ready for the chairs to review and
start working group last call.

Thanks,
Adrian

-Original Message-
From: BESS  On Behalf Of internet-dra...@ietf.org
Sent: 12 January 2019 14:30
To: i-d-annou...@ietf.org
Cc: bess@ietf.org
Subject: [bess] I-D Action: draft-ietf-bess-nsh-bgp-control-plane-05.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
Authors : Adrian Farrel
  John Drake
  Eric Rosen
  Jim Uttaro
  Luay Jalil
Filename: draft-ietf-bess-nsh-bgp-control-plane-05.txt
Pages   : 54
Date: 2019-01-12

Abstract:
   This document describes the use of BGP as a control plane for
   networks that support Service Function Chaining (SFC).  The document
   introduces a new BGP address family called the SFC AFI/SAFI with two
   route types.  One route type is originated by a node to advertise
   that it hosts a particular instance of a specified service function.
   This route type also provides "instructions" on how to send a packet
   to the hosting node in a way that indicates that the service function
   has to be applied to the packet.  The other route type is used by a
   Controller to advertise the paths of "chains" of service functions,
   and to give a unique designator to each such path so that they can be
   used in conjunction with the Network Service Header.

   This document adopts the SFC architecture described in RFC 7665.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-nsh-bgp-control-plane/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bess-nsh-bgp-control-plane-05
https://datatracker.ietf.org/doc/html/draft-ietf-bess-nsh-bgp-control-plane-
05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-nsh-bgp-control-plane-05


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:
ftp://ftp.ietf.org/internet-drafts/

___
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-evpn-df-election-framework-06

[Adrian Farrel]

We're good. Thanks!

Consult with your AD, but for the "updates" question, a way forward would be to 
make an explicit statement (in the Introduction) to the contrary.

Best,
Adrian
--
Fairy tales from North Wales brought to you for Christmas
https://www.feedaread.com/profiles/8604/
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-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 Jorge and Adrian. 

Inline [Satya].

Thanks,
--Satya

On 12/14/18, 2:40 AM, "Rabadan, Jorge (Nokia - US/Mountain View)" 
 wrote:

Hi Adrian,

Thank you very much for your thorough review.
I incorporated most of your comments, please see the details in-line with 
[JORGE].

There is one outstanding comment that Satya and I will discuss.

Thank you.
Jorge

-Original Message-
From: "Satya Mohanty (satyamoh)" 
Date: Friday, December 7, 2018 at 9:11 PM
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
Resent-From: 
Resent-To: , , 
, , , 
, , 
, , 
, , , 
Stephane Litkowski 
Resent-Date: Friday, December 7, 2018 at 9:11 PM

Hi Adrian,

Thank you very much for your detailed review and comments.
We will take care of all the nits that you have pointed out and include 
the reference to the IEEE/ACM TON paper (the link you have pointed out is 
indeed correct).

However, I had one query. Most of the time research journal/conference 
papers will be behind a paywall and there may not be a free cached copy 
available online.
How do we get across this problem?

    Best,
--Satya

On 12/7/18, 7:20 AM, "Adrian Farrel"  wrote:

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 purpose of the review is to provide assistance to the 
Routing ADs.
For more information about the Routing Directorate, please see
?http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although 
these comments
are primarily for the use of the Routing ADs, it would be helpful 
if you could
consider them along with any other IETF Last Call comments that you 
receive,
and strive to resolve them through discussion or by updating the 
draft.

Document: draft-ietf-bess-evpn-df-election-framework-06.txt
Reviewer: Adrian Farrel
Review Date: 2018-12-07
IETF LC End Date: 2018-12-18
Intended Status: Standards Track

Summary:

This document is basically ready for publication, but has nits that 
should be
considered prior to publication.

Comments:

This document addresses issues in the default election algorithm 
used for
Designated Forwarder Election in EVPN (RFC 7432 and RFC 8124) by 
defining a new
election algorithm and a capability to influence the election 
result for a
VLAN, depending on the state of the associated Attachment Circuit.

This is an exceptionally clear and well written document. The 
authors and the
working group are to be congratulated.

During my review I observed a number of small issues and editorial 
nits. I
don't believe any of these is cause for discussion in the working 
group, but it
would be sensible to resolve them before publication.

Thanks and Happy Christmas,
Adrian
--
It's Christmas.
Buy someone you love a book of fairy tales.
https://www.feedaread.com/profiles/8604/
Available from your favourite online bookseller.
Or contact me to receive a signed copy by mail.

===

Major Issues:
 No major issues found

===

Minor Issues:

HRW1999 is

[bess] Referencing material behind a paywall

[Adrian Farrel]

Hi,

[Changed the subject line, tried to reduce the recipients (but it's still a bit 
much), added the RSE in case she has advice]

It's tricky. Sometimes we need to reference material that is behind a paywall 
or simply in a paper journal. Sometimes we need to reference something from a 
published book.

Most often such references are Informative, and that's usually considered OK so 
long as there is a stable reference to the material (such as a URL, or an ISBN, 
or a DOI). 

For Normative references the issue is more complex because the implication is 
that the reference must be read in order to understand and implement the RFC. 
That, of course, is a problem for an open access organisation like the IETF 
(you could look at https://open-stand.org/ for an overview of the principles 
that underlie this).

In general (and I think your draft is an example of this) it is possible to 
describe/rewrite the pieces of normative text without infringing copyright. 
That usually reduces the reference to Informative and provides enough 
information in the RFC for implementation. Your draft is an example of this 
because you have described the algorithms in your text with enough detail to 
allow an implementation: the reference is really only there to provide context 
and proof of the algorithms. (And anyway, having found a freely accessible copy 
of the reference in your draft, we are probably home and dry.)

Cheers,
Adrian

-Original Message-
From: Satya Mohanty (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 for your detailed review and comments.
We will take care of all the nits that you have pointed out and include the 
reference to the IEEE/ACM TON paper (the link you have pointed out is indeed 
correct).

However, I had one query. Most of the time research journal/conference papers 
will be behind a paywall and there may not be a free cached copy available 
online.
How do we get across this problem?

Best,
--Satya

On 12/7/18, 7:20 AM, "Adrian Farrel"  wrote:

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 purpose of the review is to provide assistance to the Routing 
ADs.
For more information about the Routing Directorate, please see
?http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these 
comments
are primarily for the use of the Routing ADs, it would be helpful if you 
could
consider them along with any other IETF Last Call comments that you receive,
and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-bess-evpn-df-election-framework-06.txt
Reviewer: Adrian Farrel
Review Date: 2018-12-07
IETF LC End Date: 2018-12-18
Intended Status: Standards Track

Summary:

This document is basically ready for publication, but has nits that should 
be
considered prior to publication.

Comments:

This document addresses issues in the default election algorithm used for
Designated Forwarder Election in EVPN (RFC 7432 and RFC 8124) by defining a 
new
election algorithm and a capability to influence the election result for a
VLAN, depending on the state of the associated Attachment Circuit.

This is an exceptionally clear and well written document. The authors and 
the
working group are to be congratulated.

During my review I observed a number of small issues and editorial nits. I
don't believe any of these is cause for discussion in the working group, 
but it
would be sensible to resolve them before publication.

Thanks and Happy Christmas,
Adrian
--
It's Christmas.
Buy someone you love a book of fairy tales.
https://www.feedaread.com/profiles/8604/
Available from your favourite online bookseller.
Or contact me to receive a signed copy by mail.

===

Major Issues:
 No major issues found

===

Minor Issues:

HRW1999 is provided as a normative reference, and from the text I can
see why. But no URL (stable or otherwise) is given for the reference.
Using my favorite search engine, I looked for and found a copy of
the referenced document on the IEEE site behind a paywall. I don't
think that will do at all. However, there is a version at

https://www.microsoft.com/en-us/research/wp-content/uploads/2017/02/HRW98.pdf
That appears to be dated 1998, but otherwise could be the same paper.

---

When I read in

[bess] Rtgdir last call review of draft-ietf-bess-evpn-df-election-framework-06

[Adrian Farrel]

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 purpose of the review is to provide assistance to the Routing ADs.
For more information about the Routing Directorate, please see
?http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments
are primarily for the use of the Routing ADs, it would be helpful if you could
consider them along with any other IETF Last Call comments that you receive,
and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-bess-evpn-df-election-framework-06.txt
Reviewer: Adrian Farrel
Review Date: 2018-12-07
IETF LC End Date: 2018-12-18
Intended Status: Standards Track

Summary:

This document is basically ready for publication, but has nits that should be
considered prior to publication.

Comments:

This document addresses issues in the default election algorithm used for
Designated Forwarder Election in EVPN (RFC 7432 and RFC 8124) by defining a new
election algorithm and a capability to influence the election result for a
VLAN, depending on the state of the associated Attachment Circuit.

This is an exceptionally clear and well written document. The authors and the
working group are to be congratulated.

During my review I observed a number of small issues and editorial nits. I
don't believe any of these is cause for discussion in the working group, but it
would be sensible to resolve them before publication.

Thanks and Happy Christmas,
Adrian
--
It's Christmas.
Buy someone you love a book of fairy tales.
https://www.feedaread.com/profiles/8604/
Available from your favourite online bookseller.
Or contact me to receive a signed copy by mail.

===

Major Issues:
 No major issues found

===

Minor Issues:

HRW1999 is provided as a normative reference, and from the text I can
see why. But no URL (stable or otherwise) is given for the reference.
Using my favorite search engine, I looked for and found a copy of
the referenced document on the IEEE site behind a paywall. I don't
think that will do at all. However, there is a version at
https://www.microsoft.com/en-us/research/wp-content/uploads/2017/02/HRW98.pdf
That appears to be dated 1998, but otherwise could be the same paper.

---

When I read in Section 3...

   In addition, since the specification in EVPN
   [RFC7432] does leave several questions open as to the precise final
   state machine behavior of the DF election, section 3.1 describes
   precisely the intended behavior.

 I wondered whether this document is updating 7432 in that respect.

Other features later in the document (such as section 5) confirm this.

---

Notwithstanding the mention of backward compatiblity in section 6, I
think it would be a good idea to include a very short section 3.2.1.

3.2.1.  Backward Compatibility

   Legacy implementations (i.e., those that predate this specification)
   will not advertise the DF Election Extended Community.  That means
   that all other participating PEs will not receive DF preferences and
   will revert to the defailt algorithm without AC-Influenced DF
   Election.

   Similarly, a legacy implementation receiving a DF Election Extended
   Community will ignore it and will continue to use the default
   algorithm.

---

On first reading, I missed an important subtlty in 3.2. The paragraph...

 - Otherwise if even a single advertisement for the type-4 route is
   not received with the locally configured DF Alg and capability,
   the default DF Election algorithm (modulus) algorithm MUST be
   used as in [RFC7432].

is really important because it handles what to do if different
participating PEs disagree about which algorithm to use.  Your text is
perfectly fine and adequate, but the "locally configured" sort of hid
it from me first time around.

Maybe add a sentence to the end of the bullet point to say...

"This procedure handles the case where participating PEs disagree about
the DF algorithm and capability to apply."

---

Section 4 introduces 8124 for the first time. It's good that this is
applicable to private wire EVPN as well as 7432 EVPN. Maybe bring this
into focus in the Introducion?

It does make me wonder whether you are also updating 8124.

---

I think section 7 is good. Since you note that the "unfair" situation
may be created maliciously, should you note that there is also scope for
a downgrade attach where the advertisement from one PE is hidden, the
preferred algorithm is modified to any unexpected value, or any
unexpected bit in the capabilities bitfield is set? I think such an
attack assumes either a subversion of the PE (perhaps via its
configuration) or modification of the BGP message. Thus, it is not a
probable if adequate existing security m

Re: [bess] Some comments on draft-ietf-bess-nsh-bgp-control-plane-03

[Adrian Farrel]

Ah, got it. Sorry for being dim.
 
In fact, there are four load balancing scenarios:
- Classifier balances across SFPs
- SFF balances across locally-attached SFIs
- SFF balances across downstream SFFs to reach downstream SFIs
- SFF balances across locally-attached SFIs *and* downstream SFFs to reach
downstream SFIs
 
This last case is the one you are adding to the discussion, and it is valid.
 
We've missed the cut-off for updating a new version before IETF-102, but I've
added it to my work list for this draft.
 
Thanks,
Adrian
 
From: Jiangyuanlong [mailto:jiangyuanl...@huawei.com] 
Sent: 02 July 2018 07:27
To: adr...@olddog.co.uk; bess@ietf.org
Subject: RE: Some comments on draft-ietf-bess-nsh-bgp-control-plane-03
 
Dear Adrian,
 
Thank you for your prompt reply.
I totally agree with you that "load balancing in SFC is something that has to be
done carefully to avoid packet ordering issues and protect stateful SF
processing.
That basically means that load balancing decisions need to be made with SFP and
flow awareness."
How to do load balancing with SFPs is more clearly described in your document,
but how to enable flow awareness for load balancing is less obvious.
 
I think the examples in 8.9.3 and 8.9.4 only show load balancing on parallel
SFFs, not on serial SFFs as in the following example:
 
 --
| SFIb |
|SFT=42|
 --
  --  --   |
 | SFI  || SFIa |  -
 |SFT=41||SFT=42| |   SFF5  |
  --  --..|192.0.2.5|..
   \/ ..:  -  :..
  - .: :.-
   --|   SFF1  |--/  - |   SFF3  |
   -->|Class-|...|192.0.2.1||   SFF6  ||192.0.2.3|-->
   -->| ifier|- |192.0.2.6|:-
   --  -  |
   |--
 --| SFI  |
| SFIc |   |SFT=43|
|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 Farrel [mailto:adr...@olddog.co.uk] 
Sent: Sunday, July 01, 2018 4:19 PM
To: Jiangyuanlong ; bess@ietf.org
Subject: RE: Some comments on draft-ietf-bess-nsh-bgp-control-plane-03
 
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.1, it firstly says:" The SFI Pool Identifier is encoded as
an 8 octet
>  value as shown in Figure 4."  However, it then says in the end of this
subsection:
> "The SFI Pool Identifier is a six octet, globally unique value encoded in
network
>  byte order." These two sentences are confusing.
 
Yes. Confusion.
 
The 8 is supposed to refer to the whole extended community, while the 6 refers
to the SPI Pool Identifier field.
 
I will clean this up.
 
> The 1st occurrence of SFI Pool Identifier shall be fully spelled out as "SFI
Pool
> Identifier extended community". Furthermore, "SPI Pool Identifier" in Figure 4
> seems to be "SFI Pool Identifier" as there is no definition for the former
term in
> the document. There are "SPI Pool Identifier" in other sections need to be
> consistent as well, such as "SPI Pool Identifier" in the last paragraph of
Section
> 3.2.1.3. 
 
Oh, thanks!
 
>  2. The definitions of "Service Function Type" in Figure 3 and Figure 9 are 
>   different and ambiguous. Maybe it can be simply defined as "The
identifier
>   for a type of service function". 
 
Hmmm, yes the text in 3.1 and 3.2.1.3 is all mixed up! We can't tell the
difference between an RD and a pool identifier!
 
> 3. "SFIR-RD List" in Figure 9 may be replaced with "SFIR-RD/SFI pool ID list",
as
> SFI pool ID is different from SFIR-RD and the list may consist of pure SFI
pool
> IDs.
 
Yes, again. As noted, 3.2.1.3 is all mixed up. 
 
> One further note is, upon processing this variable, we need to distinguish
> RD Type and SFI Pool Identifier Type, the IANA will need to take care not to
allocate 0x80XX for SFIR-RD Type

[bess] Changes to draft-ietf-bess-nsh-bgp-control-plane-04.txt

[Adrian Farrel]

Hi,

The changes can be seen in the diff and are mainly to address Yuanlong's
comments.

- 3.1.1 clarify text
- 3.2.1.2 clarify text and note two possible sub-TLVs of the Hop TLV
- 3.2.1.3 and 3.2.1.4 split into two sub-TLVs and explain their use
- 10.3 fix up IANA section per 3.2.1.3/4
- 12 add Yuanlong
- 13.2 update references
- Typos

Cheers,
Adrian

> -Original Message-
> From: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] On Behalf Of
> internet-dra...@ietf.org
> Sent: 01 July 2018 09:30
> To: i-d-annou...@ietf.org
> Cc: bess@ietf.org
> Subject: I-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 SFC
> Authors : Adrian Farrel
>   John Drake
>   Eric Rosen
>   Jim Uttaro
>   Luay Jalil
>   Filename: draft-ietf-bess-nsh-bgp-control-plane-04.txt
>   Pages   : 55
>   Date: 2018-07-01
> 
> Abstract:
>This document describes the use of BGP as a control plane for
>networks that support Service Function Chaining (SFC).  The document
>introduces a new BGP address family called the SFC AFI/SAFI with two
>route types.  One route type is originated by a node to advertise
>that it hosts a particular instance of a specified service function.
>This route type also provides "instructions" on how to send a packet
>to the hosting node in a way that indicates that the service function
>has to be applied to the packet.  The other route type is used by a
>Controller to advertise the paths of "chains" of service functions,
>and to give a unique designator to each such path so that they can be
>used in conjunction with the Network Service Header.
> 
>This document adopts the SFC architecture described in RFC 7665.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-bess-nsh-bgp-control-plane/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-bess-nsh-bgp-control-plane-04
> https://datatracker.ietf.org/doc/html/draft-ietf-bess-nsh-bgp-control-plane-04
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-nsh-bgp-control-plane-04
> 
> 
> 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:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

Re: [bess] draft-ietf-bess-nsh-bgp-control-plane

[Adrian Farrel]

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) we might want to get
a little more stability and (of course) clarify the relationship with
draft-ietf-mpls-sfc.

It would also be worth checking whether the mechanisms included in sections
3.2.1.5 and 3.2.1.6 already do the job, whether 7.6 helps explain, and whether
the (already defined) Tunnel Encapsulation attribute can help.

Shall we spend some face time in Montreal clarifying what needs to be added?

Cheers,
Adrian

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

Re: [bess] Some comments on draft-ietf-bess-nsh-bgp-control-plane-03

[Adrian Farrel]

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.1, it firstly says:" The SFI Pool Identifier is encoded as
an 8 octet
>  value as shown in Figure 4."  However, it then says in the end of this
subsection:
> "The SFI Pool Identifier is a six octet, globally unique value encoded in
network
>  byte order." These two sentences are confusing.
 
Yes. Confusion.
 
The 8 is supposed to refer to the whole extended community, while the 6 refers
to the SPI Pool Identifier field.
 
I will clean this up.
 
> The 1st occurrence of SFI Pool Identifier shall be fully spelled out as "SFI
Pool
> Identifier extended community". Furthermore, "SPI Pool Identifier" in Figure 4
> seems to be "SFI Pool Identifier" as there is no definition for the former
term in
> the document. There are "SPI Pool Identifier" in other sections need to be
> consistent as well, such as "SPI Pool Identifier" in the last paragraph of
Section
> 3.2.1.3. 
 
Oh, thanks!
 
>  2. The definitions of "Service Function Type" in Figure 3 and Figure 9 are 
>   different and ambiguous. Maybe it can be simply defined as "The
identifier
>   for a type of service function". 
 
Hmmm, yes the text in 3.1 and 3.2.1.3 is all mixed up! We can't tell the
difference between an RD and a pool identifier!
 
> 3. "SFIR-RD List" in Figure 9 may be replaced with "SFIR-RD/SFI pool ID list",
as
> SFI pool ID is different from SFIR-RD and the list may consist of pure SFI
pool
> IDs.
 
Yes, again. As noted, 3.2.1.3 is all mixed up. 
 
> One further note is, upon processing this variable, we need to distinguish
> RD Type and SFI Pool Identifier Type, the IANA will need to take care not to
allocate 0x80XX for SFIR-RD Type.  
 
Yes, it's all a mess! Looks like we introduced the pool identifier without
enough thought :-(
What I have done for the next version is make a second sub-TLV of the Hop TLV so
that SFIs and SFI Pool Identifiers are kept separate.
 
> Some minor editorial comments:
> 4.  "SFRIR-RD list" in Section 4.3 is misspelling.
 
Yes
 
> 5.  s/a packets/a packet/
 
Yes
 
> 6.  s/ach subtended/as subtended/
 
Should be "each"
 
> BTW, I think it is useful to support load balancing SFs across multiple SFFs
as
> described in Section 5.5 of RFC 7665, this will enable a more flexible
deployment
> of similar service functions in multiple sites across a network, such as in 5G

> transport.
> In fact, Figure 11 in your draft already demonstrates that SF Type 41 has two
> instances attached to SFF1 and SFF2 respectively, I think another example can
> be added for load balancing across multiple SFFs, such as the following:
> --
>| SFIa |
>|SFT=42|
> --
>  --  --   |
> | SFI  || SFI  |  -
> |SFT=41||SFT=42| |   SFF5  |
>  --  --..|192.0.2.5|..
>   \/ ..:  -  :..
>  - .: :.-
>   --|   SFF1  |--/  - |   SFF3  |
>   -->|Class-|...|192.0.2.1||   SFF6  ||192.0.2.3|-->
>   -->| ifier|- |192.0.2.6|:-
>   --  -  |
>   |--
> --| SFI  |
>| SFIb |   |SFT=43|
>|SFT=42|--
> --   
 
Yes, an example of load balancing is a god thing to include in the examples.
Of course, load balancing in SFC is something that has to be done carefully to
avoid packet ordering issues and protect stateful SF processing.
That basically means that load balancing decisions need to be made with SFP and
flow awareness.
This is the point made by the examples in Section 8.9, and specifically the
examples in 8.9.3 and 8.9.4.
Can you have another look at those two examples and say whether they address the
load balancing you were thinking about?
 
Thanks,
Adrian
 
 
 
 
 
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] I-D Action: draft-ietf-bess-datacenter-gateway-01.txt

[Adrian Farrel]

Hi BESS,

Mainly a keep-alive on this draft. A couple of insignificant tweaks.

We think this draft is in a circling pattern until two references have
progressed through IDR:
- draft-ietf-idr-bgpls-segment-routing-epe
- draft-ietf-idr-tunnel-encaps

Adrian

> -Original Message-
> From: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] On Behalf Of
> internet-dra...@ietf.org
> Sent: 02 May 2018 23:30
> To: i-d-annou...@ietf.org
> Cc: bess@ietf.org
> Subject: I-D Action: draft-ietf-bess-datacenter-gateway-01.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   : Gateway Auto-Discovery and Route Advertisement for
Segment
> Routing Enabled Domain Interconnection
> Authors : John Drake
>   Adrian Farrel
>   Eric Rosen
>   Keyur Patel
>   Luay Jalil
>   Filename: draft-ietf-bess-datacenter-gateway-01.txt
>   Pages   : 11
>   Date: 2018-05-02
> 
> Abstract:
>Data centers have become critical components of the infrastructure
>used by network operators to provide services to their customers.
>Data centers are attached to the Internet or a backbone network by
>gateway routers.  One data center typically has more than one gateway
>for commercial, load balancing, and resiliency reasons.
> 
>Segment routing is a popular protocol mechanism for operating within
>a data center, but also for steering traffic that flows between two
>data center sites.  In order that one data center site may load
>balance the traffic it sends to another data center site it needs to
>know the complete set of gateway routers at the remote data center,
>the points of connection from those gateways to the backbone network,
>and the connectivity across the backbone network.
> 
>Segment routing may also be operated in other domains, such as access
>networks.  Those domains also need to be connected across backbone
>networks through gateways.
> 
>This document defines a mechanism using the BGP Tunnel Encapsulation
>attribute to allow each gateway router to advertise the routes to the
>prefixes in the segment routing domains to which it provides access,
>and also to advertise on behalf of each other gateway to the same
>segment routing domain.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-bess-datacenter-gateway/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-bess-datacenter-gateway-01
> https://datatracker.ietf.org/doc/html/draft-ietf-bess-datacenter-gateway-01
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-datacenter-gateway-01
> 
> 
> 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:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

Re: [bess] [sfc] [mpls] Progress with draft-farrel-mpls-sfc

[Adrian Farrel]

Wim and Robert,
 
[Dropping SPRING at this point as (as previously discussed) we have taken / are 
taking SR out of this document]
 
I think that draft-ietf-bess-service-chaining is really important work: it 
expresses a technique that is implemented and shipping.
 
On the other hand, this approach is not fully consistent with RFC 7665. 
 
But it does describe an actual SFC technology. Whether it remains in the field 
or is a migration technology only time (and operators) will tell.
 
Now, if we want to support RFC 7665 and RFC 8300 and use a control plane to 
discover the SFFs and to which SFs they provide access and to install 
"forwarding state" for SFPs, then we also have 
draft-ietf-bess-nsh-bgp-control-plane.
 
That draft was originally written with RFC 8300 in mind, but with the addition 
of one sub-TLV to indicate the encoding, it also supports 
draft-farrel-mpls-sfc. That should not be a surprise as draft-farrel-mpls-sfc 
attempts to model RFC 8300 as much as possible.
 
And that brings us back to "Where do we end up, what transition tools should we 
have, and how many steps to transition are there?"
 
draft-farrel-mpls-sfc provides another transition tool on the migration to RFC 
8300. It allows SFFs to be built as a minor mod to existing routers before 
there is forwarding plane support for the NSH.
 
But I want to reiterate that the discussion of wat encoding the SF supports is 
a red herring (certainly in the context of RFC 7665). An SF is either 
"SFC-aware" or not [RFC 7665 fig. 3], that is, it either can support the SFC 
encoding (such as NSH) or it can't. But also, an SF is either locally attached 
to the SFF or not. A local attachment is (of course) easier to operate and 
allows "bump in the wire" proxies very easily. A remote attached SF is (IMHO) 
attached via a tunnel.
 
The question of "remotely attached SFs" is one that should concern all 
implementations of RFC 7665 because no one (as yet) has worked on a protocol to 
bind SFs to SFFs. Robert is right that providing bump in the wire proxy for 
remotely attached SFs means that it is hard to know/control what goes where. 
But that problem exists to some extent for any remotely attached SF. For that 
reason (among others) I would implement the proxy as part of the SFF.
 
Cheers,
Adrian
 
From: Henderickx, Wim (Nokia - BE/Antwerp) [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 what we have and draft-ietf-bess-service-chaining-04 is an example of how 
you can use the existing data-plane for service chaining. draft-farrel-mpls-sfc 
requires an implementation change in the data-plane, whether we like it or not 
and an upgrade is required even in brownfield deployments. So, you better go 
directly to the final solution defined in IETF SFC WG. If we standardize 
draft-farrel-mpls-sfc we end up supporting both forever.
 
From: <rras...@gmail.com> on behalf of Robert Raszuk <rob...@raszuk.net>
Date: Saturday, 17 March 2018 at 19:13
To: Adrian Farrel <adr...@olddog.co.uk>
Cc: "Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderi...@nokia.com>, mpls 
<m...@ietf.org>, SPRING WG List <spr...@ietf.org>, "s...@ietf.org" 
<s...@ietf.org>, "bess@ietf.org" <bess@ietf.org>
Subject: Re: [sfc] [mpls] Progress with draft-farrel-mpls-sfc
 
Hi Adrian,
 
> That proxy may be a bump in the wire between the SFF and SF
 
I am not so sure about that ... If this would be just "bump in the wire" you 
would have zero guarantees that all packets which need to go via given function 
will actually hit that bump - so this is far from a reliable network service. 
 
There must be associated control plane component attracting traffic to such 
bump. 
 
That mechanism with basic MPLS (where labels by based MPLS architecture are of 
local significance) is available with L3VPN extensions as already progressing 
in BESS (draft-ietf-bess-service-chaining-04) so why not use this for as you 
state "interim" ? 
 
No one really addressed that question yet and I think it is a critical one to 
make any further judgement  as to the future of this individual submission. 
 
Cheers,
R. 
 
 
 
On Sat, Mar 17, 2018 at 6:46 PM, Adrian Farrel < <mailto:adr...@olddog.co.uk> 
adr...@olddog.co.uk> wrote:
Hi Wim,

Thanks for reading the draft so carefully.

> Adrian, on replacement of NSH. You will have to change the SF with this 
> proposal
> in Non proxy case so this proposal does not solve a brownfield case. Which 
> SF(s)
> support MPLS?

This is not about "replacing" the NSH. As you'll see from point 2, below, this 
is about providing an interim / migration tec

[bess] Update: I-D Action: draft-ietf-bess-nsh-bgp-control-plane-03.txt

[Adrian Farrel]

A few nits and fixed a bug in the IANA section.

Adrian

> -Original Message-
> From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of internet-
> dra...@ietf.org
> Sent: 18 March 2018 09:10
> To: i-d-annou...@ietf.org
> Cc: bess@ietf.org
> Subject: [bess] I-D Action: 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
> Authors : Adrian Farrel
>   John Drake
>   Eric Rosen
>   Jim Uttaro
>   Luay Jalil
>   Filename: draft-ietf-bess-nsh-bgp-control-plane-03.txt
>   Pages   : 54
>   Date: 2018-03-18
> 
> Abstract:
>This document describes the use of BGP as a control plane for
>networks that support Service Function Chaining (SFC).  The document
>introduces a new BGP address family called the SFC AFI/SAFI with two
>route types.  One route type is originated by a node to advertise
>that it hosts a particular instance of a specified service function.
>This route type also provides "instructions" on how to send a packet
>to the hosting node in a way that indicates that the service function
>has to be applied to the packet.  The other route type is used by a
>Controller to advertise the paths of "chains" of service functions,
>and to give a unique designator to each such path so that they can be
>used in conjunction with the Network Service Header.
> 
>This document adopts the SFC architecture described in RFC 7665.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-bess-nsh-bgp-control-plane/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-bess-nsh-bgp-control-plane-03
> https://datatracker.ietf.org/doc/html/draft-ietf-bess-nsh-bgp-control-plane-03
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-nsh-bgp-control-plane-03
> 
> 
> 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:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> 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

[bess] L2SM working group last call on draft-ietf-l2sm-l2vpn-service-model

[Adrian Farrel]

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

Re: [bess] IPR Disclosure Eric Rescorla's Statement about IPR related to draft-ietf-bess-evpn-overlay belonging to Chemtron Research LLC

[Adrian Farrel]

Martin is right.

OTOH Asking questions is legal.

However, answering them is optional.

A
> -Original Message-
> From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Martin Vigoureux
> Sent: 18 January 2018 11:12
> To: Ali Sajassi (sajassi); bess@ietf.org
> Subject: Re: [bess] IPR Disclosure Eric Rescorla's Statement about IPR 
> related to
> draft-ietf-bess-evpn-overlay belonging to Chemtron Research LLC
> 
> Ali,
> 
> licensing information is optional, as well as specifying which section
> of the document is affected by the patent(s).
> 
> regards,
> Martin
> 
> Le 2018-01-18 à 2:17, Ali Sajassi (sajassi) a écrit :
> >
> > Hi Martin,
> >
> > I have the following two questions:
> > 1) The disclosed IPR doesn’t have the licensing declaration section filled 
> > up. Is
> this section optional or is it just being overlooked?
> > 2) I found the following url for this IPR:
> https://www.google.com.pg/patents/US7936693. It would be good for the IPR
> author to explain how this CPOL is related to this draft – i.e., what 
> section(s) of
> the draft is covered by this IPR as I couldn’t figure it out by glancing 
> through it.
> >
> > Regards,
> > Ali
> >
> >
> > On 1/16/18, 1:56 PM, "BESS on behalf of Martin Vigoureux"  boun...@ietf.org on behalf of martin.vigour...@nokia.com> wrote:
> >
> >  WG,
> >
> >  as you can see, an IPR disclosure was made during the IESG review phase
> >  of draft-ietf-bess-evpn-overlay. We'd like to give you the opportunity
> >  to reflect on this and let us know if you see any reason not to proceed
> >  with the standardisation process.
> >
> >  Deadline for voicing opinions is set to the 23rd of January.
> >
> >  -m
> >
> >  Le 2018-01-16 à 19:51, IETF Secretariat a écrit :
> >  > Dear Ali Sajassi, John Drake, Nabil Bitar, Ravi Shekhar, Jim Uttaro, 
> > Wim
> Henderickx:
> >  >
> >  >
> >  > An IPR disclosure that pertains to your Internet-Draft entitled "A
> >  > Network Virtualization Overlay Solution using EVPN"
> >  > (draft-ietf-bess-evpn-overlay) was submitted to the IETF Secretariat 
> > on
> and
> >  > has been posted on the "IETF Page of Intellectual Property Rights
> >  > Disclosures" (https://datatracker.ietf.org/ipr/3131/). The title of 
> > the IPR
> >  > disclosure is "Eric Rescorla's Statement about IPR related to
> >  > draft-ietf-bess-evpn-overlay belonging to Chemtron Research LLC"
> >  >
> >  >
> >  > Thank you
> >  >
> >  > 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
> >
> >
> 
> ___
> 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