Subject: [Sidrops] Comments on draft-ietf-sidrops-8210bis-01

From: "Borchert, Oliver (Fed)" <[email-masked]>
Date: Wed, 10 Feb 2021 15:32:20 +0000

Hi Randy and Rob,

Reading section “5.12 ASPA PDU” in draft-ietf-sidrops-8210bis-01 (8210-bis01), it mentions the possibility of zero provider ASs.

   ...An ASPA PDU represents one single customer AS

   and zero or more provider ASs for a particular Address Family.

   ...
   The Provider AS Count is the number of Provider Autonomous System
   Number(s) at the end of the PDU, and may be zero or more.
   ...

   The Provider AS Count is the number of 32-bit Provider Autonomous
   System Numbers in the PDU.  There may be none.

   There are zero or more 32-bit Provider Autonomous System Number

   fields; see [I-D.ietf-sidrops-aspa-profile<https://tools.ietf.org/html/draft-ietf-sidrops-8210bis-01#ref-I-D.ietf-sidrops-aspa-profile>].

I noticed though that the ASCII ART of the PDU specifies the field “Provider Autonomous System Number(s)” correctly as 1..N which means the field “Provider AS Count” cannot be zero.

  |                                           |
   +-------------------------------------------+
   |                                           |
   |   Provider Autonomous System Number(s)    |
   |                                           |
   ~-------------------------------------------~
The ASPA Profile (draft-ietf-sidrops-aspa-profile-XX) which is referred to in the text specifies 1..N provider ASs

      ASProviderAttestation ::= SEQUENCE {
           version [0] ASPAVersion DEFAULT v0,
           AFI  AddressFamilyIdentifier,
           customerASID  ASID,
           providerASSET  SEQUENCE (SIZE(1..MAX)) OF ASID }

I believe the wording in 8210-bis01 is still based upon the initial draft-ietf-sidrops-aspa-profile-00. Though since version 01, the draft was updated to require 1..N providers and 8210-bis01 needs to be updated (see below) to reflect these changes.

The proposed modification could be:

Change: /zero or more/one or more/

   ...An ASPA PDU represents one single customer AS

   and one or more provider ASs for a particular Address Family.

   ...

Change: /may be zero/must be one/
   The Provider AS Count is the number of Provider Autonomous System
   Number(s) at the end of the PDU, and must be one or more.
   ...

Change: /may be none/must be one or more/

   The Provider AS Count is the number of 32-bit Provider Autonomous
   System Numbers in the PDU.  There must be one or more.

Change: /zero or more/one or more/

   There are one or more 32-bit Provider Autonomous System Number

   fields; see [I-D.ietf-sidrops-aspa-profile<https://tools.ietf.org/html/draft-ietf-sidrops-8210bis-01#ref-I-D.ietf-sidrops-aspa-profile>].

In Addition I noticed Section 5.1 does not contain any of the new Fields and the “Flags” field does not contain any information on the new “AFI” bit used for ASPA. There are bits and pieces in 5.12 but a more detailed explanation in 5.1 would be great.

Thanks,
Oliver

-----------------------------------------------
Oliver Borchert, Computer Scientist
National Institute of Standards and Technology
(Office) +1.301.975.4856
(GVoice) +1.240.668.4117

---

From: Randy Bush <[email-masked]>
Date: Wed, 10 Feb 2021 12:52:22 -0800

> I believe the wording in 8210-bis01 is still based upon the initial
> draft-ietf-sidrops-aspa-profile-00. Though since version 01, the draft
> was updated to require 1..N providers and 8210-bis01 needs to be
> updated (see below) to reflect these changes.

alexander already dinged me on that and i have a hack.  but your
rigorous detail is much appreciated.

but it seems we are making the mistake of chasing a changing aspa
draft.  i suggest that work on the aspa aspect of 8210bis be postponed
until the aspa draft has been approved by the iesg.

chairs please note

> In Addition I noticed Section 5.1 does not contain any of the new
> Fields and the “Flags” field does not contain any information on the
> new “AFI” bit used for ASPA. There are bits and pieces in 5.12 but a
> more detailed explanation in 5.1 would be great.

sigh

randy

---

From: "Borchert, Oliver (Fed)" <[email-masked]>
Date: Wed, 10 Feb 2021 22:52:27 +0000

In general I agree with you to wait for ASPA being approved. Said that
I believe it is worthwhile to make at least the minor modification 
regarding 0..1 to 1..N count. Adding the fields to 5.1 can definitely
wait but regarding the 1..N modification, this seems to me fairly stable in 
the ASPA draft. 
The alternative throws a lot of questions on why 0 and what would that mean. 
All unnecessary confusion and as it is often in life, once written code 
might not be changed at all and causes future bugs and incompatibilities. 
Especially where the draft is active. 

IMHO reference implementation for testing purpose should not implement
the 0..n approach.

Oliver

    chairs please note

    sigh

    randy

---

From: Randy Bush <[email-masked]>
Date: Wed, 10 Feb 2021 17:00:55 -0800

here is what is in my emacs buffer

< draft-ietf-sidrops-8210bis-01.txt

draft-ietf-sidrops-8210bis.txt >

Network Working Group R. Bush

Network Working Group R. Bush

Internet-Draft IIJ & Arrcus

Internet-Draft IIJ & Arrcus

Updates: 8210 (if approved) R. Austein

Updates: 8210 (if approved) R. Austein

Intended status: Standards Track Dragon Research Labs

Intended status: Standards Track Dragon Research Labs

Expires: August 8, 2021 February 4, 2021

Expires: August 14, 2021 February 10, 2021

The Resource Public Key Infrastructure (RPKI) to Router Protocol,

The Resource Public Key Infrastructure (RPKI) to Router Protocol,

Version 2

Version 2

draft-ietf-sidrops-8210bis-01

draft-ietf-sidrops-8210bis-02

Abstract

Abstract

In order to verifiably validate the origin Autonomous Systems and

In order to verifiably validate the origin Autonomous Systems and

Autonomous System Paths of BGP announcements, routers need a simple

Autonomous System Paths of BGP announcements, routers need a simple

but reliable mechanism to receive Resource Public Key Infrastructure

but reliable mechanism to receive Resource Public Key Infrastructure

(RFC 6480) prefix origin data and router keys from a trusted cache.

(RFC 6480) prefix origin data and router keys from a trusted cache.

This document describes a protocol to deliver them.

This document describes a protocol to deliver them.

This document describes version 2 of the RPKI-Router protocol. RFC

This document describes version 2 of the RPKI-Router protocol. RFC

skipping to change at page 1, line 40 ¶

skipping to change at page 1, line 40 ¶

Internet-Drafts are working documents of the Internet Engineering

Internet-Drafts are working documents of the Internet Engineering

Task Force (IETF). Note that other groups may also distribute

Task Force (IETF). Note that other groups may also distribute

working documents as Internet-Drafts. The list of current Internet-

working documents as Internet-Drafts. The list of current Internet-

Drafts is at https://datatracker.ietf.org/drafts/current/.

Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months

Internet-Drafts are draft documents valid for a maximum of six months

and may be updated, replaced, or obsoleted by other documents at any

and may be updated, replaced, or obsoleted by other documents at any

time. It is inappropriate to use Internet-Drafts as reference

time. It is inappropriate to use Internet-Drafts as reference

material or to cite them other than as "work in progress."

material or to cite them other than as "work in progress."

This Internet-Draft will expire on August 8, 2021.

This Internet-Draft will expire on August 14, 2021.

Copyright Notice

Copyright Notice

Copyright (c) 2021 IETF Trust and the persons identified as the

Copyright (c) 2021 IETF Trust and the persons identified as the

document authors. All rights reserved.

document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal

This document is subject to BCP 78 and the IETF Trust's Legal

Provisions Relating to IETF Documents

Provisions Relating to IETF Documents

(https://trustee.ietf.org/license-info) in effect on the date of

(https://trustee.ietf.org/license-info) in effect on the date of

publication of this document. Please review these documents

publication of this document. Please review these documents

skipping to change at page 3, line 18 ¶

skipping to change at page 3, line 18 ¶

1. Introduction

1. Introduction

In order to verifiably validate the origin Autonomous Systems (ASes)

In order to verifiably validate the origin Autonomous Systems (ASes)

and AS paths of BGP announcements, routers need a simple but reliable

and AS paths of BGP announcements, routers need a simple but reliable

mechanism to receive cryptographically validated Resource Public Key

mechanism to receive cryptographically validated Resource Public Key

Infrastructure (RPKI) [RFC6480] prefix origin data and router keys

Infrastructure (RPKI) [RFC6480] prefix origin data and router keys

from a trusted cache. This document describes a protocol to deliver

from a trusted cache. This document describes a protocol to deliver

them. The design is intentionally constrained to be usable on much

them. The design is intentionally constrained to be usable on much

of the current generation of ISP router platforms.

of the current generation of ISP router platforms.

This document updates [RFC6810].

This document updates [RFC8210].

Section 3 describes the deployment structure, and Section 4 then

Section 3 describes the deployment structure, and Section 4 then

presents an operational overview. The binary payloads of the

presents an operational overview. The binary payloads of the

protocol are formally described in Section 5, and the expected

protocol are formally described in Section 5, and the expected

Protocol Data Unit (PDU) sequences are described in Section 8. The

Protocol Data Unit (PDU) sequences are described in Section 8. The

transport protocol options are described in Section 9. Section 10

transport protocol options are described in Section 9. Section 10

details how routers and caches are configured to connect and

details how routers and caches are configured to connect and

authenticate. Section 12 describes likely deployment scenarios. The

authenticate. Section 12 describes likely deployment scenarios. The

traditional security and IANA considerations end the document.

traditional security and IANA considerations end the document.

skipping to change at page 3, line 43 ¶

skipping to change at page 3, line 43 ¶

1.1. Requirements Language

1.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and

"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and

"OPTIONAL" in this document are to be interpreted as described in BCP

"OPTIONAL" in this document are to be interpreted as described in BCP

14 [RFC2119] [RFC8174] when, and only when, they appear in all

14 [RFC2119] [RFC8174] when, and only when, they appear in all

capitals, as shown here.

capitals, as shown here.

1.2. Changes from RFC 8210

1.2. Changes from RFC 8210

This section summarizes the significant changes between [RFC6810] and

This section summarizes the significant changes between [RFC8210] and

the protocol described in this document.

the protocol described in this document.

o New ASPA PDU type (Section 5.12) added to support

o A new ASPA PDU type (Section 5.12) has added to support

[I-D.ietf-sidrops-aspa-profile].

[I-D.ietf-sidrops-aspa-profile].

o A small section, Section 11, has been added to handle two ROA PDU

o A small section, Section 11, has been added to handle two ROA PDU

race conditions, Break Before Make and Shorter Prefix First.

race conditions, Break Before Make and Shorter Prefix First.

o Protocol version number incremented from 1 (one) to 2 (two).

o The protocol version number incremented from 1 (one) to 2 (two)

and the Section 7 section has been updated accordingly.

2. Glossary

2. Glossary

The following terms are used with special meaning.

The following terms are used with special meaning.

Global RPKI: The authoritative data of the RPKI are published in a

Global RPKI: The authoritative data of the RPKI are published in a

distributed set of servers at the IANA, Regional Internet

distributed set of servers at the IANA, Regional Internet

Registries (RIRs), National Internet Registries (NIRs), and ISPs;

Registries (RIRs), National Internet Registries (NIRs), and ISPs;

see [RFC6481].

see [RFC6481].

skipping to change at page 10, line 20 ¶

skipping to change at page 10, line 20 ¶

changes between the Serial Number specified by the router and the

changes between the Serial Number specified by the router and the

cache's current Serial Number, the cache MUST merge those changes to

cache's current Serial Number, the cache MUST merge those changes to

present the simplest possible view of those changes to the router.

present the simplest possible view of those changes to the router.

In general, this means that, for any particular prefix or router key,

In general, this means that, for any particular prefix or router key,

the data stream will include at most one withdrawal followed by at

the data stream will include at most one withdrawal followed by at

most one announcement, and if all of the changes cancel out, the data

most one announcement, and if all of the changes cancel out, the data

stream will not mention the prefix or router key at all.

stream will not mention the prefix or router key at all.

The rationale for this approach is that the entire purpose of the

The rationale for this approach is that the entire purpose of the

RPKI-Router protocol is to offload work from the router to the cache,

RPKI-Router protocol is to offload work from the router to the cache,

and it should therefore be the cache's job to simplify the change

and it should therefor be the cache's job to simplify the change set,

set, thus reducing work for the router.

thus reducing work for the router.

If the cache does not have the data needed to update the router,

If the cache does not have the data needed to update the router,

perhaps because its records do not go back to the Serial Number in

perhaps because its records do not go back to the Serial Number in

the Serial Query, then it responds with a Cache Reset PDU

the Serial Query, then it responds with a Cache Reset PDU

(Section 5.9).

(Section 5.9).

The Session ID tells the cache what instance the router expects to

The Session ID tells the cache what instance the router expects to

ensure that the Serial Numbers are commensurate, i.e., the cache

ensure that the Serial Numbers are commensurate, i.e., the cache

session has not been changed.

session has not been changed.

skipping to change at page 19, line 23 ¶

skipping to change at page 19, line 23 ¶

| | | |

| | | |

| Flags | zero | Provider AS Count |

| Flags | zero | Provider AS Count |

| | | |

| | | |

| |

| |

| Customer Autonomous System Number |

| Customer Autonomous System Number |

| |

| |

| |

| |

| Provider Autonomous System Numbers |

| |

| |

The ASPA PDU is to support [I-D.ietf-sidrops-aspa-profile]. An ASPA

The ASPA PDU is to support [I-D.ietf-sidrops-aspa-profile]. An ASPA

PDU represents one single customer AS and zero or more provider ASs

PDU represents one single customer AS and one or more provider ASs

for a particular Address Family. Receipt of an ASPA PDU announcement

for a particular Address Family. Receipt of an ASPA PDU announcement

when the router already has an ASPA PDU with the same Customer

when the router already has an ASPA PDU with the same Customer

Autonomous System Number and the same Address Family (see Flags

Autonomous System Number and the same Address Family (see Flags

field), replaces the previous one. This is to avoid a race condition

field), replaces the previous one. This is to avoid a race condition

when a BGP announcement is received between an withdrawn PDU and a

when a BGP announcement is received between an withdrawn PDU and a

new announced PDU. Therfore, the cache SHOULD deliver entire data of

new announced PDU. Therefor, the cache MUST deliver entire data of

an ASPA record in a single ASPA PDU.

an ASPA record in a single ASPA PDU.

The router should only see one ASPA for a particular Customer

Autonomous System Number active at any time. This may place a burden

on the cache to merge multiple ASPA records it has received from the

global RPKI into one ASPA PDU.

The Flags field is defined as follows:

The Flags field is defined as follows:

Bit Bit Name

Bit Bit Name

---- -------------------

---- -------------------

0 Announce/Withdraw (ann == 0, with == 1)

0 Announce/Withdraw (ann == 0, with == 1)

1 AFI (IPv4 == 0, IPv6 == 1)

1 AFI (IPv4 == 0, IPv6 == 1)

2-7 Reserved, must be zero

2-7 Reserved, must be zero

Number(s) at the end of the PDU, and MUST be one or more.

The Customer Autonomous System Number is the 32-bit Autonomous System

The Customer Autonomous System Number is the 32-bit Autonomous System

Number of the customer which signed the PDU. There may be only one

Number of the customer which signed the PDU. There MUST be one and

ASPA for a Customer Autonomous System Number active at any time.

only one ASPA for a Customer Autonomous System Number active in the

router at any time.

System Numbers in the PDU. It MUST be one or greater.

fields; see [I-D.ietf-sidrops-aspa-profile].

fields; see [I-D.ietf-sidrops-aspa-profile].

6. Protocol Timing Parameters

6. Protocol Timing Parameters

Since the data the cache distributes via the RPKI-Router protocol are

Since the data the cache distributes via the RPKI-Router protocol are

retrieved from the Global RPKI system at intervals which are only

retrieved from the Global RPKI system at intervals which are only

known to the cache, only the cache can really know how frequently it

known to the cache, only the cache can really know how frequently it

makes sense for the router to poll the cache, or how long the data

makes sense for the router to poll the cache, or how long the data

are likely to remain valid (or, at least, unchanged). For this

are likely to remain valid (or, at least, unchanged). For this

reason, as well as to allow the cache some control over the load

reason, as well as to allow the cache some control over the load

skipping to change at page 21, line 30 ¶

skipping to change at page 21, line 34 ¶

Caches MUST set Expire Interval to a value larger than either Refresh

Caches MUST set Expire Interval to a value larger than either Refresh

Interval or Retry Interval.

Interval or Retry Interval.

7. Protocol Version Negotiation

7. Protocol Version Negotiation

A router MUST start each transport connection by issuing either a

A router MUST start each transport connection by issuing either a

Reset Query or a Serial Query. This query will tell the cache which

Reset Query or a Serial Query. This query will tell the cache which

version of this protocol the router implements.

version of this protocol the router implements.

If a cache which supports version 1 receives a query from a router

If a cache which supports version N receives a query from a router

which specifies version 0, the cache MUST downgrade to protocol

which specifies version Q < N, the cache MUST downgrade to protocol

version 0 [RFC6810] or send a version 1 Error Report PDU with Error

version Q [RFC6810] or [RFC8210] or send a version 1 Error Report PDU

Code 4 ("Unsupported Protocol Version") and terminate the connection.

with Error Code 4 ("Unsupported Protocol Version") and terminate the

connection.

If a router which supports version 1 sends a query to a cache which

If a router which supports version N sends a query to a cache which

only supports version 0, one of two things will happen:

only supports version C < N, one of two things will happen:

1. The cache may terminate the connection, perhaps with a version 0

1. The cache may terminate the connection, perhaps with a version 0

Error Report PDU. In this case, the router MAY retry the

Error Report PDU. In this case, the router MAY retry the

connection using protocol version 0.

connection using protocol version C.

2. The cache may reply with a version 0 response. In this case, the

2. The cache may reply with a version C response. In this case, the

router MUST either downgrade to version 0 or terminate the

router MUST either downgrade to version C or terminate the

connection.

connection.

In any of the downgraded combinations above, the new features of

In any of the downgraded combinations above, the new features of the

version 1 will not be available, and all PDUs will have 0 in their

hogher version will not be available, and all PDUs will have the

version fields.

negotiated lower version number in their version fields.

If either party receives a PDU containing an unrecognized Protocol

If either party receives a PDU containing an unrecognized Protocol

Version (neither 0 nor 1) during this negotiation, it MUST either

Version (neither 0, 1, nor 2) during this negotiation, it MUST either

downgrade to a known version or terminate the connection, with an

downgrade to a known version or terminate the connection, with an

Error Report PDU unless the received PDU is itself an Error Report

Error Report PDU unless the received PDU is itself an Error Report

PDU.

PDU.

The router MUST ignore any Serial Notify PDUs it might receive from

The router MUST ignore any Serial Notify PDUs it might receive from

the cache during this initial startup period, regardless of the

the cache during this initial startup period, regardless of the

Protocol Version field in the Serial Notify PDU. Since Session ID

Protocol Version field in the Serial Notify PDU. Since Session ID

and Serial Number values are specific to a particular protocol

and Serial Number values are specific to a particular protocol

version, the values in the notification are not useful to the router.

version, the values in the notification are not useful to the router.

Even if these values were meaningful, the only effect that processing

Even if these values were meaningful, the only effect that processing

skipping to change at page 33, line 35 ¶

skipping to change at page 33, line 35 ¶

corruption attacks. As pointed out in Section 9, TCP-AO is the

corruption attacks. As pointed out in Section 9, TCP-AO is the

long-term plan. Protocols which provide integrity and

long-term plan. Protocols which provide integrity and

authenticity SHOULD be used, and if they cannot, i.e., TCP is used

authenticity SHOULD be used, and if they cannot, i.e., TCP is used

as the transport, the router and cache MUST be on the same

as the transport, the router and cache MUST be on the same

trusted, controlled network.

trusted, controlled network.

15. IANA Considerations

15. IANA Considerations

This section only discusses updates required in the existing IANA

This section only discusses updates required in the existing IANA

protocol registries to accommodate version 1 of this protocol. See

protocol registries to accommodate version 1 of this protocol. See

[RFC6810] for IANA considerations from the original (version 0)

[RFC8210] for IANA considerations from the original (version 0)

protocol.

protocol.

All existing entries in the IANA "rpki-rtr-pdu" registry remain valid

All existing entries in the IANA "rpki-rtr-pdu" registry remain valid

for protocol version 0. All of the PDU types allowed in protocol

for protocol version 0. All of the PDU types allowed in protocol

version 0 are also allowed in protocol version 1, with the addition

version 0 are also allowed in protocol version 1, with the addition

of the new Router Key PDU. To reduce the likelihood of confusion,

of the new Router Key PDU. To reduce the likelihood of confusion,

the PDU number used by the Router Key PDU in protocol version 1 is

the PDU number used by the Router Key PDU in protocol version 1 is

hereby registered as reserved (and unused) in protocol version 0.

hereby registered as reserved (and unused) in protocol version 0.

The policy for adding to the registry is RFC Required per [RFC8126];

The policy for adding to the registry is RFC Required per [RFC8126];

skipping to change at page 36, line 29 ¶

skipping to change at page 36, line 29 ¶

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC

2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,

2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,

May 2017, <https://www.rfc-editor.org/info/rfc8174>.

May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8208] Turner, S. and O. Borchert, "BGPsec Algorithms, Key

[RFC8208] Turner, S. and O. Borchert, "BGPsec Algorithms, Key

Formats, and Signature Formats", RFC 8208,

Formats, and Signature Formats", RFC 8208,

DOI 10.17487/RFC8208, September 2017,

DOI 10.17487/RFC8208, September 2017,

<https://www.rfc-editor.org/info/rfc8208>.

<https://www.rfc-editor.org/info/rfc8208>.

[RFC8210] Bush, R. and R. Austein, "The Resource Public Key

Infrastructure (RPKI) to Router Protocol, Version 1",

RFC 8210, DOI 10.17487/RFC8210, September 2017,

<https://www.rfc-editor.org/info/rfc8210>.

16.2. Informative References

16.2. Informative References

[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone

[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone

Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996,

Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996,

August 1996, <https://www.rfc-editor.org/info/rfc1996>.

August 1996, <https://www.rfc-editor.org/info/rfc1996>.

[RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5",

[RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5",

RFC 4808, DOI 10.17487/RFC4808, March 2007,

RFC 4808, DOI 10.17487/RFC4808, March 2007,

<https://www.rfc-editor.org/info/rfc4808>.

<https://www.rfc-editor.org/info/rfc4808>.

End of changes. 24 change blocks.

31 lines changed or deleted

44 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/

---

From: "Borchert, Oliver (Fed)" <[email-masked]>
Date: Thu, 11 Feb 2021 15:01:29 +0000

Great,

Thanks for the quick reply __

Oliver

On 2/10/21, 8:03 PM, "Randy Bush" <[email-masked]> wrote:

---

From: Alexander Azimov <[email-masked]>
Date: Thu, 11 Feb 2021 20:56:17 +0300

Just to keep it in an all-in-one thread: the diff covers all my comments
out-of-the-thread and I'm happy with it. :)

чт, 11 февр. 2021 г. в 18:01, Borchert, Oliver (Fed) <oliver.borchert=
[email-masked]>:

> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops
>

-- 
Best regards,
Alexander Azimov

---

From: "Borchert, Oliver (Fed)" <[email-masked]>
Date: Thu, 18 Feb 2021 16:20:58 +0000

Hi Randy,

While we are adding the ASPA PDU addition to our implementation and applying the modifications of your emacs buffer you posted to the list, we noticed an additional issue that I believe is an error in the draft.

The draft's ASPA PDU specifies the Flags field as follows:
		
     Bit     Bit Name
     ----    -------------------

Whereas bit 0 is coded the opposite for all other PDUs (ann==1, with==0). For instance the Flags description reads:

	Flags:  The lowest-order bit of the Flags field is 1 for an
     		 announcement and 0 for a withdrawal.

This is echoed within the IPv4, IPv6, and Route Key PDUs...

	The lowest-order bit of the Flags field is 1 for an announcement and
	0 for a withdrawal.

Can I assume that the flip of the bit value in the ASPA PDU is a mistake?

PS: Also thanks again for already addressing the previous changes, I was wondering when can we see your emacs buffer being uploaded to the data tracker? 

Thanks,
Oliver

---

From: Randy Bush <[email-masked]>
Date: Thu, 18 Feb 2021 13:13:25 -0800

> Can I assume that the flip of the bit value in the ASPA PDU is a

bug report appreciated!

> PS: Also thanks again for already addressing the previous changes, I
> was wondering when can we see your emacs buffer being uploaded to the
> data tracker?

done

randy

---

From: "Borchert, Oliver (Fed)" <[email-masked]>
Date: Thu, 18 Feb 2021 21:42:29 +0000

Thanks,

Oliver

    bug report appreciated!

    done

    randy