Yes, also since the MAC is not part of the NLRI, some co-authors suggested that.
Do you think we should add?:
“The presence of the Router's MAC EC alone is not enough to indicate the use of
the mac address as the overlay index”
Thx
Jorge
On 10/19/17, 4:37 AM, "Jeffrey (Zhaohui) Zhang" <zzh...@juniper.net> wrote:
Are you saying that the presence of the Router's MAC EC alone is not enough
to indicate the use of the mac address as the overlay index (since the EC was
originally designed for other purpose), but the encoding of ESI and GW IP addr
in the NLRI is enough to indicate that they will be used as overlay index?
That makes sense, but could you clarify that?
Thanks.
Jeffrey
> -----Original Message-----
> From: Rabadan, Jorge (Nokia - US/Mountain View)
> [mailto:jorge.raba...@nokia.com]
> Sent: Tuesday, October 17, 2017 10:24 AM
> To: Jeffrey (Zhaohui) Zhang <zzh...@juniper.net>;
draft-ietf-bess-evpn-prefix-
> advertisem...@tools.ietf.org; BESS <bess@ietf.org>
> Subject: Re: draft-ietf-bess-evpn-prefix-advertisement-05 comments
>
> Hi Jeffrey,
>
> Ah ok, I see what you mean. The label column is basically based on this
text in
> section 3.1:
>
> o The MPLS Label field is encoded as 3 octets, where the high-order
> 20 bits contain the label value. When sending, the label value
> SHOULD be zero if recursive resolution based on overlay index is
> used. If the received MPLS Label value is zero, the route MUST
> contain an Overlay Index and the ingress NVE/PE MUST do recursive
> resolution to find the egress NVE/PE. If the received Label value
> is non-zero, the route will not be used for recursive resolution
> unless a local policy says so.
>
> We do care about the label value since, if it is zero we know for sure,
there
> must be an overlay index. In rows 1/2/3 we do not care, since the overlay
> index indication is based on fields contained in the NLRI.
>
> Thanks.
> Jorge
>
>
> On 10/17/17, 2:18 PM, "Jeffrey (Zhaohui) Zhang" <zzh...@juniper.net>
wrote:
>
> Hi Jorge,
>
> > >
+----------+----------+----------+------------+----------------+
> > > | ESI | GW-IP | MAC* | Label |
Overlay Index |
> > >
|--------------------------------------------------------------|
> > > | Non-Zero | Zero | Zero | Don't Care | ESI
|
> > > | Non-Zero | Zero | Non-Zero | Don't Care | ESI
|
> > > | Zero | Non-Zero | Zero | Don't Care | GW-IP
|
> > > | Zero | Zero | Non-Zero | Zero | MAC
|
> > > | Zero | Zero | Non-Zero | Non-Zero | MAC or
None** |
> > > | Zero | Zero | Zero | Non-Zero |
None(IP NVO)***|
> > >
+----------+----------+----------+------------+----------------+
> > >
> > > The fifth row is like a variation of the fourth row; why
isn't there a
> > > corresponding variation for each of the first three rows? The
following
> > > paragraph mentioned earlier seems to apply to all situations.
> > > [JORGE] in rows 4 and 5, the label value 0 or non-0 has a
meaning. In
> the
> > first
> > > three rows, the label doesn’t have any meaning.
> >
> > Can you elaborate on "the label does not have any meaning",
especially
> for
> > row #2?
> > [JORGE] since an overlay index is used, a recursive resolution is
needed.
> Hence
> > the label is not used to forward packets. “Don’t Care” means a
valid 0 or
> non-
> > zero label value should be ignored.
> >
>
> But Row 4/5 is the same - there is a MAC address as overlay index, so:
>
> - either we "don’t care" the label for row 4/5 and just use overlay
index, or
> - do the same with for rows 1/2/3 as with rows 4/5 and do label based
> forwarding based on local policy
>
> I'm just curious why there is a difference?
>
> Thanks.
> Jeffrey
>
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
