►
From YouTube: IETF115-BESS-20221111-0930
Description
BESS meeting session at IETF115
2022/11/11 0930
https://datatracker.ietf.org/meeting/115/proceedings/
A
Okay,
folks,
it's
9
30.
welcome
to
the
the
best
working
group.
I,
just
I,
just
hope.
People
get
settled.
I'm,
I'm,
Matthew,
Bocce
man,
Commander
sitting
with
me,
is
our
working
group
secretary
Stefan
I
think
is
yes,
Stefan
is
online
as
he
the
other
chair.
A
Okay,
this
is
this
is
the
notes.
Well,
basically,
it's
saying
anything
you
say
here
is
considered
a
contribution
to
the
ITF
I'll
just
leave
it
up
for
a
moment,
future
Ponder.
A
Foreign,
so
this
is
our
agenda.
It's
a
fairly
busy
agenda.
We've
got
a
few
minutes
Slack
as
also
I.
Just
wanted
to
note
that,
as
some
of
you
may
be
aware,
today
is
Remembrance
Day
and
it's
marked
in
the
UK
and
many
other
countries
by
two
minutes
silence
at
11AM.
A
A
Okay,
so
status
update,
we
don't
have
any
new
rfcs.
We
have
a
couple
of
rfcs
still
in
the
a
couple
of
documents
in
the
RSC
editors
queue.
They
are
both
waiting
on
Miss
refs.
A
That's
the
IRB
multicast
draft,
the
evpn
LSP
ping
draft
evpm
prefdf
draft,
which
is
just
sitting
at
publication,
requested
at
the
moment
virtual
ethernet
segment
draft,
which
is
in
ad
follower,
I,
think
Andrew's
following
it
up
at
the
moment
the
VW
BPW
evpn
vpws
fxc
draft,
as
you
said,
publication
requested
and
the
evpn
aggregation
label
draft
is
with
Andrew.
A
Okay
under
we've
got
quite
a
few
documents
under
Shepard's
review.
We
had
a
big
queue
of
working
group
last
calls
done
over
the
last
year
or
so,
and
this
is
unfortunately
backed
up
a
bit,
so
I
think
rank
money.
You've
done
a
review
of
the
evpn
Redundant
multicast
Source
draft.
It's
waiting
for
is
that
still
waiting
for
write
up.
A
C
No
I
think
it
is
okay
now
because
I
requested
Realtors
to
reduce
the
number
of
offers,
and
we
documented-
and
this
has
been
done
so
I-
think
the
next
step
now
will
be
to
request
the
routing
directorate
review
as
part
of
the
of
the
new
process.
A
Thank
you.
The
EVP
engineer
draft
is
is
waiting
for
me
to
do
my
my
shepherd's
review
on
write-up
there's
a
kind
of
a
we
call
it
a
companion
draft,
but
there's
another
draft
in
the
nvo3
working
group,
which
is
describing
the
applicability
of
evpn
to
Geneva
yeah.
One
reminder:
can
you
use
your
the
the
on-site
tool
and
remember
to
register
your
presence
for
the
blue
sheets
up
on
the
using
the
QR
code.
A
The
first
DF
recovery
draft
is
waiting
for
a
shepherd's
write-up.
For
me,
I
did
send
a
comment
to
the
authors
which
I
haven't
seen
the
response
yet
about
whether
this
updates
RFC
85.
D
D
A
Draft
is
waiting
for
right
up
from
Stefan.
The
sd-wan
usage
draft
just
went
through
working
group
last
call,
but
there
is
a
routing
area
directorate
review
of
that
draft,
which
we're
still
waiting
for
the
authors
to
address
to
look
at
the
comments.
I
think
they
were
fairly
minor
comments
to
be
honest
and
just
a
reminder
that
we
will
be
sending
all
drafts
through
rooting
area
directorate
review
from
now
on
on
the
request
of
our
ad.
So
when,
when
we
do
a
working
group
last
call
we'll
do
that.
A
E
Sasha
Weinstein
ribbon
I
would
like
to
understand
what
happens
with
the
evpn
young.
It
appears
as
one
of
the
objectives
in
the
charter
the
draft
has
expired,
has
been.
There
is
a
war
group
document
that
has
expired.
Four
years
ago,
I
have
sent
a
few
emails
to
the
authors
to
the
group
to
the
chairs
asking
whether
this
work
has
been
known,
include,
dropped
or
or,
if
not,
whether
it
is
going
to
be
resumed
and
I
haven't,
got
any
responses
whatsoever.
A
Okay,
so
if
I
can
answer
that
question,
so
there
was
a
kind
of
a
consensus,
call
that
we
did
I
think
just
over
a
year
ago
about
what
to
do
with
the
young
drafts,
because
they
weren't
being
progressed
actively
at
the
time,
and
we
had
a
lot
of
other
protocol
documents
to
deal
with
then
so
they
were,
they
were
parked
should
say
their
parents
working
group
drafts
I
think
on
the
on
the
tracker.
C
E
A
but
is
it
going
to
be
to
be
resurrected
and
progressed
at
some
time,
or
is
it
just
going.
C
Of
course,
no,
no,
it's
not
it's
absolutely
not
canceled,
so
I
I
would
say
it
will
be
up
to
the
working
group
to
design
when
to
resume
it.
It's
perfectly
fine
to
to
go
ahead
with
the
documents.
If
we
are
now
ready
and
we
if
we
have
completely
cleared
the
dependencies
that
we
have
with
the
overall
young
models.
E
Okay,
because
this
is
something
that,
from
my
point
of
view,
is
needed
and
the
we
don't
know
my
colleagues
and
I
don't
know
what
to
look
for
and
what
to
expect.
Thank
you.
A
Okay,
this
EVP
and
I
said
CMAC.
Flash
draft
is
waiting
for
a
write-up
from
me,
so
I
think
you're
waiting
in
the
queue
for
the
other
drafts
right,
so
the
the
evpn
ipvpn
working
into
working
draft
so
that
that
is
still
in
a
kind
of
an
extended
last
call
at
the
moment,
because
we
did
we
had
a
review
from
the
IDR
working
group
and
the
chairs
had
some
comments
on
that
draft.
So
go
ahead.
F
This
is
this:
is
the
feedback
the
best
chairs
suggest
I
provided
this
at
this
time.
This.
My
review
of
this
found
three
things.
It
goes
against
an
roc-4456
requirement
for
full
distribution
routes
with
route
reflectors.
This
can
be
simply
noted,
as
we've
discussed,
that
with
the
best
chairs
and
find
that
the
topology
in
a
wild
garden
works
against
it.
It
also
specifies
a
transitive
path,
attribute
bpath
without
an
open
capability
limitation
and
specifies
changes
to
for
RFC
4271
without
an
open
capability
limitation.
F
The
last
two
are
could
break
I
understand.
The
word
could
not
must
break
the
b2p
route
selection
in
a
modified
4270
win
in
the
case
of
a
partial
deployment
that
may
could
could
lose
an
inconsistent
in
its
Cur.
F
So
the
IDR
chairs
are
concerned
about
the
approval
of
a
deep
path
in
the
4270
changes
without
an
open
capability
we
realize
at
this
time
there
are
wild
Gardens
construct
or
AKA
constrained
domains
in
VPN,
but
past
experiences
with
bgp
lead
us
to
believe
that
bgb
updates
can
escape
walled,
Gardens
and
cause
harm
to
the
internet,
and
perhaps
some
of
you
know
of
incidents
where
this
occurred
again.
F
We
think
that
there
are
some
things,
because
it
is
a
deployed
topology,
where
configuration
can
help
that,
and
we
look
to
continue
this
discussion
with
the
chairs
and
with
the
authors.
I
want
to
thank
Stefan
and
Jorge
for
their
great
interaction
on
this.
E
G
Jorge
yeah,
so
I
just
wanted
to
say
that,
first
of
all,
thank
you
sue
for
the
thorough
review
and
all
the
interaction
as
well
and
yeah
we
are
discussing
among
the
authors.
Our
understanding
is
based
on
Sue's
review
is
that
the
the
blocking
issue
right
now
is
to
provide
some
solution
to
avoid
the
leakage
of
this
d-path
attribute
into
Safi
one
routes
to
avoid
basically
the
potential
issues
that
the
ASU
was
referring
to.
So
that's
our
understanding
and
we
will
work
with
that
in
mind.
A
Right,
the
evpn
SR
p2mp
draft,
we
think
is-
is
ready
for
working
group.
Master
call
it's
in
our
in
our
queue.
If
there's
any
other
working
group
documents
that
the
authors
think
are
ready
and
we
haven't
listed
them,
please
raise
up
to
the
chairs.
A
Okay,
we
have
quite
a
few
expired
working
group
documents,
but
we
have
a
few
non-expired
working
group
documents
which
are
currently
being
updated.
A
Some
of
these
are
being
presented
on
the
agenda
today,
I
think
generally,
we
would
probably
like
to
see
a
higher
proportion
of
the
agenda
talking
about
how
we're
progressing
the
existing
working
group
documents
that
we
have,
we
have
a
best
seems
to
have
a
lot
of
it's
actually
very
healthy,
that
we
have
a
lot
of
new
work
coming
into
the
working
group,
but
we
do
have
a
lot
of
drafts
that
we,
we
they're
in
a
fairly
mature
state
that
we
probably
need
to
move
forward
as
and
and
we'd
like
to
get
some
updates,
and
maybe
at
the
next
ATF
from
the
editors
of
those
drafts.
D
And
I'll
be
presenting
updates
on
two
working
group
drafts.
The
first
one
is
RFC,
7432
bis,
so
this
is
the
update
to
the
base
7432
draft
that
we've
been
using
in
best
free
VPN.
D
This
latest
version
has
actually
a
fairly
significant
update,
both
editorial
and
towards
content,
so
I
thank
both
Sasha
and
Marek
for
their
for
their
comments.
Thank
you,
and
we
did
quite
a
bit
of
rework
to
include
content
from
other
drafts
in
the
working
group
to
have
them
be
part
of
the
new
base.
7432
bits
next
slide.
D
So
the
changes
from
O3
so
I
did
not
present
the
changes
in
o4,
but
from
since
O3.
This
draft
now
effectively
creates
in
the
ESI,
extended
Community
label
field,
a
Ina
or
request
an
Ina
registry
for
this
field.
Previously
this
field
was
effectively
just
defining
the
no
flag
present
being
all
active
load,
balancing
mode
and
7432.
D
The
base
defends
defines
sorry
the
single
active
mode
with
one
flag,
but
we
found
through
I
forget
which
draft
maybe
prefdf
or
I,
forget
which
draft,
but
we
found
that
updating
this
ESI
field
led
to
some
collisions
so
effectively.
This
draft
now
defines
an
I
and
a
registry
for
allocating
fields
or
bits
in
this.
D
In
this
Flags
field,
the
best
path
sections
were
updated,
both
from
the
default
gateway,
which
was
in
1011,
so
they
were
taken
from
a
a
best
pass
draft
that
existed
in
best
to
to
clearly
Define
or
clearly
order
the
best
path,
selection
for
evpn
routes,
and
this
the
section
currently
covers
routes
one
to
three,
and
there
was
some
question
on
the
usage
of
the
usage
of
the
label,
two
field,
which
is
effectively
not
defined
the
usage
of
the
label.
D
Two
field
was
not
defined
in
the
draft
and
so
there's
a
reference
to
9135.
That
is
that
is
added
to
the
draft
now,
and
apart
from
that,
just
many
comments
and
significant
editorial
changes
in
between
all
four
and
o5.
Actually,
the
next
steps
for
this
draft
on
the
next
slide
are.
D
We
have
received
many
reviews,
many
comments,
since
it
was
first
published
and
even
when
it
was
first
published,
the
the
zero
zero
version
of
the
draft
actually
was
based
on
a
plethora
of
comments
on
the
bass
draft
base
7432.
So
obviously,
more
reviews
and
more
comments
are
always
welcome,
but
this
draft
is
nearing
working
group
last
call
stage,
so
I
think
we
will
be.
We
will
be
ready
to
to
see
class
call
on
this
draft.
C
C
D
The
next
draft
I'm
presenting
if
there
are
another
no
other
questions,
is
the
is
the
evpn
multi-homing
for
layer,
2
Gateway
protocols.
So
this
is
the
one
that
Stefan
mentioned
in
one
of
his
slides
for
active
working
group
documents.
So
we
refreshed
it
specifically,
in
our
case,
this
evpn
multi-homing
attributes
registry
that
we
just
that
we
just
went
over
so
now,
there's
a
new
load,
balancing
mode
defined
and
instead
of
just
allocating
a
bit,
we
now
allocate
an
entry
in
this
load,
balancing
registry
or
multi-homing,
attribute
registry.
D
There
was
some
comments
received
based
on
clarifying
the
art
procedures
in
the
in
the
draft,
and
so
the
diversion
actually
I
think
it's
not
O2,
but
the
version
that's
currently
active
I
made
updates
to
explicitly
reference
9135.
So
the
irb-based,
our
probing
procedures,
but
I
have
spoken
to
to
the
person
who
made
those
comments
due
to
Sasha
actually,
and
he
was
actually
seeking
a
a
reference
to
both
our
probing
scenarios
right.
The
IRB
and
the
non-irb
scenario.
D
So
I
will
include
that
use
case
of
non-irb
in
the
next
in
the
next
update
and
Define
the
art
probing
procedures
for
non-irb,
so
other
than
that
on
the
next
slide.
This
draft
has
matured
quite
a
bit.
We
have
received
reviews
and
comments
from
many
vendors
and
operators.
Actually,
so
the
there
are
implementations
of
this
draft
it
is
in
use,
so
we
would
be
seeking
working
group
Last
Call
on
it.
A
H
Good
morning
my
name
is
I'm
here
to
talk
about
the
evpn
layer,
3
multi-homing
little
balancing.
This
is
a
draft
that
that
came
out
about
more
than
a
year
ago,
and
so
what
we
decided
to
do
here
is
to
bring
more
calibrator
collaboration
with
or
a
and
when,
for
the
other,
from
Jennifer
and
Nokia,
so
I
know
for
times
constraint.
I
may
not
go
through
all
the
whole
things,
but
I
think
what
is
really
important
is
that
people
start
looking
at
it.
H
H
All
right,
so,
basically,
what
we
are
trying
to
achieve
is
it's
exactly
what
we,
what
we
have
been
designing
for
a
while
in
evpn,
but
over
LD
interface,
so
you
will
see
that
we
are
taking
care
of
unicast
multicast
and
a
few
of
the
igp
stuff.
Please
next
slide.
H
So
so
the
mechanic
also
is.
You
will
see
that
whenever
you're
going
to
read
the
draft
is
like.
We
need
also
to
make
sure
that
whenever
the
synchronization
is
happening,
we
can
refer
to
the
right
interface,
the
right
Delta
interface.
So
all
the
mechanics
has
been
described
there.
So
in
the
new
version
we
put
a
bunch
of
clarification
to
help
the
readers
to
understand
how
that
how
this
is
working,
I
think
with
hurry
and
when
we've
done
a
very
good
job
on
that.
Please
next.
H
This
is
pretty
much
the
reptile
that
are
evicted
and
the
use
case
that
we
are
covering
next
one
and
the
beauty
about
this
one
is
the
entire
mechanics
already
exists,
so
so
it
just
pretty
much
explaining
how
we
use
current
mechanics
to
and
get
applied
for,
L3
interfaces
thanks
yeah.
Obviously
we
have
a
bunch
of
advantages
with
that,
because
what
it
means,
then
we
are
kind
of
going
away
from
direct
ICI,
ICN
link
and
the
whole
Legacy
mechanic
at
Cisco.
We
do
have
already
this
solution
being
being
run
on
customers.
H
G
Okay,
yeah
I
have
a
short
review
of
three
drafts
here.
The
first
one
is
the
evpn
vpws
Gateway
zero
one
presenting
this
on
behalf
of
my
friends
from
Nokia
Junior
Francisco.
G
We
presented
this
this
draft
to
iets
ago
and
I
think
now
it's
much
more
stable
and
better
in
this
next
slide.
Please
yeah
I'm
going
to
talk
about
a
short
refresh
changes
that
we've
made
in
version
zero.
One
and
next
steps
next
slide.
Please
the
the
draft
in
the
introduction
talks
about
different
ways
of
having
interconnectivity
across
domains
for
evpm
vpws
services.
G
It
talks
about
three
different
solutions
which
are
all
perfectly
valid
and
depending
on
the
requirements,
you
should
go
to
one
or
the
other,
but
if
you
have
the
requirements
that
are
listed
here
in
this
table,
probably
the
best
solution.
Is
this
service
interworking
spec
that
we
are
we're
specifying
here
and
there
was
nothing
about
it
in
the
in
the
best
working
group?
So
that's
why.
I
I
G
Slide
please
so
the
the
draft
is
basically
all
about
making
the
water
routers
across.
You
know
connecting
different
domains,
making
them
service
gateways
and
in
the
draft
we
talk
about
redistribution
of
the
routes
of
the
ad
per
evi
routes
and
even
though
you
know
raw
distribution,
May
mean
different
things
for
different
people.
So
it's
good
to
to
understand
what
it
means
in
this
draft
in
the
context
of
this
document.
G
G
We
also
need
to
program
the
forwarding
path
based
on
the
received
route
and
also
based
on
the
encapsulation
of
the
next
domain,
and
and
finally,
we
need
to
re-advertise
the
route
to
a
different
domain.
This
re-advertisement
is
really
a
re-origination
of
the
route,
meaning
that
we
can
translate
rewrite
the
route,
the
route
distinguishers,
the
ethernet
tag
and
and
many
other
attributes
in
the
route.
Next
slide,
please,
as
far
as
the
redundancy
is
concerned,
we
defined
two
ways
of
doing
it.
G
So
the
first
one
here
on
the
left
hand,
side
is
what
we
call
the
any
gas
gateways
redundancy,
and
this
is
a
all
about
configuring,
exactly
in
the
same
way
the
the
service
gateways
that
are
connecting
to
given
domains
right.
So
they
when
they
redistribute
the
routes,
they
will
do
it
with
the
same
route,
distinguisher
the
same
ethernet
tag
and
everything
so
the
next
four,
the
routers
or
the
peas.
They
rely
on
the
pgp
best
selection
to
pick
up
one
of
the
the
service
gateways.
G
The
second
way
is
a
bit
more.
Sophisticated
is
Illustrated
on
the
right
hand,
side
and
here
basically
each
pair
or
you
know,
all
their
redundant
service
gateways
that
are
connecting
two
given
domains.
They
are
attached
to
what
we
call
an
interconnect,
ethernet
segment,
the
interconnect
ethernet
segment
is
defined
in
RFC
9014
for
Elan
Services.
Here
we
are
repurposing
the
same
concept
for
evpm
vpws
services,
but
other
than
that
you
have
all
the
the
beauties
of
EVP
and
multi-homing.
So
you
can
Define
the
ethernet
segment
as
a
single,
active
or
active.
G
You
have
all
the
idea.
Selection
mechanisms
Etc
next
slide,
please
so
the
changes
that
we
made
in
this
revision
pretty
much
are
these
two.
We
added
support
for
fxc
services,
so
you
can
also
do
this
fxc
Services
across
different
domains.
We
updated
references
in
some
other
minor
details
next
slide,
please.
G
A
G
G
All
right
next
one
is
the
vpnd
bath
draft
again
presenting
on
behalf
of
my
friends
from
Nokia
system
Juniper
next
slide.
Please
I'll
talk
about
a
short
refresh,
what's
new
in
this
version
and
next
steps
next
slide,
please
yeah!
So
what
we
are
doing
here
with
this
draft
is
we
take
the
d-path
attribute
that
we
talked
about
before
that
is
defined
in
the
evpn
and
ipvp
and
interworking
draft
the
initially
the
attribute
was
only
for
layer,
3
routes,
route,
type,
five,
any
VPN
or
ipvpn
routes.
G
Here
we
are
using
it
for
layer,
2,
evpn
routes
right,
and
we
want
to
use
d-path
for
two
purposes
here
to
provide
some
Loop
detection
and
therefore
protection
as
well,
specifically
on
service
gateways
that
are
following
IFC
9014,
but
we
also
want
to
use
it
so
that
the
the
PE
is
receiving
the
evpn
layer.
2
routes
can
see
the
t-path
and
and
Trace
the
all
the
gateways
through
which
the
route
has
gone,
and
there
is
also
we
use
it.
G
You
know
in
case
the
d-pad
has
different
length.
We
also
use
it
for
modifying
the
best
path,
selection
for
evpn
layer,
2
routes.
Next
slide.
Please
a
simple
example
would
be
what
you
have
here
in
the
in
the
diagram.
Let's
say
you
have
two
data
center
gateways
interconnecting
two
domains
and
they
are
attached
to
the
same
broadcast
domain.
G
So
the
two
data
center
Gateway
they
receive
a
given
Mac
IP
route
from
from
ipe.
They
redistribute
that
route
into
the
other
domain
and,
of
course,
the
the
two
redundant
data
center
gateways.
They
receive
each
other's
routes,
but
the
the
nice
thing
now
is
that
when
they
redistribute
into
the
other
domain,
they
slap
the
d-path
with
the
identifier
of
the
domain
of
origin.
So
now,
for
instance,
data
center
Gateway
One
when
it
receives
the
Mac
route,
identifies
that
is
coming
from
domain
1.1,
which
is
a
locally
configured
domain.
G
Now
the
other
advantage
of
this
model
is
for
whatever
reason:
if
data
center
data
center
Gateway
One
loses
the
route
coming
directly
from
the
PE,
it
has
already
another
route
that
is
actually
advertised
from
data
center
gateway2.
So
you
can
do
this
U-turn
thing
and
provide
the
fast
convergence
for
in-flight
packets
next
slide.
Please
another
example
that
we
have
in
the
in
the
draft
is
for
imet
routes
for
for
inclusive
multicast,
ethernet,
Tech
routes
or
routes,
type
3.
G
same
thing.
You
can
have
gateways
interconnecting
domains
for
in
the
same
broadcast
domain,
so
they
both
exchange
iMed
routes
in
different
domains.
So
normally
you
would
need
to
avoid
somehow
manually
to
avoid
the
the
two
parallel
links
to
be
created
in
both
domains.
To
avoid
packet,
duplication,
debuff
provides
an
automated
way
to
to
do
that.
G
Basically,
you
would
tag
the
diamond
routes
in
one
of
the
domains
with
with
the
d-path
domain,
and
that
would
be
enough
for
the
gateways
to
modify
the
best
pass
selection
and
pick
up
only
one
next
slide.
Please.
G
So
what
is
new
in
this
version?
Zero?
Two.
Basically,
we
modified
this
section
about
best
path,
selection
for
routes
type,
one,
two
and
three
now
it's
aligned
with
the
with
7432
bits
that
Luke
was
talking
about
before.
G
We
only
modify
that
section
of
74
C2
based
in
this
draft
with
including
d-path
for
the
best
pass
selection
of
of
these
evpn
layer,
2
routes.
G
We
are
also
clarifying
what
happens
if
you
have
on
the
on
the
service
gateways
that
are
following
the
9014
procedures
and
they
have
a
interconnect
internet
segments,
how
you
deal
with
the
ESI
and
the
d-path,
because
both
could
be
used
to
to
detect
Loops.
So
we
are
clarifying
that
in
the
draft
and
some
other
minor
changes
next
slide.
Please
again,
so
this
is
version
zero.
Two
We've
presented
this
several
times,
so
we
believe
it's
ready
for
working
group
adoption
and
but
of
course,
in
the
meantime,
we
we
welcome
any
feedback.
G
F
I
would
suggest
my
same
comments
from
the
deep
path.
If
you're
in
a
single
domain,
you
need
to
put
an
exception
444
for
the
route
reflectors,
if
you're
not
retaining
the
same
consistency
if
you're
between
domains,
you
should
explain
what
the
error
handling
is
there
just
this
and
if
I'm
unclear
I
can
take
it
offline
or
do
if
you
want
me
to
answer
it
here.
I
can.
G
Yeah
we
we
can.
We
can
certainly
do
that.
The
my
only
comment
would
be
that
RFC
19014
is
one
example
that
it's
already
noticed
in
the
that
centers
was
not
written
there
right,
but
yeah.
We
can
do
that
if.
F
It
happens,
I
I
would
suggest
that
addition
I,
would
suggest
nine
90
14
bits,
but
let's
just
go
on
and.
G
G
A
Any
other
questions,
questions.
G
Okay,
so
one
more,
this
is
about
multicast
forwarding
for
evpn
to
EVP
and
gateways
or
eggs.
G
This
is
a
new
work
and
it's
pretty
much
based
on
some
gaps
that
we
identified
in
in
the
different
EVP
multicast
drafts,
so
I'm
presenting
this
on
behalf
of
a
bunch
of
people
from
Nokia,
Arista
and
Juniper
next
slide.
Please
so
I'll
talk
about
introduction
some
procedures
and
next
steps
next
slide.
Please
all
right!
So
why?
Why
are
we
doing
this?
G
There
are
two
parts
and
again
we'll
we'll
be
talking
here
about
service
gateways
and
what
I
mean
by
that
is.
You
have
multiple
domains
and
you
have
a
service
gateways
interconnecting
those
domains.
It
can
be
for
Layer,
Two
services
or
layer
3
services.
G
Let's
talk
about
Layer
Two
Services
first,
so
we
know
that
we
have
RFC
9251,
that
is
defined
in
item
pmld
proxy
in
the
context
of
evpn,
in
a
single
evpn
and
broadcast
domain,
we
also
have
949014,
which
is
defining
the
service
Gateway
connectivity
for
Unique
ass
and
for
bomb
traffic,
but
not
for
IP
multicast.
G
Because
of
of
that,
basically,
the
the
equation
that
came
up
is
how
how
do
we
interconnect
two
or
more
evpn
domains
with
you
know,
gateways
following
9014
when
the
piece
in
in
the
domains
basically
support
the
igmp
MLD
proxy
VPN
procedures,
right?
That
was
not
defined
anywhere,
so
we
needed
a
place
to
do
it.
G
G
That
graph
is
actually
defined
in
service
gateways
between
oism
and
team,
Pim
or
mvpn.
But
the
question
is:
we
are
missing
a
place
where
we
specify
what
happens
if
you
have
two
evpn
layer,
three
domains
and
you
want
to
forward
IP
multicast
between
them.
That
was
not
specified
anywhere
so
result
of
that
we
we
thought
it
was
needed
this.
We
needed
this
document.
So
next
slide
please.
G
So
the
document
has
two
distinct
parts,
so
one
for
Layer
Two,
another
one
for
layer
three.
So
if
we
talk
about
layer
2
first,
the
diagram
is
it's
an
illustration
that
is
also
included
in
the
draft,
and
you
can
see
that
there
are
two
evpn
domains
right.
G
All
the
piece
and
gateways
are
attached
to
the
same
broadcast
domain
right.
The
gateways
in
between
they
are
connecting
those
to
evpn
domains.
G
Here,
in
the
example
we
have,
we
assume
that
one
domain
is
is
using
vx9
encapsulation
and
the
other
one
is
mpls
or
SRM
TLs,
but
any
other
two
encapsulations
would
be
also
valid.
G
What
we
are
extending
here
is
that
now
the
gateways
they
import
the
sment
routes
or
the
selective
multicast
ethernet
tank
routes
coming
from
the
piece
and
they
perform
what
we
call
a
proxy
function
of
those
estimate
routes
right
when
you'd
use.
When
you
use
redundancy
in
the
interconnect
internet
segment,
there
is
a
DF
and
a
non-df,
so
we
mandated
EF
to
do
the
proxy
function
of
the
esmet
routes.
There
is
an
option
too,
if
you
wanted
to
to
provide
a
faster
convergence
in
case
of
a
failure.
G
There
is
an
option
for
the
non-df
to
also
do
the
proxy
function
of
the
azmet
routes
that
is
also
allowed,
and
when
you
do
that,
basically,
there
is
a
risk
of
a
control
plane
Loop
for
the
estimate
routes
between
the
Redundant
gateways.
That's
why
we
also
introduce
the
t-path
for
the
s-met
routes
in
the
data
plane.
There
are
no
extensions
here,
so
basically
the
non-df
will
block
the
Ingress
and
Ingress
multicast
as
per
the
RFC
9014,
and
the
draft
also
supports
local
receivers
and
sources
on
the
service
gateways.
G
G
G
Now
it's
it's
important
to
mention
that
the
draft
also
says
that
if
the
gateways
are
able
to
perform
the
all
the
procedures
with
with
a
single
SBD,
in
other
words,
if
the
behavior
in
the
on
the
wires
is
the
same
as
the
the
ones
you
know
explained
in
the
draft,
if
the
implementation
uses
only
one
SBD,
that's
perfectly
compliant
with
the
draft
there
is.
G
There
is
also
here
we
Define
one
more
flag
for
the
multicast
texts
and
the
communities
that
is
exchanged
by
the
gateways
on
the
iMed
routes,
for
the
SBD
and
based
on
that
there
is
a
Dr
election
or
a
designated
router
election.
So
the
Dr
in
this
context
is
the
the
one
in
charge
of
doing
the
proxy
function,
similar
to
the
the
layer
2
case
for
the
estimate
routes
between
domains.
G
Yeah,
we
also
support
her
here's
local
receivers
and
sources
on
the
on
the
service
gateways.
Next
slide,
please
it's
a
first
version.
So,
of
course
we
are
very
interested
in
in
feedback
from
the
working
group
and
that's
it
any
questions.
J
Hello
I'm,
presenting
on
behalf
of
my
co-authors,
so
this
is
an
update
to
our
draft
and
advertising
applicability
of
sbfd
in
multi-homed,
P
domain
and
four
inter
area
next,
one
at
least
okay,
so
I
was
invited
and
I
was
happy
to
join
as
a
coffer
and
we
worked
in
updated
scenario.
Descriptions
next
slide,
please.
J
So
the
BFD
is
well
known
and
established
method
of
fast
detection
of
faults,
but
it
does
bear
some
extra
operational
work
that
requires
provisioning
of
BFD
sessions.
Sbfd
overcomes
some
of
this
operational
aspects,
but
just
to
simplify
it
does
require
their
information
about
the
IP
address
of
their
reflector
sbfd
reflector
and
the
discriminator
that
this
reflector
allocates
for
sbfd
session
or
sessions.
J
So
the
rfcs
already
established
extensions
to
igp
to
edit
for
systems
to
advertise
their
be
sbfd
discriminators.
So
this
document
extends
this
functionality
into
bgp
next
slide
for,
inter
and
intra
area
scenario.
So
this
is
scenario
one
so,
as
you
can
see.
J
So
the
idea
is
that
you
have
a
service
CE
double
home
with
their
service,
please
and
then
their
set
of
access
piece.
The
idea
is
that
service
B
advertises
its
the
discriminator.
So
that
xsps
can
monitor
this.
J
A
service
six
locator.
J
Any
questions
about
the
scenario:
okay,
next
slide,
please
so
scenario
two
is
similar
again
we
have
double
homed
service,
C
and
then
service
PES
advertise
as
B
of
D
extension
with
the
discriminator
and
the
source
IP
address,
and
so
the
access
piece
can
monitor
their
status
of
their
connection
and
the
PE,
because,
understandably
in
sbfd,
you
cannot
differentiate
whether
it's
a
path,
failure
or
not
failure.
J
So
you
need
to
have
integral
view
in
it
basically
fall
over
and
then
separately
do
fault,
localization
and
restoration,
but
at
least
because
it's
redundancy,
so
there
is.
This
architecture
allows
you
for
the
fast
detection
and
fast
fell
over
next
slide.
Please
so
what's
been
used,
the
bin
used
the
BFD
discriminator
that
is
defined
in
RFC
9026,
so
this
is
was
case
for
point
to
point
BFD
mode.
So
in
this
document
we
propose
two
new
values
for
BFD
mode
parameter.
J
Next
hop
locator
in
both
cases,
optional
Tov
carries
the
source
IP
address
so
that
the
receiver
of
this
that
attribute
can
understand
what
case
is
being
tested
and
next
slide.
Please
so
here's,
basically
what
each
of
the
actors
in
in
this
process
does
so
as
BFD
reflector
uses
BFD
discriminator
attribute
to
advertise.
J
J
And
start
sending
periodic
BFD
control
messages
so
that
when
they're
in
our
case,
service
B
receives
it,
it
sends
it
back,
and
so
their
access
D
is
capable
of
monitoring
the
path
and
status
of
given
service
B.
And
then,
if
there
is
a
failure,
then
switch
over
to
a
redundant
destination
next
slide.
Please.
J
So
with
that,
we
welcome
comments
and
discussions
and
we
think
that
the
draft
is
stable
and
and
currently
ask
you
for
consider
working
group
adoption.
A
Okay,
Castle
is
in
the
queue,
but
I
don't
see
an
on
meet.
B
So
Greg
I
understand
this
is
the
BFD
discriminator
attribute,
which
is
already
existing
and
that's
defined
as
an
optional
transitive
attribute
in
the
RFC
where
it
was
introduced,
it
was
applicable
for
mvpn,
but
my
understanding
that
your
ex
expanding
its
use
to
probably
all
other
office
as
well
here.
J
Yes,
correct,
actually,
okay,
going
back
to
the
original
RFC
in
discussion
that
we
had
and
now
can
better
appreciate
their
suggestions
from
Jeff
to
make
it
more
generic.
So
now-
and
you
are
right-
and
the
scenario
that
being
covered
in
original
RFC
for
point
to
multipoint
was
different
because
then
for
point
to
multi-point
BFD,
it
is
their
head
end
advertises
its
discriminator
value,
so
informing
the
leaves
in
this
case.
Yes
we're
using
existing
attribute.
But
it's
reverse.
J
So
it's
a
reflector
advertises
discriminator
value
that
it
expects
Ingress
or
packets,
BFD
control
messages
to
descend
it
with
and
use
this
value
as
your
discriminator,
so
that
reflector,
the
multiplexes
them.
B
Right,
so
that's
what
I
understood
as
well.
So
my
concern
here
is
that
this
is
an
optional,
transitive
and
I
know.
Probably
you
may
be
aware
or
not,
but
there
has
been
discussion
in
the
IDR
working
group
about
these
attributes
going
I
mean,
and
in
your
example
pictures
you
showed
about
Crossing
as
borders
right.
B
Yes,
so
I
think
you
might
want
to
check
on
this
with
that
in
the
idea
working
group
to
get
inputs
on
how
to
prevent
this
information
from
leaking
out,
especially
because
this
also
applies
to
every
everyone
right.
So
I
I
just
wanted
to
bring
that
up
here.
J
Okay,
thank
you
for
your
comment
and
suggestion
definitely
will
educate
ourselves
on
that
and
bring
it
more
probably
more,
we'll
welcome
more
expertise
with
from
RDR
and
I
guess.
We
have
Jeff
ready.
A
I
Has
so
keitans
made
the
point
excellently
the
thing
the
general
advice
idea
I
would
give,
and
a
number
of
these
issues
is
if
the
attribute
gets
attached
to
something
that
can
leak
into
general
internet
or
other
context.
What
bad
things
can
happen?
So
framing
this
specific
issue
here.
Do
you
really
want
the
outside
rule
to
have
your
BFD
discriminators?
And
you
know
this?
What
you're
sort
of
telling
people
is
you
know,
spfd
is
a
reflector
technology.
I
Reflector
Technologies
are
used
for
reflector
attacks,
so
this
is
the
danger
of
having
you
know
a
service
like
spfd,
which
has
no
authentication
for
Echo
being
advertised
the
outside
world.
Certainly
you
can
limit
access
to
these
Technologies
through
firewalls.
You
can,
you
know,
make
sure
your
domains
actually
are
filtering
things
appropriately,
but
what
you'd
get
is
advice
from
the
security
ads
is
that
this
is
inadvertent
disclosure
in
some
cases,
optional
transitive
is,
unfortunately,
very
leaky
for
bgp
and
once
you
put
it
in
there,
it's
sort
of
hard
to
get
rid
of
it.
I
J
You
and
actually
you
pointing
out
and
highlighting
this
security,
one
of
the
mechanism
to
mitigate
security
risk
is
a
use
of
Source
IP
address
in
BFD
discriminator
attribute.
So
basically
that
gives
the
reflector
way
of
verifying
the
source
of
BFD
control
messages
and
then
protecting
itself
from
service
attacks.
I
A
K
Yes,
can
you
hear
me.
A
K
J
We
we
well
their
assumption
is
that
evpn
is
interpreted
as
a
VPN
with
their
bgp
based
control
plane.
So
if.
K
J
Know:
okay,
yeah
I
guess
I
see
yes,
I
might
be
that
clarification
would
be
helpful
because
you're
right
so
basically
that
what's
intended
to
be
monitored
as
a
destination,
is
related
to
a
service,
six
locator
and
the
policy
So
yeah.
Thank
you
for
your
suggestion.
We'll
make
the
analysis
and
clarify
the
scope
of
this
work.
Okay,.
B
Yeah
I
just
took
Ketone
here
just
a
quick
follow-up
to
Jeff's
comments
and
I'm
wondering
whether
approach
that
was
used
for
the
ELC
V3.
Isn't
that
some
kind
of
something
that
is
needed
in
this
case
as
well
I'm,
not
really
sure
if
just
putting
things
in
the
security
considerations
would
be
good
enough.
J
Okay,
I
I,
guess
that's
something
that
we.
We
need
to
talk
with
you
as
ideal
experts,
so.
L
From
Hawaii,
firstly,
I
think
the
motivation
of
this
work
is
start
from
the
srv6
service,
the
spfd
in
that
case.
Well,
we
also
can
generalize
it
to
other
related
three
vpns.
That
is
also
possible.
We
may
add
some
clarification
about
this
in
this
version
and
regarding
the
security
or
the
the
announcement
scope
of
this
feature.
Actually,
if
we
use
it
with
a
VPN
in
the
context.vpn,
the
distribution
of
this
attribute
will
be
constrained
together
with
the
vaping
rounds.
So
I
think
that
is
also
controllable
for
VPN
service
route.
M
M
This
document
was
published
before
itf112
and
a
presented
in
item
113
and
8114,
and
there
is
a
long
Suite
of
technical
discussion
on
this
document
with
Jeffrey.
So,
thanks
generally
for
the
discussion,
I
was
in
the
adoption
and
the
review
request
to
working
group
after
itf114,
but
not
replied
too
long.
M
M
M
Six:
six
five
one
five
fix
some
problems
in
iqb6
infrastructure
scenario
in
the
regular
and
whipping
procedure
of
RC
6014
division,
long
segmented
in
her
as
Demarcus
root,
using
originator,
IP
of
the
root
P
to
fill
the
sources
field
of
the
mli
and
the
SBR
counters
C
markets
group
locating
between
s,
along
with
the
reserved
parts
of
intra
sad
using
artists
and
sources
of
C,
martial
UI
to
match
against
Rd
and
originator
FC
of
the
corresponding
interest
ad.
The
problem
is
that
the
sources
field
of
the
cmatic
housing
AI
is
four
bet.
M
One
for
Badlands
cannot
hold
IPv6
originating
IP
in
IPv6
influence
function.
Scenarios
next
slide,
please,
so
here
is
the
proposed
solution
for
the
propagating
culture
between
asses
svr
steel,
cultural
C
markets
locating
along
with
the
reserved
parts
of
the
instrument,
sad
Studio
use,
Rd
of
cmaticals
in
our
match
against
study
of
the
corresponding
interest
ad.
The
only
modification
is
that
the
global
administrator
field
of
the
IPv6
thematic
has
import.
Rt
is
instead
of
sources
field
of
simultaneous
URI
to
match
against
the
originated
later
IP
of
the
corresponding
interest
ad.
M
All
those
IPv6
extend
the
community
carry
in
the
simultaneously
include
more
than
one
IPv6
input
artists.
There
is
only
one
which
would
will
be
used
by
the
route
key
to
import,
the
corresponding
schematic
handle
to
its
local,
where
I
have
another.
Only
one
IPv6
import
RT
has
a
characteristics
that
the
local
administrator
field
is
non-zero,
which
can
be
used
by
the
procedure
to
distinguish
it
from
the
other
input
artists.
M
It
should
be
loaded
that
in
GTM
scenarios,
the
local
administrator
field
on
IPv6
in
polarity,
used
by
root
P
to
import
the
corresponding
simultaneous
root
is
also
zero
according
to
is
also
zero
according
to
RC
7761.
So
we
suggest
that
the
local
administrator
field
of
the
activistics
important
GTM
scenario
is
also
filled
with
a
Long
Level
value
which
are
sent
by
root
Shield
through
the
way
of
importer.
M
Next
slide,
please
if
there
are
only
one
root,
key
for
a
specific
grammatical
Source.
The
solution
is
in
previous
slides
is
enough.
Here
are
the
scenarios
that
a
specific,
multiple,
Source,
smart
home
into
multiple
piece?
The
long
segment
is
the
interior
as
C.
Multiple
root
must
be
discussed
for
each
individual
root
piece.
There
are
three
options:
option
one
each
root
be
configured
with
16
Rd,
which
is
recommended
in
rc6514
option
two:
each
root
C
configured
with
a
distinct
format,
emulation
distinguishers
to
use
to
fill
the
sources
field
of
C
multiples
in
URI
option.
Three.
M
Only
please
use
the
comma
Hashi
algorithm
to
calculate
the
16
fat,
loot,
IPS
204,
but
unique,
unique
distinguishers
to
failure
sources,
field
of
C
marketing,
AI
option,
2
and
office.
3
are
used
in
the
scenarios
of
English
she
configured
with
a
scene,
Rd
gtms
as
an
example.
M
M
The
following
figure
is
example,
is
an
example
of
pgp
MLP
enable
Evolution
to
activate
six
ipv4
and
IPv6
power,
which
sessions
are
established
and
the
number
of
passes
of
this
route
will
be
doubled
with
each
reflection.
M
So
the
solution
is
that
to
reduce
BGC
and
whipping
routes
in
parallel
ipv4
another
IPv6
specification
networks,
the
firing
action
should
be
taken
by
a
standard
piece
for
interest,
iPhone
message
routes
and
the
new
3D
route.
If
the
originated
root,
IPS
address
field
in
the
root
is
filled
with
the
iqv6
address
is
seen
to
the
IPv6
laborers
RS
is
signature.
Ipv4
BB
labels
for
inner
as
IP
message,
root
and
Source
active
ad
Roots
is
seen
through
both
IPv6
VPC
labels
and
ipu4pv
labors
for
similar
house
rules.
M
If
the
IPv6
we
have
Roots
importing
external
completely
exists
in
the
root
is
sent
to
ipvc
exp
neighbors,
otherwise
it
is
seen
to
the
ipv4
pdpc
labels
in
the
reflector
routers.
The
part
of
roots
which
are
received
from
IPv6
speed
label
will
be
reflected
to
other
IPv6
specific
labels.
Another
other
part
of
the
route
which
are
received
from
ipv4
bit
of
Labor
will
be
reflected
to
other
ipv4
PB
labels
next
slide.
Please.
M
So
comments
are
welcome.
We
are
also
seeking
for
working
group.
Adoption
I
think
they
used
to
described
in
the
document
is
clear
and
the
solution
is
very
low
as
an
adoption
request
after
the
last
item
meetings,
but
the
no
response
received
so
I
request.
The
key
in
this
time
and
which
is
a
working
group,
could
give
some
response.
It
would
be
operation.
You
can
give
some
suggestion
or
point
out
the
gaps
for
the
adoption
of
this
document.
Thank
you.
N
Jeffrey
Donald
drop
her
down
from
juniper,
so
indeed
we
have
had
some
discussions
on
the
marianist
I.
Don't
think
we
have
reached
agreement
on
what's
the
best
way
to
address
this,
my
understanding
that
you
have
three
problems
here
in
this
script,
the
first
problem
there
was
another
there's
another
solution,
another
trapped
which
I
presented
in
Las
IHF
as
well
and
I,
requested
for
adoption.
That
draft
covers
many
issues
and
solutions
for.
N
For
symmetrical
related
issues-
and
your
second
problem
does
not
seem
to
be
IPv6
specific,
so
the
the
third
one
is
indeed
IPv6
specific
and
we
was
not
covered
in
other
drafts,
but
going
forward
what's
best
way,
I
think
we
can.
We
should
discuss
more,
but
indeed
I
just
want
to
mention
that
we
also
have
requested
for
adoption
for
the
other
drafts
and
I
have
presented
last
time
and
also
followed
up
with
with
the
with
the
with
the
chairs,
with
their
adoption
request.
N
A
Yeah
we
have
a
lot
of
adoption
requests
at
the
moment.
So
if
you
could
email
the
unicast
the
chairs
to
best
shows
at
least
you
have
thought
that
would
really
help
actually
because
I
think
just
about
every
draft
that
gets
presented
or
asking
for
working
group.
Adoption.
O
Yeah
hi
I'm
swadesh
Agarwal
from
Cisco
Systems.
This
is
a
new
draft.
This
is
for
bgp
extensions
for
srb6
and
mpls
interworking
and
I'm,
presenting
on
the
behalf
of
my
authors.
Next
slide,
please
so
there's
a
spring
draft
which
describes
the
srv6
and
MPS
interworking
architecture
in
the
multi-domain
network,
where
each
domain
run
srv6
and
mpls
independently,
and
that
document
already
had
the
bgp
protocol
extensions.
O
Next
slide,
please
so
we
Define
a
new
tlv
as
it
is
called
sr6
tunnel
for
label
route
with
the
this
is
carried
in
the
bgp
prefixed
attribute
to
Signal.
The
srv6
Sid,
along
with
the
mpls
label,
bound
to
the
bound
to
the
prefix
in
the
nlri,
so
SRC
terminal
tunnel
for
the
label,
route,
tlv,
signals
and
semantics.
O
That
is
push
the
a
label
signal
in
the
nlri
and
perform
H
Dot
N
caps
with
the
destination
as
a
sr66
signal
in
this
new
tlv,
and
this
tlv
is
encoded
exactly
like
srv6
services
tlv
in
the
prefixed
attribute
Define
already
defined
in
RFC
9252
without
transposition
set
Behavior,
which
is
currently
defined
for
this
tlv
is
a
n
dot
DTM,
but
in
future
new
behaviors
may
come
up
next
slide.
Please.
O
This
shows
how
this
tlv
is
carried.
So
we
have
a
Services
running
from
E
10
to
E1,
which
is
I'm
showing
here:
VPN
Services,
the
VPN
label,
and
on
one
we
need
a
reachability
to
E10
low
back.
So
it's
at
our
left
and
the
right
domain
are
mpls
and
the
middle
domain
is
srv6,
so
E10
doesn't
know
anything
about
a
middle
domain.
It's
advertised
the
loopback
in
bgplu,
a
regular
one
with
the
prefix
E10
implicitinal
and
the
next
top
on
the
seven.
O
What
we
do
these
we
allocate
this
set
of
DTM
behavior,
and
we
carry
that
acid
in
the
prefixed
attribute
of
this
new
tlv
type
and
as
well
as
we
carry
the
MPS
label,
which
is
bound
to
the
prefix
a
regularly
like
bgplu
and
the
behavior
is
DTM
and
it
is
C
by
node.
4
and
4
will
do
a
next
top
cell
and
an
advertise
to
E1
as
a
regular
bgplu
update.
O
So
now,
when
the
packet,
which
service
traffic
that
comes
on
E1,
would
be
it's
a
regular
encapsulation
with
the
ABR
label
and
the
bgplu
label
to
E10,
but
on
node
4.
If
you
see
what
it's
doing,
it's
it's
pushing
both
the
it's
doing
a
swap
operation
for
label
for
the
prefix
for
E10.
That
means
16010
as
well
as
it's
doing
H
dot,
end
caps
with
the
DTM
behavior
and
for
DTM
Behavior,
which
is
defined
in
the
spring
graph.
O
It
means
decapsulation
and
lookup
of
look
up
the
label
below
the
header
in
the
mpls
table,
so
that
16010,
which
is
from
the
will,
carry
the
packet
to
the
E10
regularly
next
slide.
Please
so
there's
another
another
case.
We
we
need
to
advertise
SRB
succeed,
and
in
this
case
this,
as
I've
said,
is
bound
to
the
prefix
in
the
nlri
like
mpls
label.
This
is
a
set
for
each
prefix
in
the
nlri.
It
is
carried
in
the
Safi,
it's
a
loop.
O
This
is
this
is
of
the
DPM
Behavior
and
it's
carried
in
Safi
4
R1
I
can
go
to
next
slide.
Please.
So
we
can
see
what
happens.
Is
it's
exactly
same
scenario,
but
we
advertising
E10
in
bgplu,
which
is
received
by
the
Note
7,
but
Note
7
here
allocates
both
the
label
and
srv6
set
bound
to
the
prefix.
That's
important
and
this
document
extends
the
bgp
prefixes
attribute
to
carry
the
this.
This
sit
in
the
srv6
layer,
3
Services,
tlb
Define
in
RFC
9252
with
rp12
and
the
Safi
4.
O
tlv
is
encoded
exactly
like
SRV
services
tlb
in
the
prefixed
attribute
without
transposition,
because
we
are
carrying
both
the
label
and
the
SRV
68.
So
there
is
no
transportation
we
can
do.
Such
an
update
can
be
processed
both
by
the
Legacy
mpls
AVR.
That
means
4
could
be
an
srs6
capable
or
a
legacy.
Also
both
will
take
and
do
the
do
the
relevant
encapsulation
next
slide.
Please
another
case
is
what
can
happen.
O
Is
7
only
supports
the
srv6
Sid
bound
to
the
prefix,
so
it's
not
allocating
the
label
in
this
case,
since
we
can't
use
label
as
Safi
4,
Safi
4
needle
label.
So
what
we
do
is
we
use
a
Safi
one
and
in
that
we
it's
already
defined
in
nine
to
five
RFC
9252
to
carry
a
sr6
sid
for
Safi
one
in
the
prefix
it
attribute.
We
do
exactly
same
procedures,
so
there's
nothing
new.
O
It's
just
a
use
case
showing
how
we
can
achieve
in
case
we
don't
have
a
label
in
the
on
the
border
nodes
of
srv6
domain.
Next
next
slide,
please
yeah.
So
we
will
We
would
like
working
group
to
review
and
provide
comments.
This
is
something
which
is
already
just
a
background.
This
is
already
defined
in
the
it
was
already
defined
in
the
spring
document
we
just
extracted
here.
So
it
was
there
from
last
10
versions.
Here
we
are
presenting
in
the
best
now
a
separate
document.
F
O
F
It
would
be
good
also
if
it's
a
draft
that
you're
modifying
that's
an
rrc
in
IDR
Swedish
it'd
be
best
to
present
it
and
get
some
feedback.
That
way
you
get
the
the
review
that
that,
from
the
original
review,
sure.
G
G
Well,
thanks
for
presenting
this
here
in
best
I
think
it
was.
It
was
needed.
G
I
have
just
one
question
out
of
curiosity,
so
for
the
DPM
Behavior,
you
have
two
cases:
either
binding
only
their
service
six
to
the
prefix
or
srv6
set
plus
the
label
I
wonder
so.
The
latter
is
just
for
migration
purposes
and
then
the
idea
is
to
have
the
just
the.
O
O
K
Hi,
my
name
is
Gian
Mishra
and
I'm
presenting
this
draft.
This
four
drafts
on
behalf
of
co-authors,
so
the
four
drafts
are,
it's
I
I
show
the
first
two
is
related
to
the
IPv6,
only
PE
design,
so
this
is
IPv6
only
key
design
and
then
the
second
draft
is
a
super
set
of
the
first
draft
and
that's
IPv6
OMP
design,
all
sappy.
K
The
next
few
draft
pair
is
the
ipv4
only
P
design
and
then
the
and
then
the
all
safety,
so
I'll
I'll
be
going
over
all
four
graphs
in
this
presentation.
Next
slide,
foreign.
K
Bcp,
it
was
adopted
in
April
of
2021,
so
the
folks
of
this
draft
is
a
proof
of
concept:
testing
DCP
for
vendor
implementations
and
operators
deployment.
So
with
this,
the
ipv
is
only
PE.
Design
supports
Safi
one
two
and
two.
It
was
then
further
updated
to
support
one
two
and
then
Safi
128
and
129.
The
ad
users
from
IP
Design
This.
K
The
the
next
draft,
which
was
mentioned
about
in
the
in
the
first
slide
is,
is
called
it's
the
IPv6
Olympic
design,
but
it's
all
sassy,
so
it's
extensible
to
all
safety,
so
we're
taking
the
same
concept
that
was
applied.
Then
we're
testing
with
it
with
with
the
vcp
use
case
with
the
original
set
of
staffies,
but
now
we're
providing
that
extensibility
with
this
new
draft
to
support
false
happy,
so
the
force
folks
have
just
so.
This
is
basically
a
superset
of
the
first
draft
and
this
one
would
be
standards
track.
K
K
So
what
we're
doing
with
both
of
these
drafts
is
it's
an
alternative
and
and
and
a
BCP,
as
well
as
a
new
standard
that
whenever
you
have
any
type
of
p
c
e,
Peery
or
inner
ASP
to
PE
pairing,
then
now
you're
able
to
use
this
new
new
Paradigm
Shift
option
where
you
actually
have
a
IPv6
only
PE,
so
the
PE
would
actually
get
all
the
NRA
SP
to
P,
peers
or
PE
to
P
peers.
K
They
would,
it
would
be
a
single
V6,
peer
and
you're
you're
being
you
would
be
able
to
carry
it
all.
Safety
and
you'd
still
be
able
to
support
both.
Could
both
data
planes,
so
the
V4
V6
data
plan
are
supported.
But
now
you
don't
have
two
sets
of
peers:
a
set
of
V4
peers
and
aesthetic
V6
peers.
So
there's
a
tremendous
capex
and
Apex
savings,
as
well
as
the
big
savings
with
V4
address
depletion
so
that
that's
a
really
big
one.
With
with
this
design
next
slide.
K
So
with
this
with
this,
designed
with
the
proof
with
the
IPv6,
only
P
design
and
sorry
with
this,
with
the
ipv4,
only
I'm,
sorry
iqv6
only
PE
design
testing,
an
update
that
we
had
is
we're
planning
to
complete
all
the
tests.
The
vendor
testing,
so
Cisco,
Juniper
and
Nokia
were
planning
to
complete
by
the
end
of
this
year.
That's
really
the
Target
that
we're
looking
at
all
of
the
vendors
support,
a
vendor
Pacific
nav
reporting
ipv4
package
without
an
ipv4
address,
so
they
all
support
that
and
that's
that's!
K
That's
a
critical
component
of
the
testing
and
Huawei
is
planning
to
complete
by
2023.
Aristo.
We
don't
have
an
ETA,
but
right
now
we're
we're.
We
have
a
lot
of
focus
on
the
first
three
trying
to
get
that
all
completed
by
The
End
by
the
end
of
the
year.
K
So
the
ipv4
only
PE
design
so
from
ietf,
114
and
I
did
mention
it.
In
the
other
side,
when
I
was
going
over
the
IPv6
only
PD
design,
but
we
we
had
some
feedback
from
the
working
group
during
the
itf-114
on
combining
drafts.
So
in
the
slide
that
I
I
had
just
gone
over
with
the
IPv6
only
PE
design,
the
first
draft
had
been
adopted.
But,
however,
the
second
draft
is
we're
still
progressing
that
draft
and
we're
hoping
for
an
adoption.
K
You
know
queuing
up
for
adoption
call,
however,
because
they
are
because
they've
the
first
draft
had
already
been
adopted.
K
Our
thoughts
are
actually
the
progressive,
separate
the
second
draft
separately
and
not
combine
the
two
drafts,
but
we
would
like
to
see
feedback
from
the
working
group
as
well
as
chairs,
on
combining
those
two
drafts,
given
that
one
draft
has
been
adopted
and
the
other
draft
is
a
new
extensible
drafty,
all
safety
draft
and
whether
we
can
still
whether
it's
possible
to
still
combine
those
two
drafts
and
it
would
save
on
Cycles
on
working
through
an
adoption
call.
So
with
this
draft.
These
both
of
these
drafts
are
new
drafts.
K
So
what
I've
done
is
I've
I
have
already
combined
from
the
feedback
from
ITF
114
I
have
combined
both
of
these
traps,
so
the
V6
only
p-designed
what
I
did
was
I
took
that
draft
and
combined
it
into
the
new
draft,
the
all
safety
draft.
So
now
it's
really
this
all
sassy
draft
that
we
would
be
progressing
forward.
That
would
be
all-encompassing.
K
It
would
Encompass
the
the
proof
of
concept
testing
that
we
would
be
doing
with
with
the
V4
LEP
design
with
safety,
one
two
128
129,
and
then
it
would
also
Encompass
all
safies
the
extensibility,
as
well
as
of
the
next
top
encoding.
So
with
this
track,
it
does
have
an
Ina
code,
Point
allocation
for
a
update
on
next
stop
encoding
and
we'll
go
over
that
in
the
substitute
slide.
Next
slide.
K
This
is
an
important
slide,
as
I
wanted
to
kind
of
key
in
on
the
timeline
for
testing,
as
well
as
the
staffies
and
what
we'll
be
testing
and
then,
as
well
as
the
extensibility
to
all
the
others
happy,
and
that's
really
one
of
the
folks
here,
just
kind
of
making
that
clear
so
in
in
the
in
the
IPv6
only
P
design.
So
we
will
be
testing
safety.
One
128
and
I
have
a
typo
there,
but
Safi
1,
128
and
129..
K
Those
are
the
three
statues
that
are
being
tested
for
both
the
V4
and
EP
design
and
the
V6
only
be
designed
so
that
that's
that's
the
folks
what's
being
tested
for
the
IP
V6
only
P
design,
the
extensibility.
So
here
actually
I
have
a
slight
typo.
It's
supposed
to
be
igv6
only
feed
design,
so
the
support
for
all
safy,
the
Paradigm
Shift.
You
know
so
that
part
of
the
draft
we're
providing
the
folks
on
the
standardization
and
you
know
to
support
all
staffy.
K
However,
we
would
not
be
testing
any
other
safeties
other
than
just
the
one
once
that's
happening,
one
128
and
129,
so
I
just
wanted
to
make
that
clear
and
then
further
testing
related
to
the
all
safety
is
really
deferred
that,
as
operator
decide
to
deploy
staffies
other
than
these
first
three
staffies
to
support
any
of
the
other
zafies
that
they
can
work
with
the
vendors
of
their
choice
as
they're
as
they're
working
to
test
and
deploy
any
of
the
other
safeties.
K
You
know
that
are
that
you
know
that
that
would
be
supported
the
IP
existence.
Only
if
you
decide
the
plan
is,
as
I
had
mentioned
in
the
other
slide
that
we
plan
to
complete
by
the
end
of
the
year
and
the
ipv4
only
PE
design
testing
we
plan
to
start
after
we
finish
the
V6,
only
key
design
testing.
So
we
want
to
get
the
V6
only
pizza
and
get
that
progressed
to
work
with
last
call.
K
Hopefully,
once
we
could
get
all
the
complete
testing
completed,
which
which
we're
we're
on
track
to
complete
the
ipv4,
only
PE
design,
so
this
one
so
the
new.
So
it's
a
new
IPv6
that
ipv
is
only
feeds
on
it.
It
involves
a
new
Next
Top
encoding,
which
we'll
be
testing
using
the
existing
next
stop
encoding.
K
So
with
this
and
we'll
I
have
a
slide
that
actually
kind
of
really
digs
into
this
a
little
more
detail,
but
this
this
the
IPv6
only
if
you
designed
so
since
it
involves
both
a
new
next
stop
encoding,
but
we
have
an
existing
F10,
Next
Top
encoding.
What
we
would
do
is
we
would
be
following
in
in
our
testing.
We
would
be
using
what
exists
with
the
vendors
so
whether
they're
using
an
ipv4,
mapped,
IPv6
address
or
an
ipv
store
address.
K
So
following
the
RFC,
5549
or
8950
next
up,
including
style,
we
wouldn't
test
that
or
if
they
support
the
map
address,
we
would
we
would
test
either
option
we'll
work
with
each
each
of
the
the
vendor
development
teams
to
get
their
support
and
agreement
on
the
change
to
the
RFC
5549
89.50
next
up,
including
style.
So
that
would
be
a
four
byte
ipv4
address
for
safety,
one
two
and
four,
and
then
for
Safi
128
129,
the
Rd
plus
the
Rd
field
of
eight
bytes.
K
Are,
you
know,
set
to
zero,
a
12
byte.
Next,
stop
encoding
standard,
so
it'd
be
a
V4
address,
four
byte
for
one
two
and
four
and
then
128
and
129.
It
would
be
a
12
byte
in
total,
so
including
eight
byte,
with
an
already
zero.
So
once
each
vendor
has
developed
the
new
next
stop
and
trading,
we
would
go
through
and
test
that
new
next
happening,
encoding
method
and
then
progress.
The
drafting
of
RC
next
slide.
K
K
Okay,
all
right,
thank
you.
Let's,
let's
skip
over
to
go
down
to
skip
to
the
next
slide.
K
Yeah
so
I'm
just
gonna
just
Breeze
through
a
couple
of
these
slides.
So
in
this
slide
we
talked
about
the
ipv4
on
AP
exide.
So
in
this
slide
we're
it's
a
V4
address,
but
basically
all
the
semantics
of
an
actual
dual
stacking.
This
is
providing
a
alternative
to
existing
existing
dual
stacking.
But
now
you
have
a
V6
address,
but
all
normal
functionality
that
exists
with
with
your
peering
would
still
would
still
be
the
same.
K
The
V4
V6
forwarding
everything
that
would
normally
happen
on
a
V4,
Next
Top,
the
IPv6
only
P
design
is
exactly
is
a
similar
alternative
to
a
dual
stack
pairing.
But
now
you
know
supporting
all
the
same
functionality
that
you
would
normally
have
a
dual
stacking,
but
now,
without
that
before
address
configured
next
next
slide.
K
So
in
this
slide,
I
wanted
to
go
over
the
next
top
encoding
so
with
the
next
top
encoding
So.
Currently,
today,
there
is
a
where
that,
with
the
IPv6
next
Saturday
next
up
encoding
standardization
change
that
that
we're
proposing
in
in
this
draft.
So
today
you
either
have
a
itv4
mapped
IPv6
address,
or
there
may
be
cases
where
you
have
a
AIP
ipv4
address
so
similar
to
the
RFC
5549
or
8950
next
top
encoding.
A
Silence
so
okay
yeah,
maybe
maybe
just
pause
here
and
then
we'll
take
questions
after
the
two
minutes.
Okay,.
K
K
All
right,
I'm,
just
I'm,
gonna,
wrap
up
and
then
I'll
I'll
take
questions,
I'll
go
ahead,
and
so
so,
basically
in
this
in.
P
Most
of
the
time
when
people
write
apps
right,
they
are
too
abstract.
So
the
section
doesn't
stay
much
more
than
what
the
title
says.
I
think
you
are
making
the
opposite
mistake.
You
are
way
too
detailed
and
my
suggestion
would
actually
be
to
move
the
current
upset
into
the
introduction
and
then
write
a
10
15
line,
abstract
per
draft
on
a
level
level
that
a
technical,
Advanced
person
couldn't
understand.
B
B
Okay,
I
I
will
I'm
sorry
about
that.
I
missed
the
announcement
that
the
period
was
over
but
I'll
send
it
over
the
email.
Thank
you.
Q
M
Q
Too,
yes,.
Q
C
Q
Okay,
so
next
slide,
please.
C
No,
no,
no,
no,
no,
no
I
I
think
kittens
that
there
is
an
audio
issue
with
the
room
now
so
Matthew
I
don't
know
if
Matthew
is
unable
to
to
hear
us
and
we
also
count
irim.
Q
C
So
they
are
currently
checking
if
there
is
something
going
wrong.
Q
Oh
hi,
maybe
I
need
to
check
and
not
just
check
my
network
and
switch
another
laptop.
So
can
I
speak
later
after.
C
The
next
president,
no
it's
not
it's
not
coming
from
you,
it's
really
coming
from
from
the
London
location.
C
Yeah
so
I
I
think
it's
okay
for
everybody
who
are
remote,
but
but
the
local
guys
are
are
not
able
to
hear
us
and
we
are
not
able
to
together.
C
N
N
So,
basically,
in
the
mpos
case,
we
have
the
ECI
labels
advertised
in
the
spz
route
to
to
indicate
the
SPG
route
has
served
two
purposes,
one
to
announce
that
certain
flows
are
redundant
floats.
It
also
carry
the
ESI
labels
so
that
the
egress
P
can
use
to
tell
which
that
which
flow
is
for
from
which
Ingress
PE.
So
in
that
case,
the
egress
speeds
can
can
decide
which
flow
to
accept
and
which
flow
to
discard,
but
in
the
IP
based
data
plane
and
where
the
ESI
labels
are
not
used.
N
So
in
that
case
we
would
just
use
the
IP
Edge
Source
address
of
the
outer
encapsulation
to
tell
which
flow
is
from
which
Ingress
PE
and
so
that
we
know
which
flow
to
accept
in
the
I
actually
to
to
clarify
in
the
IP
based
tunnel.
There
are
two
situations:
one
is
the
vxline
and,
and
then
the
other
one,
and
is
the
genev
and
I
forgot,
which
the
other
one
where
it
does
also
have
the
equivalence
of
the
ESI
label.
N
N
So
in
the
DSi
case,
we
have
a
pair
of
gateways
between
the
two
between
the
data
center
and
data
center
interconnects,
so
the
the
gateways
will
receive
the
both
flows
from
the
Redundant
sources
and
they
will
use
the
existing
procedures
to
to
decide
which
flow
like
the
Gateway
should
accept,
and
after
that,
the
normal
procedure
is
that
only
the
the
destiny
folder
of
those
two
of
those
gateways
will
forward
the
traffic
into
the
next
data
center
or
data
center
interconnect.
N
In
this
case,
we
could
follow
the
same
method
that
only
the
the
Gateway
will
forward,
but
then
we
will
lose
the
protection
and
once
we
pass
the
Gateway
and
so
now
the
new
procedure
here
in
the
data
sender
interconnect
case
is
the
gateways,
regardless
of
the
testing
the
forward
or
not
or
for
the
traffic.
So
now
again,
egress
piece
will
receive
duplicate
floats
and
now
they
need
to
decide
whether
to
accept
traffic
or
not,
and
to
do
that,
the
gateways
will
re-originate
the
SPG
route.
N
Based
on
the
received
SPG
route
to
announce
the
redundancy
case
and
in
case
of
mqos
data
plan
internet
in
the
downstream,
we
can
use
the
again
use
these
ESI
label
that
is
associated
with
that
interconnects
a
virtual
segment.
But
here
the
one
difference
is
that
those
gateways
they
should
have
different
ESL
labels
for
the
same
virtual
need
in
a
segment.
N
So
that's
the
downstream
piece
or
gateways
can
use
to
determine
which
flows
are
from
which
Gateway
and
then
decide
which
flows
to
accept
again
and
that's
the
assuming
when
the
downstream
segment
a
downstream
is
the
mpos
data
playing
or
genev
or
srb6
data
plane.
N
N
There
is
also
a
another
situation
where,
even
when
you
don't
have
the
true
Source
redundancy,
then
the
fact
that
the
post
gateways
are
received
as
the
single
flow
they
can
still
decide
to,
based
on
the
operator's
choice.
They
can
all
send
traffic
to
the
to
the
downstream
whether
it's
a
text,
entry
forward
or
not.
That's
what
we
call
Gateway
introduced
flow
redundancy
and
similarly,
the
as
long
as
the
all
the
gateways
and
all
the
peas
in
the
domain
act.
The
same
follow
the
same
procedure,
the
downstream
peas
or
gateways.
N
N
So
we
have
described
the
procedures
in
the
in
the
draft,
but
we
need
to
add
more
details
on
the
normative
part
of
the
the
draft
we
we
will
add
more
details
to
the
draft.
In
the
meantime,
we
says,
request
feedbacks
and
comments
from
the
working
group.
A
Q
Q
Q
So
when
there
are
multiple
PES
in
English
sites,
we
need
to
designate
one
as
primary
forward
the
traffic
to
the
leaf
PE.
Another
PE
is
chosen
as
a
standby
designated
folder
as
a
backup,
but
primary
and
standby
receive
traffic
from
both
primary
and
standard
ape
receives
the
traffic
from
multicast
source
in
warm
route
standby
scenario,
only
primary
PE
will
fraud
traffic
to
live
PE
in
IFC,
1926
livpi
needs
to
select
primary
and
standby
PE.
However,
problems
such
as
inconsistency
between
the
root
and
leaf
P
will
result
in
slow
fare
over
time.
Q
Therefore,
we
propose
the
idea
that
the
Ingress
PE
should
designate
folders
themselves
to
avoid
the
inconsistency.
Leaf
PE
will
also
accept
all
traffic
from
root
PES.
So
this
time,
instead
of
the
vrrp
method
in
previous
version,
We
propose
our
new
systematic
and
endogenous
procedures
for
Ingress
DF,
election
and
phosphere
over.
We
also
introduced
relevant
attribute
and
Community
next
slide,
please.
Q
Q
The
root
PES
will
be
bundled
together
using
the
multi-chases
protocol,
while
in
active
mode.
The
routers
inside
the
c
network
and
PE
inside
the
Ingress
site
will
be
connected
using
layer.
3
interfaces,
the
Ingress
PE
this
time
of
independent
routers
traffic
from
multicast
Source
will
be
folded
to
all
Ingress
PES.
Therefore,
the
IDF
election
and
negotiation
need
to
be
done
actively
inside
the
Ingress
site.
Next
slide.
Please.
Q
So
we
Define
a
new
community
called
IDF
negotiation
Community,
it
is
carried
in
the
Upstream
multicast
help
routes
and
its
value
will
be
allocated
from
the
bgp
well-known
communities
registry
for
each
negotiation
mode.
The
Edge
routes
will
be
delivered
to
the
root
PES
and
leave
PE
for
root
PE.
It
is
used
to
notify
each
other
peas
that
this
PE
will
participate.
The
IDF
election
and
leaf
P
will
regard
the
community
as
a
symbol
to
install
the
corresponding
p-tunnel
routed
from
the
root
PE
into
the
leaf.
P
is
any
cost
RPF
checklist.
Q
The
BFG
discriminator
attribute
is,
firstly,
defining
IFC
9026
and
we
reduces
the
format
and
we
add
a
new
BFD
mode
type
called
unicast
BFD
session
type.
The
value
is
suggested
to
be
two.
The
BFD
discriminator
attribute
needs
to
carry
a
mandatory,
Source
IP
tlv.
This
time
the
IP
address
of
this
iptlv
will
be
used
to
establish
the
BFD
session
for
failure.
Detection
next
slide,
please
foreign.
Q
So
let
me
introduce
the
election
procedure
in
detail.
Route
B
is,
firstly
originates
the
umh
roots
and
the
negotiation
community
and
the
BFD
discriminator
attribute
are
carried
inside.
The
IP
addresses
the
source.
Iptv
in
vfd
discriminator
attribute
is
the
RPF
interface
of
the
root
PE,
as
shown
in
the
figure.
Q
Q
So
the
root
distinguishers
of
HP
root,
p
e
for
the
same
and
Libyan
are
suggested
to
be
distinct.
When
attribute
to
client
multicast
Source
are
advertised
to
each
root
PE,
they
will
know
each
other's
originator.
Ip
addresses
the
key
procedure
here
is
to
generate
an
ordered
list
of
these
IP
addresses
in
ascending
order,
just
as
shown
in
the
table.
Firstly,
if
for
different
scenarios,
two
methods
are
defined
here.
Firstly,
if
all
c
groups
uses
the
same
primary
and
the
standby
IDF,
the
election
occurs
upon
receiving
all
the
UN
attributes
of
other
pe's.
Q
Q
The
second
method
is
for
the
load
balancing
scenario
this
time.
Different
groups
can
use
different
PES
or
IDF,
and
the
one
C
group
will
have
different
p
as
primary
and
standby
PE.
The
order
list
is
used
here
also,
but
with
different
algorithms.
The
election
occurs
upon
receiving
C
multicast,
drawing
of
the
corresponding
group
from
Leaf
PE
p,
with
index
I
will
be
the
IDF
if
I
equals
to
group
mode
n
after
the
IDF
is
selected,
is
elected.
Q
Q
So
we
have
elected
our
primary
and
standby
IDF
with
above
procedures.
Another
very
important
function
of
warm
route
standby
scenario
is
to
detect
the
failure
of
the
primary
IDF
and
perform
faster
over
this
time.
We
mainly
introduce
our
endogenous
method
for
active
mode
in
order
to
detect
the
failure
of
the
primary
IDF.
The
standby
IDF
need
to
initialize
a
BFD
session.
The
destination
IP
address
of
the
session
is
the
ipf
interface
of
the
primary
IDF.
Q
Therefore,
when
the
IDF
device
or
its
client
facing
link
is
done,
the
standby
P
will
immediately
notice
that
and
take
over
the
primary
IDF
role
to
forward
the
traffic.
When
the
traffic
arrives
at
Leaf
PE,
it
will
not
be
dropped
because
the
p
tunnel
has
already
been
installed
into
its
any
cost.
Rpf
list
next
slide.
Please.
Q
So
finally,
the
data
forwarding
behavior
of
the
route
and
leave
PES
are
discussed
in
active
mode.
If
there
are
local
receivers
at
the
Ingress
site,
they
can
receive
traffic
directly
from
the
corresponding
root
PES,
because
all
root
peas
can
receive
traffic
while
in
a
passive
mode
only
one
of
the
root
PE
can
receive
traffic.
Therefore,
the
p
with
local
receivers
will
install
pitano
towards
the
IDF.
The
traffic
will
be
forwarded
through
the
P
tunnel
and
it
will
only
be
forwarded
towards
the
local
receivers
to
avoid
the
track
traffic
Loop.
Q
Q
A
Okay,
thanks
very
much
I,
don't
see,
I
think
we
should
move
ahead
with
the
final
final
presentation,
which
is
when
then.
N
So
this
is
a
proposal
for
a
newly
extended
Community
to
advertise
group-based
policy.
Id
next
slide.
Please.
N
So
that's
the
Ingress
p
is,
can
can
signal
to
the
egress
PE
in
the
data
package
on
what
group
policy
to
be
applied
at
the
egress
when
the
traffic
arrives
there
by
the
it
could
be
that
the
Ingress
send
the
traffic
to
the
egress
and
after
the
egress
applies
the
policy.
That's
steady,
signaled
in
the
packet
itself,
then
the
decision
is
to
drop
the
package
after
we
have
got
the
packets
of
the
egress.
We
want
to
avoid
the
situation
Next
Step,
please.
N
N
So
this
is
the
proposed
extended
Community
that
encodes
the
group
policy
ID.
It's
a
non-trans
transitive
OPEC
extended
Community.
We
encode
the
policy
ID,
which
is
a
16-bit
value.
There
I
think
we
already
got
a
type
and
subtype
allocated
from
Diana.
This
can
be
carried
by
the
VPN
type,
2
type,
5
and
type
3
routes
in
control
plane,
so
that
the
Ingress
nodes
knows
that
for
which
traffic
will
apply.
The
policy
on
the
Ingress
side
next
slide,
please.
N
So
the
DCI
procedures
will
need
to
be
added.
We
also
request
feedbacks
from
the
working
group.
G
N
C
G
The
the
other
comment
and
and
probably
Matthews
can
clarify,
but
my
understanding
was
that
the
yeah
consensus
was
not
to
extend
a
vxlan
right
but
to
if
there
is
an
extension
to
do
do
it,
probably
in
geneve
or
vxlan
gpe
right,
but
not
vxlan
per
se.
A
Certainly
from
an
nv03
perspective,
the
preference
would
definitely
be
to
to
go
for
and
use
Junaid.
That's
that's
the
kind
of
ITF
Direction,
okay.
N
I
actually
I
just
realized
that
this
draft
is
about
using
Ingress
policy
enforcement
to
replace
the
egress
policy
replacement.
So
it
does,
it
does
not
need
a
mean
that
we
are
Reviving.
That
group
based
policy
draft.
That's
actually
put
into
the
the
policy
ID
into
the
vxn
package
itself.
We
are
we're
proposing
a
different
solution.
A
I
think
one
last
comment
from
wendlin
is
in
the
queue
disappeared.
A
Okay,
all
right
thanks
so
much
everyone
and
I
think
that's
that's
it.