Hi Rajiv,
IMO, I don’t think that “Inferring it from AFI/SAFI per section 3 of RFC4760”
means that there is a format match between the NH field and NLRI, it just says
that there is a relation between the AFI/SAFI and the protocol layer of the NH.
When you know the AFI/SAFI, you can deduce the NH encoding based on the NH
encoding rules defines for this particular AFI/SAFI. RFC4760 doesn’t say that
there is an exact match between NLRI format and NH format.
“The Network Layer protocol associated with the Network Address of
the Next Hop is identified by a combination of <AFI, SAFI>
carried in the attribute.”
Brgds,
Stephane
From: BESS [mailto:[email protected]] On Behalf Of Rajiv Asati (rajiva)
Sent: Thursday, June 27, 2019 13:37
To: Robert Raszuk
Cc: [email protected]; Xiejingrong; Alexander Okonnikov; [email protected];
[email protected]; [email protected]
Subject: Re: [bess] [Softwires] [Idr] Regarding the Next Hop Network Address
coding for IPv4 VPN over IPv6 Core in RFC5549
I agree and sometimes flexibility becomes an unwanted necessity (as is the case
here with option (a)).
IMO, option (b) length based check for NH should be preferred, since it works
for all AFI/SAFIs with an assumption that NH could be one IPv4 or IPv6 prefix.
Very reasonable option.
Option (a) AFI/SAFI based interpretation doesn’t work for all AFI/SAFIs that
don’t distribute non-routing information e.g. policy, capabilities, LS etc.
Cheers,
Rajiv
On Jun 27, 2019, at 6:50 AM, Robert Raszuk
<[email protected]<mailto:[email protected]>> wrote:
> Back to my suggestion: implementation should interpret nexthop RD+IPv4 and
> nexthop IPv4 the same, and interpret nexthop RD+IPv6 and nexthop IPv6 the
> same.
When elements of BGP UPDATE message are being parsed code must know what to
expect. Note that we are dealing here with deployed SAFI 128 for nearly 20
years.
So today there are two ways to know what format of next hop is in MP_REACH:
a) Inferring it from AFI/SAFI per section 3 of RFC4760
or (in addition to the above coarse assumption)
b) Inferring it from the discrete value of next hop length field as defined in
section 3 of RFC5549
Note that if we would be defining new SAFI we can write anything we like to the
rules of constructing the update message. But here again we are dealing with
something which is deployed so sort of operating on the plane in flight.
If implementation can infer next hop type from length we are safe to define all
sections to have next hop length = 16 octets and be done. But if there are some
implementations which would only take AFI/SAFI to check if the next hop is
correct or even further to check if the next hop length is correct then we have
a problem.
/* Btw this notion of next hop length = 32 is bizarre ! I have never seen any
BGP implementation sending two next hops (global IPv6 address followed by link
local IPv6 address) not I am able to find any docs describing how any BGP stack
would handle it. IMHO we should move this 32 next hop length to historic asap.
*/
To the msg from Martin,
> maybe the WG would like to reach a conclusion on how to treat that erratum:
> http://www.rfc-editor.org/errata/eid5738
I would vote to reject the errata. There is no value of stuffing 8 octet of
zeros in the next hop field. If the RFC got defined in 2012 that really means
that most implementations are capable of inferring next hop format from the
length field - which is very good. Accepting the errata would be a step
backwords.
Thx,
R.
On Thu, Jun 27, 2019 at 11:15 AM Xiejingrong
<[email protected]<mailto:[email protected]>> wrote:
Thanks for the RFC historical lessons.
--there was historically some assumption that next hop must be of the same AF
as prefix.
--RFC 2858 says that Next Hop field should match AFI. On the other hand, RFC
4760 says that Next Hop Field should match combination of AFI/SAFI.
--authors of RFC 4364 were trying to make it consistent with 4760.
--Also, drafts of RFC 4364 and RFC 4760 were being developed practically at the
same time period.
The problem is clear, the nexthop field has been inconsistent between different
L3VPN/MVPN scenarios and different implementations in the long history.
<draft-dawra-bess-srv6-services-00> is the latest draft, but it has different
nexthop in section 3.1 to 3.4, in the year 2019.
Back to my suggestion: implementation should interpret nexthop RD+IPv4 and
nexthop IPv4 the same, and interpret nexthop RD+IPv6 and nexthop IPv6 the same.
I think it may be helpful for <draft-dawra-bess-srv6-services-00> to add the
above text, and update RFC4364/4659/4760/5549, to eliminate the worries about
interoperation. ----is there any worries about interoperation ?
Thanks
Jingrong
From: Alexander Okonnikov
[mailto:[email protected]<mailto:[email protected]>]
Sent: Wednesday, June 26, 2019 9:38 PM
To: Robert Raszuk <[email protected]<mailto:[email protected]>>
Cc: UTTARO, JAMES <[email protected]<mailto:[email protected]>>; Xiejingrong
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>
Subject: Re: [Idr] [bess] [Softwires] Regarding the Next Hop Network Address
coding for IPv4 VPN over IPv6 Core in RFC5549
Hi Robert,
Sorry, I was not so precise :-) Of course, RD part in Next Hop is not copied
from RD of NLRI, but zeroed. I was trying to explain why Next Hop field in RFC
4364 and RFC 4659 has format RD:IP (VPNvX address) rather than just IP.
Thank you!
_______________________________________________
Softwires mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/softwires
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
