Re: [bess] draft-ietf-bess-evpn-prefix-advertisement-05 comments

["Rabadan, Jorge (Nokia - US/Mountain View)" <[e-mail]>]

OK, just published rev 07 with the latest changes you suggested.
I guess it is ready from your perspective now?

Thank you, Jeffrey, for the detailed review!

Jorge

On 10/19/17, 1:25 PM, "Jeffrey (Zhaohui) Zhang" <[e-mail]> wrote:

    Yup - perhaps add "since the EC could be used for other purposes".
    
    Thanks!
    Jeffrey
    
    > -----Original Message-----
    > From: Rabadan, Jorge (Nokia - US/Mountain View)
    > [mailto:[e-mail]]
    > Sent: Thursday, October 19, 2017 1:54 AM
    > To: Jeffrey (Zhaohui) Zhang <[e-mail]>; draft-ietf-bess-evpn-prefix-
    > [e-mail]; BESS <[e-mail]>
    > Subject: Re: draft-ietf-bess-evpn-prefix-advertisement-05 comments
    > 
    > 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" <[e-mail]> 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:[e-mail]]
    >     > Sent: Tuesday, October 17, 2017 10:24 AM
    >     > To: Jeffrey (Zhaohui) Zhang <[e-mail]>; draft-ietf-bess-evpn-
    > prefix-
    >     > [e-mail]; BESS <[e-mail]>
    >     > 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" <[e-mail]>
    > 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
    >     >
    > 
    >