Subject: [Idr] BGP autoconfiguration - draft-minto-idr-bgp-autodiscovery

From: Jeffrey Haas <[email-masked]>
Date: Tue, 8 Mar 2022 01:24:29 -0500

Working Group,

As noted in another thread, we had a late entrant to the BGP
autoconfiguration options.  In an attempt to spur along discussion of the
L3ND proposal, I posted my analysis of that proposal in the same vein as the
discussions we'd had over the course of the various IDR interim meetings and
also as covered in the Appndices of draft-ietf-idr-bgp-autoconf-considerations.[1]

While draft-minto-idr-bgp-autodiscovery[2] had been presented and received
discussion at those interims, similar analysis as that in the design team's
document wasn't done.  The authors of L3ND have asked for similar treatment
for draft-minto.

Below, find my observations on the draft with questions and commentary
intermixed.  I finish this response with my high level analysis and personal
opinion on what these properties accomplish.

-----

Scoping Discussion:

- The proposal starts by noting that it covers more general discovery by
  labeling itself "Service Advertisement".  So, the scope is broader than
  simply BGP autoconfiguration state.
- Single-hop BGP and "loopback address BGP between directly connected
  speakers" are use cases.
- Advertised state is expected to be refreshed; it times out.
- Messages are transmitted peridically.

-----

Protocol properties:

- PDU messages are simple 1-octet type, 2-octet length TLV format.
- Two top-level PDUs defined:
  + Service Advertisement PDU
    * Defines "lifetime" properties of the advertisements.  A "time to live"
      field.
    * A Config sequence TLV.  Compare vs. "BGP Session Protocol State
      Version Number" in the requirements.
    * Authentication TLV. Provides authentication of Service Advertisements.
    * Refresh request TLV.  The only message that attempts to trigger
      another Service advertisement speaker to send messages.

Section 3's TLV format runs somewhat backwards from many RFCs:
- The top level TLV, the SA PDU, is shown last.
- The individual messages in an SA PDU is shown in the middle.
- The generic TLV structure is at the top.

Message ID, is per-message.  It's a little unclear how individual message
IDs within a given SA PDU is helpful.  Should the message ID be per SA PDU
instead?

The individual field definitions should list whether they are mandatory or
optional. 

The Remaining lifetime field is 2-octets.  65k seconds is 1k hours. That's
overly long.  :-) 
- This field should probably be bound to a much lower value for sending.
- Implementations may wish to bound the maximum time they're willing to
  keep.
- Expiry of records might want to interact with Refresh request?

The Refresh request procedure is under-specified.  Since it's the one
field that causes another SA speaker to respond, it should describe:
- What does responding to such a trigger do to the sender's timers for the
  message?
- What sort of rate limiting should be done for responding to the triggers?

Local address TLV:
- The flags and Res fields need the standard "MUST BE ZERO on send, SHOULD
  BE ignored on receipt" text.
- The flags field needs an IANA Considerations section.
- Preference doesn't have any normative text as to how it should be used.
- The contents of sections 4.2.1 and 4.2.2 blend together a bit.

Transport properties:
- Being at the top level of the SA message, the implication is that these
  apply uniformly to the Local Address in that message.

Security TTL:
- Currently specified as a zero-length flag.
- Some GTSM might require 254 rather than 255.  This is inconsistently
  flagged in many pieces of configuration state across IETF.

Security authentication:
- A selector for BGP's authentication mechanism.
- Has TCP-MD5 and TCP-AO
- Need an IANA registry.
- Not bound to any particular address in the Local Address field.  If
  security needs to vary, like any other attribute, it needs to go into a
  separate SA message.

MSS:
- 4 bytes is probably too big. :-)

-----

Protocol behavior:
- The procedure really needs to talk about some possible default timer
  values.
- The procedure indicates that it may refresh more frequently than the
  expiration time.  It should offer advice as to how often it may do so.  An
  example from BGP's holdtime would be to send at least once in 1/3 of that
  interval.  Other options could be to have two timers described: retention
  timer (placed in PDU) and transmit timer (configuration state).
- Fast transmit could use some procedure.  For example, transmit X times in
  Y interval.
  + The refresh TLV provides some ability to do a "pull".
- When specifying "all routers", include the multicast group in the text for
  clarity.
- The procedure argues that you can receive the same state in multiple
  encapsulations; i.e. IPv4 and IPv6.  Some discussion should be given as to
  how to recognize it's the same for puposes of "resetting state".  As an
  example, the Identifier field being the same.
- The transmit procedure supplies some of the "what is mandatory"
  description.  That should be clarified in the TLV descriptions.
- The procedure for handling the identifier vs. IP addresses should be
  clarified.

-----

Misc:
- The document should really remove references to UDP port 179.  IANA hasn't
  assigned this.  It should simply be "TBD".
- Code points should consider starting at 1 rather than 0.  (Jeff's
  opinion.)
- TLVs starting at > 16 should get some discussion as to why that number is
  being used.

-----

Security Properties:
Authentiction TLV for Service Advertisements contain:
<key-id (2-octets), Sequence number (4-octets), Hash/digest (variable)>

(Defined in §4.1.3, procedure in §5.4.)

- The procedure for management of key-ids is left as an opaque detail.  This
  would require implementations to have key id management that includes
  inputs for cipher and shared key.
- The Sequence number field has procedure somewhat similar to BFD's use of
  Sequence number in non-meticulous mode. (See RFC 5880, §4.3+.)
  + I suspect the sequence number comparison features should refer to 
    RFC 1982.  (And the authors of draft-minto may wish to refer to the
    Author list of that RFC. :-)
- The procedure for handling the hash over the PDU is missing many of the
  usual bits of procedure when such hash based mechanisms are done:
  - What value should the PDU's Hash/digest field be set to?
  - Where should the key be placed in the PDU for purposes of calculating
    the hash?
- What are the mandatory hash mechanisms?
  + Is there a benefit to including an authentication type along with just
    the key-id?  Doing so might help simplify procedure by making validation
    always able to determine TLV lengths based on input.
- The receiver procedure needs clarification as to what its desired security
  properties are.  For example, if the receiver expects to receive packets
  with the Authentication TLV, it should require one on receipt.  Otherwise
  there's possibility of an active attacker simply generating Service
  Advertisements without an Authentication TLV.

The mechanism is currently vulnerable to replay attacks.
- This can be somewhat mitigated by reasonable key rotation and limited key
  lifetime.
- Keys really need to be rotated as part of sequence number rollover.
- Sequence number increment procedures need to be bound to prevent certain
  scenarios where a later sequence number has been cached by an attacker and
  used to trigger the "this is a valid next number" and convince listeners
  to ignore the valid but appear to be stale packets.

For fresh starting receivers, they are vulnerable to replay attacks that
keep sequence numbers from synchronizing initially.
+ An epoch/generation value in addition to to the steps above could reduce
  the attack space.  
+ See for example TCP-AO's Sequence Number Extension concept.

The security TLV for the BGP session itself is incomplete.  While 
authentication TLV indicates TCP-AO/TCP-MD5, there needs to be a hint as to
what the connection properties should be.  Key-id, reference to keychain
RFC, etc.  Is ipsec planned for?

-----

Transport Layer Considerations:

- The feature uses (IP) UDP multicast.
- No transport reliability is implied.
- IP fragmentation is implied as the mechanism to deal with packets that are
  too large.
  + Link MTU will thus define how much state can be passed around.
  + Possibility is left in the design (via TBD TLVs) that fragmentation
    might be addressable in the future.

-----

Misc.:

- The document is in need of a spelling and grammar review.  In the interest
  of not cluttering functional analysis when the intent is clear, I will
  send comments on spelling and grammar separately to the authors.

-----

Jeff's read of the proposal:

The protocol is a "shout in the dark" type protocol.  In general, it doesn't
have any particular session layer.  Receivers may, or may not be listening.
For the most part, there is no expectation of a receiver with the expection
of the refresh TLV which is intended to elicit a response from other
senders.  (Compare vs. IGMP/MLDv2.)

Being sessionless, one of its big problems is that the state must be small
enough to fit into link MTU.  This is likely sufficient for many BGP
autodiscovery scenarios, although the question of massive numbers of
messages is raised in discussion about L3ND.

IP fragmentation is offered as a possible method to deal with too-large
messages, but fragmentation is often seen as an attack on IP infrastructure
and in many cases is explicitly filtered.  The draft discussses possible
procedures for extending support via additional TLVs.  If there's intent to
do that, such procedure should be specified early since it would tend to
manifest as one of a common set of prior solutions:
- Split it into a number of additional messages.  Compare vs. PIM Group Set
  Fragmentation.
- Provide a session-based protocol as the extension mechanism.  However,
  that opens attacks against sessions.  Compare possibly vs. LLDPv2.

The SA procedures can be exercised unidirectionally.  This means that a
device may volunteer to have BGP Speakers peer with it, but don't have to
have the rest of the network trying to peer with them.

The timer procedures are underspecified.  Similarlities can be drawn to RIP
and to some extent IGMP/MSDP.

Security procedures for the SA PDU need tightening, as noted above. 

The procedure for keying of BGP sessions is absent and needs text.  Since
the protocol has no privacy, exchanging BGP session keys directly in the
TLVs as cleartext cannot be suggested.

Being sessionless, there is no session infrastructure to be under attack.
The primary ready attacks against the infrastructure are volumetric attacks.
Such attacks beat up on the crypto involved at a cost related to the
strength of the cipher used to protect the validation of the packet.  These
attacks are mitigated, much as similar attacks on TCP-MD5 and TCP-AO, on the
mechanism relying on GTSM.  This restricts such attacks to on-link.

Configuration of security mechanisms are critical for this protocol.  In the
absence of required security, since this protocol advertises state to be
cached for BGP session configuration, unauthenticated messages can be used to:
- Flood the cache of SA state for all listening receivers.
- Cause those receivers to effectively attack hosts at TCP port 179 on the
  local network by trying to BGP peer with them, even if they're not BGP.

-- Jeff (who is up way past his bedtime...)

[1] https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-autoconf-considerations/
[2] https://datatracker.ietf.org/doc/html/draft-minto-idr-bgp-autodiscovery-01

---

From: Minto Jeyananth <[email-masked]>
Date: Fri, 18 Mar 2022 22:41:56 +0000

Jeff,
   Thanks for the review.  At a high level, the SA protocol design trade-off is given to simplicity(the requirement is to just bring up BGP).  Any higher-level complexity can be very well handled by BGP.

Please see inline [minto]. A couple of clarifications inline and will address the rest of the comments in the next version of the draft.  Again thanks for the thoughtful review.

From: Jeffrey Haas <[email-masked]>
Date: Monday, March 7, 2022 at 10:24 PM
To: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: BGP autoconfiguration - draft-minto-idr-bgp-autodiscovery
[External Email. Be cautious of content]

Working Group,

-----

Scoping Discussion:

-----

Protocol properties:

[minto] The message-id per message type will help in debugging per message level.

[minto] will fix it in next version.

[minto] We always run into not enough size.  And 65k is 18hours.

- This field should probably be bound to a much lower value for sending.
- Implementations may wish to bound the maximum time they're willing to
  keep.
[minto] Yes. It is not explicitly mentioned in spec. But a stateless implementation, could simply discard subsequent pdu after it bring up  bgp.

- Expiry of records might want to interact with Refresh request?
[minto] Good suggestion. Will add it in some section in next version.

[minto] Will add a new section on the refresh request and fast send.

Local address TLV:
[minto] Will fix it in next version.

Transport properties:

Security TTL:
- Currently specified as a zero-length flag.
- Some GTSM might require 254 rather than 255.  This is inconsistently
  flagged in many pieces of configuration state across IETF.
[minto] Will fix it in next version.

Security authentication:

MSS:

-----

Protocol behavior:
- The procedure really needs to talk about some possible default timer
  values.
[minto] The preference be automatic. The value might change from fast(order of milliseconds) to steady state value based on local load.

[minto] will add a section in next version.

- When specifying "all routers", include the multicast group in the text for
  clarity.
[minto] will fix it in next version.

[minto] Will fix it next version.

-----

Misc:
[minto] will fix it.

[minto] ok. My initial thought, if a need special tlv code across all message then we can use it.

-minto

-----

Security Properties:

-----

-----

Misc.:

-----

[1] https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-autoconf-considerations/__;!!NEt6yMaO-gk!W_mD4PG04ql6NljpkZMM_DJtZ2k23wBJvMX_qM2LMVXeLiO3F5MbhN3o17TzPQ$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-idr-bgp-autoconf-considerations/__;!!NEt6yMaO-gk!W_mD4PG04ql6NljpkZMM_DJtZ2k23wBJvMX_qM2LMVXeLiO3F5MbhN3o17TzPQ$>
[2] https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-minto-idr-bgp-autodiscovery-01__;!!NEt6yMaO-gk!W_mD4PG04ql6NljpkZMM_DJtZ2k23wBJvMX_qM2LMVXeLiO3F5MbhN2snlIPMw$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-minto-idr-bgp-autodiscovery-01__;!!NEt6yMaO-gk!W_mD4PG04ql6NljpkZMM_DJtZ2k23wBJvMX_qM2LMVXeLiO3F5MbhN2snlIPMw$>

Juniper Business Use Only

---

From: "Susan Hares" <[email-masked]>
Date: Sat, 19 Mar 2022 08:21:03 -0400

Jeff and Minto: 

[WG chair hat off]

[Individual contributor hat on]

I have a few additional questions below. 

Two high level questions: 

1) What non-BGP use are you proposing for your protocol? 

2) What is the normal rate of your timers? 

Thank you for your hard work on this protocol! 

Sue 

From: Idr [mailto:[email-masked]] On Behalf Of Minto Jeyananth
Sent: Friday, March 18, 2022 6:42 PM
To: Jeffrey Haas; [email-masked]
Cc: [email-masked]
Subject: Re: [Idr] BGP autoconfiguration - draft-minto-idr-bgp-autodiscovery

Jeff, 

   Thanks for the review.  At a high level, the SA protocol design trade-off
is given to simplicity(the requirement is to just bring up BGP).  Any
higher-level complexity can be very well handled by BGP. 

Please see inline [minto]. A couple of clarifications inline and will
address the rest of the comments in the next version of the draft.  Again
thanks for the thoughtful review.

From: Jeffrey Haas <[email-masked]>
Date: Monday, March 7, 2022 at 10:24 PM
To: [email-masked] <[email-masked]>
Cc: [email-masked]
<[email-masked]>
Subject: BGP autoconfiguration - draft-minto-idr-bgp-autodiscovery

Working Group,

As noted in another thread, we had a late entrant to the BGP
autoconfiguration options.  In an attempt to spur along discussion of the
L3ND proposal, I posted my analysis of that proposal in the same vein as the
discussions we'd had over the course of the various IDR interim meetings and
also as covered in the Appndices of
draft-ietf-idr-bgp-autoconf-considerations.[1]

-----

Scoping Discussion:

[Sue:  Is there extra state due to the service advertisement? 

[Sue: Please indicate where you find this information in the text.] 

[sue]: What is your normal time frame.  Page 9 does not provide this
information. 

It states:  “A sender should periodically send PDU to refresh the advertised
information before the time expires.”

-----

> - PDU messages are simple 1-octet type, 2-octet length TLV format.

[Sue: Type is 8 bits.  Do you see any future expansion for the non-BGP use
case? ]]

Is the structure of the two PDUs due to the non-BGP use case? 

[minto] The message-id per message type will help in debugging per message
level. 

[Sue: Why are you cycling so much?  What are the timer limits?]

[minto] Yes. It is not explicitly mentioned in spec. But a stateless
implementation, could simply discard subsequent pdu after it bring up  bgp.

[Sue:  It would be helpful to mention this in the specification. 

[Sue] How are you keeping track of the expiry of records in your
implementation? 

Local address TLV:

Transport properties:

Security TTL:

Security authentication:

MSS:
- 4 bytes is probably too big. :-)
[Sue: Do you  need the MSS of 4 bytes for some of your retransmission? }
-----

Protocol behavior:

[minto] The preference be automatic. The value might change from fast(order
of milliseconds) to steady state value based on local load. 

[Sue: Could you explain how the preference might be automatic. 

It would be helpful to explain this in the protocol.]

[Sue:] Does the refresh have a “pull”. 

-----

Misc:

[minto] will fix it.

[minto] ok. My initial thought, if a need special tlv code across all
message then we can use it. 

-minto 

-----

Security Properties:

-----

-----

Misc.:

-----

cached for BGP session configuration, unauthenticated messages can be used
to:

[1]
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-idr-
bgp-autoconf-considerations/__;!!NEt6yMaO-gk!W_mD4PG04ql6NljpkZMM_DJtZ2k23wB
JvMX_qM2LMVXeLiO3F5MbhN3o17TzPQ$
<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-idr-
bgp-autoconf-considerations/__;!!NEt6yMaO-gk!W_mD4PG04ql6NljpkZMM_DJtZ2k23wB
JvMX_qM2LMVXeLiO3F5MbhN3o17TzPQ$> 
[2]
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-mint
o-idr-bgp-autodiscovery-01__;!!NEt6yMaO-gk!W_mD4PG04ql6NljpkZMM_DJtZ2k23wBJv
MX_qM2LMVXeLiO3F5MbhN2snlIPMw$
<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-mint
o-idr-bgp-autodiscovery-01__;!!NEt6yMaO-gk!W_mD4PG04ql6NljpkZMM_DJtZ2k23wBJv
MX_qM2LMVXeLiO3F5MbhN2snlIPMw$>

---

From: Jeffrey Haas <[email-masked]>
Date: Sat, 19 Mar 2022 15:29:27 -0400

Sue,

I'll leave it ot Minto to answer the detailed questions.  I did however want
to remind you that your own question has a similar unaswered question:

> 1) What non-BGP use are you proposing for your protocol? 

Ditto on L3ND.  This was specifically asked about the purpose of the
"encaspulation" information that makes up the bulk of the L3ND procedures.

-- Jeff

---

From: "Susan Hares" <[email-masked]>
Date: Sun, 20 Mar 2022 08:24:52 -0400

Jeff:

I believe that the l3ND text answers your question.   Perhaps you missed
this phrase: 
"While L3ND is designed for the MDC, there are no inherent reasons it could
not run on the WAN." 
(p.  5).  

If you find the same information in draft-minto-idr-bgp-autodiscovery,
please let me know. 

As to encapsulation and nonce, I believe that Randy has answered your
questions.   In answering your detailed questions, I noted differences
between your viewpoint and mine on "session-id" and "nonce".   If Randy has
agreed with you, I'll circle around to discuss the topic with him.   As to
the state machine, I agree that it needs to be added. 

As to security in the data center,  in some MDC - there is security in the
content.   In others,  the BGP auto-configuration may encounter attacks.
See the new article  
Did I leave anything out? 

Cheers, 

Sue 

Amazon Web services (reducing spam attacks) - Nice jump off point to attacks

https://www.spamhaus.org/news/article/794/amazon-web-services-thwarting-spam
-with-a-decade-old-best-practice

This notes that the spam traffic is reducing, and it is a positive article
on cloud services.  
I posted this one instead of a negative article.  

-----Original Message-----
From: Jeffrey Haas [mailto:[email-masked]] 
Sent: Saturday, March 19, 2022 3:29 PM
To: Susan Hares
Cc: 'Minto Jeyananth'; [email-masked];
[email-masked]
Subject: Re: [Idr] BGP autoconfiguration - draft-minto-idr-bgp-autodiscovery

Sue,

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Sun, 20 Mar 2022 13:34:22 -0400

> "While L3ND is designed for the MDC, there are no inherent reasons it could
[...]
> questions.

It is still unclear what the "encapsulation" fields are used for with
respect to BGP discovery.

Please provide an example how this information is leveraged for BGP to
establish its transport session.

WAN may be a useful property, but has been left intentionally out of scope.

-- Jeff

---

From: "Susan Hares" <[email-masked]>
Date: Sun, 20 Mar 2022 14:33:56 -0400

Jeff:

You asked  L3DN is useful where besides the DC.   The WAN or the metro-Rings
are other uses.   Data centers have many types of overlays.   NVO3 had lots
of discussions on that point. 

I am looking for the same level of answer from the draft-minto-*.   Are they
planning to use this for WAN BGP auto-configuration.  

On the encapsulation,  as Randy has said AFI/SAFI.  Consider a data center
with multiple overlays (L2, mpls, L3) and AFI/SAFIs.  Suppose, you want to
use an MPLS interface for an L3 connections.  You might want to select a
specific set of labels for the underlay for L3DN. 

Cheers, Sue 

-----Original Message-----
From: Jeffrey Haas [mailto:[email-masked]] 
Sent: Sunday, March 20, 2022 1:34 PM
To: Susan Hares
Cc: 'Minto Jeyananth'; [email-masked];

[...]

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Sun, 20 Mar 2022 14:39:16 -0400

Sue,

I'm asking a very specific question.  Let me repeat:

On Sun, Mar 20, 2022 at 02:33:56PM -0400, Susan Hares wrote:
> You asked  L3DN is useful where besides the DC.

> planning to use this for WAN BGP auto-configuration.  

I'm not speaking for them.  Minto or Shiva can commment on their draft.

> specific set of labels for the underlay for L3DN. 

That's still not clear.  

How is this used to setup BGP's transport session during discovery?
I.e. how does this impact BGP's TCP SYN and the rest of the session?

-- Jeff

---

From: Randy Bush <[email-masked]>
Date: Sun, 20 Mar 2022 12:45:09 -0700

> I noted differences between your viewpoint and mine on "session-id"
> and "nonce".

lack of braggadocio may have caused jeff to miss that i was trolling

for some of us, a session is an ephemeral thing, and 'nonce' is a quite
appropriate term.

otoh, 'nonce' is what it *is*, while "session id" is how it is *used*

and clearly it caused confusion.  so i renamed it.  trivial.

randy

---

From: Randy Bush <[email-masked]>
Date: Sun, 20 Mar 2022 12:52:02 -0700

> I.e. how does this impact BGP's TCP SYN and the rest of the session?

encaps (clearly a word causing confusion) provide the ip addressing,
hints as to forwarding needed for afis, loopbacks, ...

it would be a mistake to assume the endpoints used for the tls are
everything you need for bgp.  as a trivial example, the tls could be
over ipv4 and a bgp peering could be over ipv6.

perhaps, as you did for s/nonce/session id/, you could suggest a term
less confusing than encapsulation.

randy

---

From: "Susan Hares" <[email-masked]>
Date: Sun, 20 Mar 2022 19:01:38 -0400

Jeff: 

I'm really trying to answer your question - so if I do not understand your
question.  I'll try again. 

The BGP transport sessions can have policy that requires the BGP hello to be
exchanged across a L3 connection running on a particular MPLS interface.
This policy ties down the TCP to a specific L3 connection on a specific L2.5
connection.   This example, show the benefit for some overlay/underlay
deployments.  

How does it impact the BGP FSM?   You will not get an TCP connection up due
to machine policy (it is reject except for the l3 connection attached to
specific MPLS interface).     

I really hope I've understood your question. 

Sue 

-----Original Message-----
From: Jeffrey Haas [mailto:[email-masked]] 
Sent: Sunday, March 20, 2022 2:39 PM
To: Susan Hares
Cc: 'Minto Jeyananth'; [email-masked];

Sue,

That's still not clear.  

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 21 Mar 2022 00:20:38 +0100

Sue,

What encapsulation happens to be used by BGP or for that matter any other
protocol is (and should be) protocol agnostic.

I hope we are not trying here to bind a TCP session to encapsulation X or Y
irrespective of what routing (and given encap orchestration - LDP FEC
binding or SR policy or something else) tells you to do. That would quickly
get very very inconsistent and prone to many failures.

Btw there is no such a thing as "MPLS interface". All MPLS interfaces I
have seen do support IP routing/switching too. And honestly it may be much
better if BGP keeps its transport limited to IPv4 and IPv6 native.

Thx,
Robert

On Mon, Mar 21, 2022 at 12:02 AM Susan Hares <[email-masked]> wrote:

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

---

From: "Susan Hares" <[email-masked]>
Date: Sun, 20 Mar 2022 19:35:34 -0400

Robert: 

The L3DN only requires IPv4 or IPv6 native.  BGP, as a protocol only uses IPv4 or IPv6 native. 

I am comforted to hear that my use case is clearer.   I realize that most MPLS interfaces support IP routing/switching (for about 20 years).  Please note that it is not the protocol BGP that is enforcing the policy,  but the implementation selecting particular interface.    The encapsulation information is optional.   

If you wish to remove this option, it is a useful input to the authors.  

Thanks for your feedback. 

Sue 

From: Robert Raszuk [mailto:[email-masked]] 
Sent: Sunday, March 20, 2022 7:21 PM
To: Susan Hares
Cc: Jeffrey Haas; idr@ietf. org; [email-masked]; Minto Jeyananth
Subject: Re: [Idr] BGP autoconfiguration - draft-minto-idr-bgp-autodiscovery

Sue,

What encapsulation happens to be used by BGP or for that matter any other protocol is (and should be) protocol agnostic. 

I hope we are not trying here to bind a TCP session to encapsulation X or Y irrespective of what routing (and given encap orchestration - LDP FEC binding or SR policy or something else) tells you to do. That would quickly get very very inconsistent and prone to many failures. 

Btw there is no such a thing as "MPLS interface". All MPLS interfaces I have seen do support IP routing/switching too. And honestly it may be much better if BGP keeps its transport limited to IPv4 and IPv6 native. 

Thx,

Robert

 

Jeff: 

Sue 

-----Original Message-----
From: Jeffrey Haas [mailto:[email-masked]] 
Sent: Sunday, March 20, 2022 2:39 PM
To: Susan Hares
Cc: 'Minto Jeyananth'; [email-masked];

Sue,

That's still not clear.  

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 21 Mar 2022 00:46:03 +0100

Sue,

> but the implementation selecting particular interface.

But this is precisely the crux of the perhaps subtle point.

Interesting/modern encapsulations are not (or do not need to be) expressed
as an interface. Neither logical nor physical.

Many thx,
R.

On Mon, Mar 21, 2022 at 12:35 AM Susan Hares <[email-masked]> wrote:

> I am comforted to hear that my use case is clearer.   I realize that most
> MPLS interfaces support IP routing/switching (for about 20 years).  Please
> note that it is not the protocol BGP that is enforcing the policy,  but the
> implementation selecting particular interface.    The encapsulation
> information is optional.
>
>
>
> *From:* Robert Raszuk [mailto:[email-masked]]
> *Sent:* Sunday, March 20, 2022 7:21 PM
> *To:* Susan Hares
> *Cc:* Jeffrey Haas; idr@ietf. org;
> [email-masked]; Minto Jeyananth
> *Subject:* Re: [Idr] BGP autoconfiguration -
> draft-minto-idr-bgp-autodiscovery
>
>
>
> Sue,
>
>
>
> I hope we are not trying here to bind a TCP session to encapsulation X or
> Y irrespective of what routing (and given encap orchestration - LDP FEC

---

From: Minto Jeyananth <[email-masked]>
Date: Mon, 21 Mar 2022 05:15:45 +0000

Susan,

Thanks for the review. Please see inline [minto2]

From: Susan Hares <[email-masked]>
Date: Saturday, March 19, 2022 at 5:21 AM
To: Minto Jeyananth <[email-masked]>, 'Jeffrey Haas' <[email-masked]>, [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: RE: [Idr] BGP autoconfiguration - draft-minto-idr-bgp-autodiscovery
[External Email. Be cautious of content]

Jeff and Minto:
[WG chair hat off]

[minto2] None. Though, technically Link tlv (section 4.2.6) could be treated as non bgp parameter.

2) What is the normal rate of your timers?
[minto2] Protocol required that a sender should refresh advertise state before it expires.
In steady-state refresh, the sender shall refresh the states after the advertised lifetime goes below 2/3 of the time. For e.g if the advertised remaining lifetime is 900 seconds, then it may refresh for every 300 seconds +/- jitter.
In short-live fast-refresh mode, the sender will not consider the advertised remaining lifetime. And sender switches to a rapid timer, typically 250 milliseconds, for a second.

Sue

Jeff,

Working Group,

-----

Scoping Discussion:

[minto2] Please see section 2.

“Receiver could use this information to bootstrap the single hop bgp and/or loopback address bgp between directly connected bgp speakers
“
- Advertised state is expected to be refreshed; it times out.
- Messages are transmitted peridically.
[sue]: What is your normal time frame.  Page 9 does not provide this information.
It states:  “A sender should periodically send PDU to refresh the advertised  information before the time expires.”
[minto2] This is same as point 2). Will add a section on next version.
-----

> - PDU messages are simple 1-octet type, 2-octet length TLV format.
[Sue: Type is 8 bits.  Do you see any future expansion for the non-BGP use case? ]]
[minto2] No. Message type also provide 8 bits. Message is provide logical grouping of TLVs.
[minto2] 2 messages. Base message provide base operation such as timer authentication etc … “
[minto2] excerpt from draft

“The document defines following messages.

1.    SA Base message

The SA Base message is mandatory message and mainly used for the

protocol operation.

2.    BGP service advertisement message

BGP Service Advertisement message provides transport information to

   bring up the bgp session.

“

[minto] Yes. It is not explicitly mentioned in spec. But a stateless implementation, could simply discard subsequent pdu after it bring up  bgp.
[Sue:  It would be helpful to mention this in the specification.
[minto2] Will add it next version. In short this is same as  point 2) response.

- Expiry of records might want to interact with Refresh request?
[minto] Good suggestion. Will add it in some section in next version.
[Sue] How are you keeping track of the expiry of records in your implementation?
[minto2] A stateful implementation keep the peer’s advertised state until the remaining-life expire.

Local address TLV:

Transport properties:

Security TTL:

Security authentication:

MSS:

[minto2] No. will fix it next version

-----

Protocol behavior:

[minto2] Will add timer section in next version.

[minto2]  Refresh request TLV ask for the receiver to resend the pdu,

Thanks

-minto

-----

Misc:

-minto

-----

Security Properties:

-----

-----

Misc.:

-----

---

From: Minto Jeyananth <[email-masked]>
Date: Mon, 21 Mar 2022 05:50:05 +0000

Sue,
draft-minto also supports bgp session using loopback address between directly connected bgp enabled devices.
Draft only supports IPv4/v6 transport endpoints. Label distribution procedure to bring bgp session is not the scope of this draft.

Thanks
-minto

From: Susan Hares <[email-masked]>
Date: Sunday, March 20, 2022 at 11:34 AM
To: 'Jeffrey Haas' <[email-masked]>
Cc: Minto Jeyananth <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Subject: RE: [Idr] BGP autoconfiguration - draft-minto-idr-bgp-autodiscovery
[External Email. Be cautious of content]

Jeff:

Cheers, Sue

-----Original Message-----
From: Jeffrey Haas [mailto:[email-masked]]
Sent: Sunday, March 20, 2022 1:34 PM
To: Susan Hares
Cc: 'Minto Jeyananth'; [email-masked];

[...]

-- Jeff

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 21 Mar 2022 04:05:02 -0400

Minto: 

Does your work apply to some work outside the data center work? 

Thanks, 

Sue 

From: Idr [mailto:[email-masked]] On Behalf Of Minto Jeyananth
Sent: Monday, March 21, 2022 1:50 AM
To: Susan Hares; 'Jeffrey Haas'
Cc: [email-masked]; [email-masked]
Subject: Re: [Idr] BGP autoconfiguration - draft-minto-idr-bgp-autodiscovery

Sue,

draft-minto also supports bgp session using loopback address between
directly connected bgp enabled devices.

Draft only supports IPv4/v6 transport endpoints. Label distribution
procedure to bring bgp session is not the scope of this draft. 

Thanks

-minto 

Cc: Minto Jeyananth <[email-masked]>, [email-masked] <[email-masked]>,

Jeff:

Cheers, Sue

-----Original Message-----
From: Jeffrey Haas [mailto:[email-masked]]
Sent: Sunday, March 20, 2022 1:34 PM
To: Susan Hares
Cc: 'Minto Jeyananth'; [email-masked];

[...]

-- Jeff

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 21 Mar 2022 04:54:55 -0400

Minto:

I see you answered the question regarding other uses (based on Link TLV). 

What scenarios have you tested the timers in ? 

Was it a test lab?  Did you have any other traffic on the link. 

Thanks for the response. 

Sue 

From: Idr [mailto:[email-masked]] On Behalf Of Minto Jeyananth
Sent: Monday, March 21, 2022 1:16 AM
To: Susan Hares; 'Jeffrey Haas'; [email-masked]
Cc: [email-masked]
Subject: Re: [Idr] BGP autoconfiguration - draft-minto-idr-bgp-autodiscovery

Susan,

From: Susan Hares <[email-masked]>
Date: Saturday, March 19, 2022 at 5:21 AM
To: Minto Jeyananth <[email-masked]>, 'Jeffrey Haas' <[email-masked]>,
[email-masked] <[email-masked]>
Cc: [email-masked]
<[email-masked]>
Subject: RE: [Idr] BGP autoconfiguration - draft-minto-idr-bgp-autodiscovery

Jeff and Minto: 

[WG chair hat off]

[minto2] None. Though, technically Link tlv (section 4.2.6) could be treated
as non bgp parameter.  

[minto2] Protocol required that a sender should refresh advertise state
before it expires.

In steady-state refresh, the sender shall refresh the states after the
advertised lifetime goes below 2/3 of the time. For e.g if the advertised
remaining lifetime is 900 seconds, then it may refresh for every 300 seconds
+/- jitter. 

In short-live fast-refresh mode, the sender will not consider the advertised
remaining lifetime. And sender switches to a rapid timer, typically 250
milliseconds, for a second.    

Sue 

 

Jeff, 

 

Working Group,

-----

Scoping Discussion:

“Receiver could use this information to bootstrap the single hop bgp and/or
loopback address bgp between directly connected bgp speakers

“ 

-----

[minto2] No. Message type also provide 8 bits. Message is provide logical
grouping of TLVs.  

[minto2] 2 messages. Base message provide base operation such as timer
authentication etc … “

[minto2] Will add it next version. In short this is same as  point 2)
response. 

[minto2] A stateful implementation keep the peer’s advertised state until
the remaining-life expire. 

Local address TLV:

Transport properties:

Security TTL:

Security authentication:

MSS:

-----

Protocol behavior:

 
Thanks 
-minto 

-----

Misc:

[minto] will fix it.

-minto 

-----

Security Properties:

-----

-----

Misc.:

-----

[1]

---

From: Minto Jeyananth <[email-masked]>
Date: Mon, 21 Mar 2022 20:24:26 +0000

Susan,
    We tested loopback bgp session and link bgp session in lab.
    With initial fast-refresh and refresh-request bgp sessions are coming up very quickly.
   If the concern is UDP reliability, then Im aware of BFD and LDP-discovery running in production for years.

Thanks
-minto

Date: Monday, March 21, 2022 at 1:55 AM

Minto:

Thanks for the response.

Sue

Susan,

Jeff and Minto:
[WG chair hat off]

Sue

Jeff,

Working Group,

-----

Scoping Discussion:

1.    SA Base message

protocol operation.

“

Local address TLV:

Transport properties:

Security TTL:

Security authentication:

MSS:

-----

Protocol behavior:

Thanks

-minto

-----

Misc:

-minto

-----

Security Properties:

-----

-----

Misc.:

-----

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 22 Mar 2022 07:39:25 -0400

Minto: 

Thank you for the details from your earlier tests. 

Details on your tests and the timings will help during our adoption process.

UDP reliability – for LDP-Discovery is one of the reasons for questions.  

If you could bring out specifics, it helps the discussion of reliable
transport/unreliable.  

Thanks! 

Cheers, Sue 

Sent: Monday, March 21, 2022 4:24 PM

Susan,

    With initial fast-refresh and refresh-request bgp sessions are coming up
very quickly.

   If the concern is UDP reliability, then Im aware of BFD and LDP-discovery
running in production for years.  

Thanks 

-minto 

Minto:

Thanks for the response. 

Sue 

 

Susan,

Jeff and Minto: 

[WG chair hat off]

 

Sue 

 

Jeff, 

 

Working Group,

-----

Scoping Discussion:

“ 

-----

Local address TLV:

Transport properties:

Security TTL:

Security authentication:

MSS:

-----

Protocol behavior:

 
Thanks 
-minto 

-----

Misc:

[minto] will fix it.

-minto 

-----

Security Properties:

-----

-----

Misc.:

-----

[1]

---

From: Minto Jeyananth <[email-masked]>
Date: Tue, 22 Mar 2022 23:28:22 +0000

Susan,

Following are timers used in the implementation and lab testing.
   Remaining-life time is 900 seconds and the transmit interval is 300 seconds.
   In fast-refresh mode (after the linkup/restart) reaming-life time 900 seconds and transmit interval 250 milliseconds for a second.

LDP has 2 keepalives.

  1.  UPD based hello for Discovery and neighbor liveness
  2.  TCP-based keepalive for session liveness (similar to BGP)

do we need tighter intervals after the discovery if liveness is not required?

Thanks
-minto

Date: Tuesday, March 22, 2022 at 4:39 AM

Minto:

If you could bring out specifics, it helps the discussion of reliable transport/unreliable.

Thanks!

Cheers, Sue

Susan,

Thanks
-minto

Minto:

Thanks for the response.

Sue

Susan,

Jeff and Minto:
[WG chair hat off]

Sue

Jeff,

Working Group,

-----

Scoping Discussion:

1.    SA Base message

protocol operation.

“

Local address TLV:

Transport properties:

Security TTL:

Security authentication:

MSS:

-----

Protocol behavior:

Thanks

-minto

-----

Misc:

-minto

-----

Security Properties:

-----

-----

Misc.:

-----

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 23 Mar 2022 06:40:18 -0400

Minto: 

This is a good question to ask to operators and deployment. 

Sue 

Sent: Tuesday, March 22, 2022 7:28 PM

Susan,

   Remaining-life time is 900 seconds and the transmit interval is 300
seconds.  

   In fast-refresh mode (after the linkup/restart) reaming-life time 900
seconds and transmit interval 250 milliseconds for a second.

LDP has 2 keepalives. 

do we need tighter intervals after the discovery if liveness is not
required?  

Thanks 

-minto  

Minto: 

Thanks! 

Cheers, Sue 

 

Susan,

Thanks 

-minto 

Minto:

Thanks for the response. 

Sue 

 

Susan,

Jeff and Minto: 

[WG chair hat off]

 

Sue 

 

Jeff, 

 

Working Group,

-----

Scoping Discussion:

“ 

-----

Local address TLV:

Transport properties:

Security TTL:

Security authentication:

MSS:

-----

Protocol behavior:

 
Thanks 
-minto 

-----

Misc:

[minto] will fix it.

-minto 

-----

Security Properties:

-----

-----

Misc.:

-----

[1]