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 we
since we are discussing that topic,
maybe the WG would like to reach a conclusion on how to treat that erratum:
http://www.rfc-editor.org/errata/eid5738
Thanks
-m
Le 2019-06-27 à 11:15, Xiejingrong a écrit :
> Thanks for the RFC historical lessons.
>
> --there was historically some assumption t
> 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
Please reject this erratum.
RFC6515 is mandatory to require 4/16 bytes nexthop, and mandatory to reject
12/24 bytes nexthop.
Thanks.
Jingrong.
-Original Message-
From: Vigoureux, Martin (Nokia - FR/Paris-Saclay)
[mailto:martin.vigour...@nokia.com]
Sent: Thursday, June 27, 2019 6:37
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
Hi all,
Can the WG reach a conclusion on how to treat that erratum related to RFC5549:
https://www.rfc-editor.org/errata/eid5253
Thanks,
Shunwan
-Original Message-
From: Softwires [mailto:softwires-boun...@ietf.org] On Behalf Of Vigoureux,
Martin (Nokia - FR/Paris-Saclay)
Sent: Thursda
Hi Robert:
I was convinced. All of your points:
(1) No need to relax the check of nexthop as my previous suggestion.
(2) No need to update 5549/6515, and the nexthops defined in
section 3.1 to 3.4 are all right to me now.
(3) if we would be defining new SAFI we can write anything
My vote - Reject.
Justification:
Irrespective if we would reject or accept the erratum implementations must
be able to handle 10 years old RFC so must be able to properly recognize
the next hop to be either of length 16 or 24. (I am putting aside the 32/48
invention).
So that means that next hop
Hi all,
For L3VPN features, there are some differences:
Per RFC4634, the IPv4-VPN routes shall carry the V4 Next-hop, beginning with an
8-octet RD and ending with a 4-octet IPv4 address.
Per RFC4659, the IPv6-VPN routes shall carry the V6 Next-hop, beginning with an
8-octet RD and ending with
Hi folks,
One question about MPLS Label value 3 used in
:
the Label value in any service route NLRI encoding MUST be set to Implicit NULL
[RFC3032].
Label = Implicit NULL
I think the more common use of MPLS Label to represent "invalid" is to use
zero, as in RFC7432 and RFC6556.
Why this doc
Hi,
(co-chair hat off)
I also vote to reject this erratum on the following grounds: The erratum text
was raised as:
Section 6.2 says:
Length of Next Hop Network Address = 16 (or 32)
It should say:
Length of Next Hop Network Address = 24 (or 48)
Notes:
The lengths should include the RD length al
s/6556/8556/g
7432 section 8.2.1
The MPLS label in the NLRI MUST be set to 0.
8556 section 3
The MPLS label field SHOULD be set to zero.
From:Xiejingrong
To:draft-dawra-bess-srv6-servi...@ietf.org
;bess@ietf.org
Date:2019-06-27 19:57:30
Subject:[bess] MPLS Label value 3 in
Hi folks,
One ques
Support.
Thanks,
Anuj Budhiraja
From: BESS on behalf of "stephane.litkow...@orange.com"
Date: Monday, June 17, 2019 at 1:56 AM
To: "bess@ietf.org"
Cc: "bess-cha...@ietf.org"
Subject: [bess] WGLC, IPR and implementation poll for
draft-ietf-bess-evpn-igmp-mld-proxy
Hello Working Group,
T
Hi
I have read this documents several times.
I think it is useful and stable to advance as a solution of L3VPN/EVPN service
over IPv6 networks.
Here are some minor comments:
SRv6 Service SID refers to an SRv6 SID that MAY be associated with
one of the service specific behavior on the advert
14 matches
Mail list logo
