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:[email protected]] > Sent: Tuesday, October 17, 2017 10:24 AM > To: Jeffrey (Zhaohui) Zhang <[email protected]>; draft-ietf-bess-evpn-prefix- > [email protected]; BESS <[email protected]> > 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" <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/bess
