Subject: Re: [Idr] [[email-masked]: I-D Action: draft-haas-idr-extended-experimental-00.txt]

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Tue, 1 Nov 2016 16:56:59 +0000

Jeff,

This is good and I support adoption, should you ask for it.
It should fix the problem.

Thanks,
Jakob.

> -----Original Message-----
> From: Idr [mailto:[email-masked]] On Behalf Of Jeffrey Haas
> Sent: Monday, October 31, 2016 1:55 PM
> To: [email-masked]
> Subject: [Idr] [[email-masked]: I-D Action: draft-haas-idr-extended-experimental-00.txt]
> 
> IDR,
> 
> There's a larger conversation to be had about proper stewardship and use of
> code points of all sorts, but path attributes have our attention for the
> moment.
> 
> A quick draft for consideration and to motivate discussion.
> 
> -- Jeff
> 
> P.S. I'm sure there's a number of rough edges in this.  I knocked it off in
> less than two hours after not enough sleep.
> 
> ----- Forwarded message from [email-masked] -----
> 
> Date: Sun, 30 Oct 2016 07:53:04 -0700
> From: [email-masked]
> To: [email-masked]
> Subject: I-D Action: draft-haas-idr-extended-experimental-00.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
>         Title           : Extended Experimental Path Attributes for BGP
>         Author          : Jeffrey Haas
> 	Filename        : draft-haas-idr-extended-experimental-00.txt
> 	Pages           : 7
> 	Date            : 2016-10-30
> 
> Abstract:
>    BGP's primary feature extension mechanism, Optional-Transitive Path
>    Attributes, has proven to be a successful mechanism to permit BGP to
>    be extended.  In order to ease various issues during the development
>    of new BGP features, this document proposes an extended experimental
>    path attribute to carry prototype features.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-haas-idr-extended-experimental/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-haas-idr-extended-experimental-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> ----- End forwarded message -----
> 
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Peter Hessler <[email-masked]>
Date: Tue, 1 Nov 2016 18:04:14 +0100

same and same.

if adopted by the WG, I'd be interested in tightening it up a bit more
but that can be handled then.

On 2016 Nov 01 (Tue) at 16:56:59 +0000 (+0000), Jakob Heitz (jheitz) wrote:
:Jeff,
:
:This is good and I support adoption, should you ask for it.
:It should fix the problem.
:
:Thanks,
:Jakob.
:
:
:> -----Original Message-----
:> From: Idr [mailto:[email-masked]] On Behalf Of Jeffrey Haas
:> Sent: Monday, October 31, 2016 1:55 PM
:> To: [email-masked]
:> Subject: [Idr] [[email-masked]: I-D Action: draft-haas-idr-extended-experimental-00.txt]
:> 
:> IDR,
:> 
:> There's a larger conversation to be had about proper stewardship and use of
:> code points of all sorts, but path attributes have our attention for the
:> moment.
:> 
:> A quick draft for consideration and to motivate discussion.
:> 
:> -- Jeff
:> 
:> P.S. I'm sure there's a number of rough edges in this.  I knocked it off in
:> less than two hours after not enough sleep.
:> 
:> ----- Forwarded message from [email-masked] -----
:> 
:> Date: Sun, 30 Oct 2016 07:53:04 -0700
:> From: [email-masked]
:> To: [email-masked]
:> Subject: I-D Action: draft-haas-idr-extended-experimental-00.txt
:> 
:> 
:> A New Internet-Draft is available from the on-line Internet-Drafts directories.
:> 
:> 
:>         Title           : Extended Experimental Path Attributes for BGP
:>         Author          : Jeffrey Haas
:> 	Filename        : draft-haas-idr-extended-experimental-00.txt
:> 	Pages           : 7
:> 	Date            : 2016-10-30
:> 
:> Abstract:
:>    BGP's primary feature extension mechanism, Optional-Transitive Path
:>    Attributes, has proven to be a successful mechanism to permit BGP to
:>    be extended.  In order to ease various issues during the development
:>    of new BGP features, this document proposes an extended experimental
:>    path attribute to carry prototype features.
:> 
:> 
:> 
:> The IETF datatracker status page for this draft is:
:> https://datatracker.ietf.org/doc/draft-haas-idr-extended-experimental/
:> 
:> There's also a htmlized version available at:
:> https://tools.ietf.org/html/draft-haas-idr-extended-experimental-00
:> 
:> 
:> Please note that it may take a couple of minutes from the time of submission
:> until the htmlized version and diff are available at tools.ietf.org.
:> 
:> Internet-Drafts are also available by anonymous FTP at:
:> ftp://ftp.ietf.org/internet-drafts/
:> 
:> _______________________________________________
:> I-D-Announce mailing list
:> [email-masked]
:> https://www.ietf.org/mailman/listinfo/i-d-announce
:> Internet-Draft directories: http://www.ietf.org/shadow.html
:> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
:> 
:> ----- End forwarded message -----
:> 
:> _______________________________________________
:> Idr mailing list
:> [email-masked]
:> https://www.ietf.org/mailman/listinfo/idr
:
:_______________________________________________
:Idr mailing list
:[email-masked]
:https://www.ietf.org/mailman/listinfo/idr

-- 
You are here:
		***
		***
	     *********
	      *******
	       *****
		***
		 *

		 But you're not all there.

---

From: Jared Mauch <[email-masked]>
Date: Tue, 1 Nov 2016 13:10:59 -0400

I’m for adopting this draft as well.

I would like to clean up the security text, as there is a lot of history behind the section 6 text:

 - snip -

6.  Security Considerations

   This document does not introduce any new security considerations into
   the BGP-4 protocol.  While the injection of unknown or badly
   formatted Optional-Transitive Path Attributes has been and remains an
   issue impacting the stability of the Internet, this proposal doesn't
   increase exposure to that issue.  It is rather expected that this
   proposal helps remediate the accidental attack surface that
   incremental BGP protocol work exposes to the Internet at large.
 - snip -

I believe it should acknowledge that in the pre-7606 world the handling
was as defined but subsequently considered harmful and with 7606 covers
the risks from this document.  Simply put, striking the text after the first
paragraph and saying the handling in 7606 covers the risk SHOULD be
sufficient.

- Jared

> On Nov 1, 2016, at 1:04 PM, Peter Hessler <[email-masked]> wrote:
> 
> same and same.
>

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 1 Nov 2016 13:34:14 -0400

> I would like to clean up the security text, as there is a lot of history behind the section 6 text:

Feel free to suggest patches:

https://github.com/jhaas-pfrc/extended-experimental

> paragraph and saying the handling in 7606 covers the risk SHOULD be

Time constraints aside, I thought a bit about this as I was scribbling up a
quick security section.  I think it might make sense to do some level of
brief overview of the issues RFC 7606 addressed in prior sections as part of
the motivation of why we need a bit better sandboxing of early work.
Section 1 covers this to some extent.  However, I'm not sure it belongs in
the considerations for this document.

-- Jeff

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 01 Nov 2016 18:38:30 +0000

> A quick draft for consideration and to motivate discussion.

this is an interesting approach and I like it.  Despite the warnings in
the document, vendors are likely to want to do vendor-specific things on
a permanent basis, but this is probably unavoidable and not necessarily
a bad thing either - there are plenty of other situations where
vendor-specific attributes are used to good effect.

I'd like to see this idea progress.

Nick

---

From: heasley <[email-masked]>
Date: Tue, 1 Nov 2016 18:45:22 +0000

> I'd like to see this idea progress.

perhaps encouraging its use for vendor-specific stuff isnt a bad idea.

Support adoption.

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 1 Nov 2016 14:58:00 -0400

> vendor-specific attributes are used to good effect.

As I mentioned, discussion. :-)

One of the general issues with vendor code spaces is that it *does* motivate
vendor-specific work.  That's not necessarily a bad thing in the general
case, but when we talk BGP we have to have a firm focus toward what the
global implications of such a thing means.

The document attempts to setup the expectation of filterability.  Right now,
path attribute filtering as a general practice is hazardous to the
incremental deployment of features on expects to work across the global
Internet.  

A feature such as this one, perhaps extended with a per-attribute form of
draft-ietf-idr-bgp-attribute-announcement along with enough information to
figure out when filtering wasn't done could provide some safety.

The related changes to this proposal would be to simply add the 4-octets of
the attribute announcement scoping and potentially the attaching AS.
However, given even such vendor features are likely to need to work in an
inter-as fashion, generating scopes of containment become tricky.

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 1 Nov 2016 15:00:30 -0400

> perhaps encouraging its use for vendor-specific stuff isnt a bad idea.

FWIW, I'm not currently asking for adoption.  But I'm happy to take this
proposal forward after WG discussion.  

-- Jeff (just to suppress the +1 / -1 storm for now)

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 2 Nov 2016 03:20:37 +0000

Hi Jeff, 

Thanks for uploading this draft, recently I also had some relevant discussion with people offline. Other protocols such as LDP already provide the mechanism for vendor specific extension, and several features have been developed based on that. Maybe it is the time to discuss whether similar mechanism is also needed in BGP, so I think this draft is quite useful. 

Some quick comments about the current draft:

1. In introduction, it describes the consequence of conflicting attribute parsing error according to RFC 4271, while the consequence according to RFC 7606 is less disruptive, it may also be described here, which is either discarding the attribute or treating the update as withdraw. 

2. In the TLV of Extended Experimental Attribute, several fields are further defined after the "Implementor IANA Private Enterprise Number" field, while many implementers may follow this design under their Private enterprise number, the mechanism chosen in LDP may also be considered, in which the format of data after the Length and vendor-ID field are vendor-dependent. 

3. As the Extended Experimental Attribute can contain a series of TLVs, is it possible that TLVs belonging to different vendors, or TLVs of different features are carried in this attribute? If this is the case, further specification about the processing of unrecognized TLVs and the error handling would be needed. 

Best regards,
Jie

> Sent: Tuesday, November 01, 2016 4:55 AM
> To: [email-masked]
> Subject: [Idr] [[email-masked]: I-D Action:
> draft-haas-idr-extended-experimental-00.txt]
> 
> IDR,
> 
> code points of all sorts, but path attributes have our attention for the moment.
> 
> P.S. I'm sure there's a number of rough edges in this.  I knocked it off in less than
> two hours after not enough sleep.
> 
> Internet-Draft directories: http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 2 Nov 2016 17:14:46 +0800

Hello,

A new version of  draft-li-idr-congestion-status-extended-community has been submitted for the coming meeting. Your comments are welcomed.

Congestion status extended community is introduced in this document to carry the link congestion status, especially for the exit link of one AS, to other BGP speakers. Some applications, such as traffic steering, can get benifits from the link congestion status information. 

 The IETF datatracker status page for this draft is:
 https://datatracker.ietf.org/doc/draft-li-idr-congestion-status-extended-community/ 

 There's also a htmlized version available at:
https://tools.ietf.org/html/draft-li-idr-congestion-status-extended-community-03 

Best Regards,

[email-masked]

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 2 Nov 2016 09:53:52 -0400

Jie,

> 1. In introduction, it describes the consequence of conflicting attribute parsing error according to RFC 4271, while the consequence according to RFC 7606 is less disruptive, it may also be describ…

Thanks for the comment.  Since I've had a similar comment from others on the
list, a little more text here may be appropriate.  However, I'm trying to
avoid inserting too much of RFC 7606's motivation in here.

> 2. In the TLV of Extended Experimental Attribute, several fields are further defined after the "Implementor IANA Private Enterprise Number" field, while many implementers may follow this design und…

Looking at RFC 5036 section 3.6.1.1, I think there's actually good
similarity:
- the LDP vendor-type corresponds to the Implementor Feature Code Point
  Number.  LDP restricts this to one 255 values, which is perhaps a bit
  small.
- The LDP vendor-private Vendor ID uses an IEEE namespace.  I've chosen to
  use an IANA Private Enterprise Number for easy entry into this feature.
  IEEE charges (I believe) for their ID where IANA will give one out to any
  who ask for free.
- The LDP vendor-private field does *not* have a version field.  While it is
  arguable that a given vendor may choose to populate a portion of their
  internal PDU with versioning information, I believe it is strongly
  worthwhile to make this part of the PDU.  We've seen too many issues in
  BGP with regard to versioning issues of features in development to not
  cause the implementor to think about this as a fundamental piece of the
  feature.
- The LDP vendor-private field *does* contain bits related to what to do if
  the field is not understood (U-bit).  Since that behavior causes
  notifications, I'm not sure it's in the spirit of RFC 7606 for BGP.
- The LDP vendor-private F-bit does have somewhat the semantics of a scoping
  bit as has been discussed somewhat earlier in the thread.

> 3. As the Extended Experimental Attribute can contain a series of TLVs, is it possible that TLVs belonging to different vendors, or TLVs of different features are carried in this attribute? If this…

There are two intents within the draft:
- If you want to use this attribute, you MUST configure something permitting it.
- Filtering is strongly encouraged.

Currently this draft is tailored toward experiments and development, not
long term deployment of features.  While the conversation is starting to
move toward using this as a generic vendor-specific PA replacement, that's
not the intent of the draft currently.

-- Jeff

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 3 Nov 2016 09:38:21 +0000

Hi Jeff, 

> From: Jeffrey Haas [mailto:[email-masked]]
> Sent: Wednesday, November 02, 2016 9:54 PM
> To: Dongjie (Jimmy) <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Idr] [[email-masked]: I-D Action:
> > Thanks for uploading this draft, recently I also had some relevant discussion
> with people offline. Other protocols such as LDP already provide the mechanism
> for vendor specific extension, and several features have been developed based
> on that. Maybe it is the time to discuss whether similar mechanism is also needed
> in BGP, so I think this draft is quite useful.
> >
> > 1. In introduction, it describes the consequence of conflicting attribute parsing
> error according to RFC 4271, while the consequence according to RFC 7606 is less
> disruptive, it may also be described here, which is either discarding the attribute
> or treating the update as withdraw.
> 
> list, a little more text here may be appropriate.  However, I'm trying to avoid
> inserting too much of RFC 7606's motivation in here.

Understood. As you said, a little more text would be enough.

>
> > 2. In the TLV of Extended Experimental Attribute, several fields are further
> defined after the "Implementor IANA Private Enterprise Number" field, while
> many implementers may follow this design under their Private enterprise
> number, the mechanism chosen in LDP may also be considered, in which the
> format of data after the Length and vendor-ID field are vendor-dependent.
> 

Yes, the type 0x3E00 - 0x3EFF is a reserved range of LDP TLVs for vendor specific extensions, and the type and Vendor ID field together specify how the Data field should be interpreted. At first I thought the type of LDP TLV is analogous to the type of BGP path attribute, while in implementations it is used to identify a particular vendor-private feature. 

>   IEEE charges (I believe) for their ID where IANA will give one out to any

This is fine to me as long as it can identify different vendors.

>   cause the implementor to think about this as a fundamental piece of the

Agree version information can help the troubleshooting of interoperability issues.

>   bit as has been discussed somewhat earlier in the thread.

To my understanding, the optional transitive attribute in BGP is analogous to an LDP TLV with both U and L bit set, so IMO no further bits are required for BGP. 

> 
> > 3. As the Extended Experimental Attribute can contain a series of TLVs, is it
> possible that TLVs belonging to different vendors, or TLVs of different features
> are carried in this attribute? If this is the case, further specification about the
> processing of unrecognized TLVs and the error handling would be needed.
> 
> Currently this draft is tailored toward experiments and development, not long
> term deployment of features.  While the conversation is starting to move
> toward using this as a generic vendor-specific PA replacement, that's not the
> intent of the draft currently.

Understood and totally agree to make this part simple at current stage. While for some experiments in which devices from multiple vendors are involved, it may be possible that different TLVs are carried in this attribute. With LDP this is simpler, as different features are carried in different LDP TLVs and can be processed independently. Of course this can be left for further discussion.

Best regards,
Jie

---

From: Marco Marzetti <[email-masked]>
Date: Sun, 6 Nov 2016 20:23:36 +0100

> inter-as fashion, generating scopes of containment become tricky.
I have always wondered if we should add and N bit to
draft-ietf-idr-bgp-attribute-announcement to limit the advertisements to
neighbor ASes only.

---

From: Colin Petrie <[email-masked]>
Date: Mon, 7 Nov 2016 15:55:01 +0100

Hi Jeff, and thanks for this draft.

> not the intent of the draft currently.

It may not be the intent, but some people have asked about that, and
your draft is a fairly pragmatic approach to giving each vendor a huge
playground space. If it prevents the squatting, I'm all for it :)

Anyway, fully support further discussion on this.

Cheers,
Colin

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 7 Nov 2016 10:26:16 -0500

Marco,

> draft-ietf-idr-bgp-attribute-announcement to limit the advertisements to

Such a thing was discussed among the authors of the attribute-announcement
draft.  What this would mean is such a bit would need to be set and then
automatically reset into the M-bits (C+A) at the next boundary.

The general challenges about what to do when intervening routers did not
understand the header remain.

-- Jeff

---

From: "John G. Scudder" <[email-masked]>
Date: Mon, 7 Nov 2016 13:15:17 -0500

> On Nov 7, 2016, at 10:26 AM, Jeffrey Haas <[email-masked]> wrote:
> 
> Marco,
> 

I'll also observe that we already have the NO_EXPORT community which has virtually the same semantics if you apply it as you're sending the route to your peer. And then there was AS_PATHLIMIT, which never achieved escape velocity. Regarding NO_EXPORT, you might remark that you have to apply it at your border router instead of at the origin, and that's true, but I'm not sure if it's a big deal. You might also remark that NO_EXPORT doesn't survive if your neighbor strips inbound communities (or explicitly blows away NO_EXPORT), and that's true too -- but if operators are deliberately dishonoring NO_EXPORT, is there any reason to think they wouldn't insist implementations have a way to dishonor the mooted N bit?

--John

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 7 Nov 2016 14:26:25 -0500

> On Nov 7, 2016, at 1:15 PM, John G. Scudder <[email-masked]> wrote:
> 
> 

Agreed.  Also, arguably the issue is worse during initial deployment of the attribute-announce feature due to the number of boxes that simply don't understand it.

That said, this is one step beyond "no-export".  It's "set no-export at my asbr boundary".

-- Jeff

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 8 Nov 2016 15:01:35 -0500

> I'll also observe that we already have the NO_EXPORT community which has virtually the same semantics if you apply it as you're sending the route to your peer. And then there was AS_PATHLIMIT, whic…

Marco pointed out privately that NO_EXPORT applies to the entire route whereas the suggested flag would apply to the attribute, so not the same thing. That's right of course, sorry for my confusion. It's not the first time I've made that mistake, but I'll try to let it be the last.

I think the question about whether there will be demand for policy to dishonor the N bit is still worth thinking about though. For some protocol constructs, we seem to have resisted the urge to make them configurable, e.g. AS_PATH loop detection (OK it's a little bit configurable). For others, we seem to consider them little more than decorations to be respected or rejected at the pleasure of the network operator, e.g. NO_EXPORT. I bet it will be important to figure out which category attribute-announcement falls in.

Regards,

--John