Re: [bess] Reg: RFC7432 EVPN - ES-import RT

[Prasannakumara S]

Hi Mankamana Mishra and Luc Andre,

Thanks for replying and sorry for quoting wrong type, yes its Type-0
instead of Type-1.
As clarified in the draft Type-0 also can follow same Es-import RT as long
as it doesnt overlap, that's good.

Was trying to understand Type-3 how PE's MAC is going to make it same ESI
on two PE's.

Regards,
Prasanna

On Fri, Jun 29, 2018 at 8:59 PM, Luc Andre Burdet (lburdet) <
lbur...@cisco.com> wrote:

> Hi Prasanna,
>
>
>
> FYI the ES-Import auto-extraction is expanded to ES Type 0,4,5 in
> https://tools.ietf.org/html/draft-ietf-bess-evpn-df-
> election-framework-03#section-3.3.
>
>
>
> Thanks
>
> Luc André
>
>
>
> [image:
> http://www.cisco.com/c/dam/m/en_us/signaturetool/images/banners/standard/09_standard_graphic.png]
>
> *Luc André Burdet*
>
> lbur...@cisco.com
>
> Tel: *+1 613 254 4814*
>
> Cisco Systems Canada Co. / Les Systemes Cisco Canada CIE
>
> Cisco.com 
>
>
>
>
>
> *From: *BESS  on behalf of "Mankamana Mishra
> (mankamis)" 
> *Date: *Friday, June 29, 2018 at 11:24 AM
> *To: *Prasannakumara S 
> *Cc: *"bess@ietf.org" 
> *Subject: *Re: [bess] Reg: RFC7432 EVPN - ES-import RT
>
>
>
> Hi Prasanna,
>
>
>
>
>
> On Jun 29, 2018, at 6:30 AM, Prasannakumara S <
> prasannakumar...@ipinfusion.com> wrote:
>
>
>
> Hi All,
>
>
>
> Related sections are:
> https://tools.ietf.org/html/rfc7432#section-5
>
> https://tools.ietf.org/html/rfc7432#section-7.6
>
>
>
> Would like to understand how ES-import RT should behave in case of
>
>
>
> 1. ESI type 1 - statically configured
>
> In this case on what basis one should import the ESI route as
> ES-import RT does not talk about ESI type 1. Why this should not follow the
> same semantics of creating ES-import RT as done for ESI Type 2; with the 6
> high-order octates? If same ESI is configured in different VTEPS then it
> would still work.
>
> This question comes because manually configuring the manual RT is tough to
> meet multiple combinations of multihomed sites.
>
>  - Type 1 (T=0x01) - When IEEE 802.1AX LACP is used between the PEs
>
>  and CEs, this ESI type indicates an auto-generated ESI value
>
>  determined from LACP by concatenating the following parameters:
>
>
>
>  + CE LACP System MAC address (6 octets).  The CE LACP System MAC
>
>address MUST be encoded in the high-order 6 octets of the ESI
>
>Value field.
>
>
>
>  + CE LACP Port Key (2 octets).  The CE LACP port key MUST be
>
>encoded in the 2 octets next to the System MAC address.
>
>
>
>  + The remaining octet will be set to 0x00.
>
>
>
>  As far as the CE is concerned, it would treat the multiple PEs that
>
>  it is connected to as the same switch.  This allows the CE to
>
>  aggregate links that are attached to different PEs in the same
>
>  bundle.
>
>
>
>  This mechanism could be used only if it produces ESIs that satisfy
>
>  the uniqueness requirement specified above.
>
>
>
> I do not think, Type 1 is statically configured.
>
>
>
>
>
> And if question was about
>
>
>
>- Type 0 (T=0x00) - This type indicates an arbitrary 9-octet ESI
>
>  value, which is managed and configured by the operator.
>
> Should it not be up to implementation to decide if they want to derive
> ES-import RT with 6 high-order octates  ?
>
>
>
>
>
>
>
> 2. ESI type 3 - MAC based ESI of the PE
>
> If MAC of the PE is considered then how different PE's can produce the
> same unique ESI? instead it should have used CE's MAC address?
>
> Since last/hig-order 6 octets are used for import how RT-import works?
>
>
>
> There is already Type 1 defined (Pasted above) which uses CE’s MAC
> address.
>
>
>
> As mentioned in https://tools.ietf.org/html/rfc7432#section-7.6 Auto
> derivation is only for Type 1, 2 , and 3. For other types, Admin would be
> responsible to configure correct ES-import RT.
>
>
>
>
>
> Let me know if I am missing something.
>
>
>
> Please refer me to any other drafts which are trying to address this; I
> can discuss over there and be part of that.
>
>
>
> Thanks in advance.
>
>
>
> Regards,
>
> Prasanna
>
>
>
>
> ..___
> 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] 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

[Henderickx, Wim (Nokia - BE/Antwerp)]

Adrian, yes lets discuss in Montreal to see how we can move fwd here.

On 01/07/2018, 14:11, "Adrian Farrel"  wrote:

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

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

[internet-drafts]

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/

___
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