Dear WG,
Why I do realize that this doc was already approved I would like to ask a
few questions - main reason being is that I am asked to review
draft-ietf-bess-evpn-dpath proposed to extend further D-PATH attribute to
be used with other EVPN route types. This document however is the base for
the evpn-dpath draft.
*Q1: Draft says: *
Gateway PE: An Interworking PE that connects
* two or more distinct domains,* where each domain may be either a
regular domain or a
composite domain. A Gateway PE may establish *either IBGP*
(Internal BGP [RFC4271]) or EBGP (External BGP [RFC4271]) sessions
with peers in the connected domains.
How interconnecting two or more distinct domains can be done with IBGP ?
*Q2:*
Why this document reinvents the wheel and defines a new term* "DOMAIN-ID"*
when semantically and syntactically it is really the very same as
Site-of-Origin encoded as Route Origin (per RFC4360/RFC4364) ? Section 5.1
alludes that Route Origin "does not guarantee detection or prevention of
all potential loops" - has there been discussion on this in BESS ? If so I
would appreciate a link to such discussion.
In fact if not adding purely for informational purposes the ISF_SAFI_TYPE
this entire notion of inventing D-PATH attribute could be completely
avoided with the use of AS-PATH at re-origination as well as propagation of
SoO.
*Q3: *
If the interworking assumes to be also covering IPVPNs (SAFI 128) how do
you deal with a pretty common situations where vanilla RFC4364 domain does
not support D-PATH Attribute ? I do not see in the specification any
mapping of D-PATH content to AS-PATH + SoO at re-origination. Or does this
specification define as normative MUST (at least for the gateways) support
for the D-PATH attribute in order to do any inter-networking ?
Let's note that D-PATH being an optional attribute can be simply dropped by
the other EBGP peer if not recognized. What happens then ? There is no BGP
capability extension defined to indicate to the peer the requirement to
support D-PATH ....
*Q4: Draft says: *
Immediately after applying the Local Preference comparison step
from [RFC4271], the PE MUST remove from consideration *any routes*
that do not have the shortest D-PATH attribute. *Routes* with no
D-PATH attribute are considered to have a D-PATH length of zero.
Please observe that this section aims to modify *BGP Best Path* selection
and not *BGP Best Route* selection steps. So what is being compared is a
set of *paths* for a single route. You can not remove "routes" but you can
remove "paths". Likewise paths which do not contain D-PATH can be
considered like having D-PATH of zero length ... I suppose per this text -
the most preferred as zero would be shortest.
This entire section 6.1 is subject to day one errata :) Section 6.2 as
well ... the draft all together uses terms: route, path, prefix pretty
loosely in more casual way then a BGP specification would deserve.
*Q5: Draft says: *
BGP speakers beyond the "walled garden" that support
D-PATH and receive the attribute in SAFI 1 routes MUST apply the
"treat-as-withdraw" behavior, as described in Section 4 and
consistent with [RFC7606].
Does this really deserve treat-as-withdraw ? If CE receives a healthy
D-PATH attribute which it understands in SAFI 1 can't it simply remove this
attribute from the routes while logging a SYSLOG message ? Is there a real
need to treat-as-withdraw action here ?
Kind regards,
Robert
_______________________________________________
BESS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
