Subject: [Idr] WG adoption of draft-dhrao-idr-4octet-extcomm-generic-subtype

From: Yakov Rekhter <[email-masked]>
Date: Sun, 02 Nov 2008 07:27:00 -0800

Folks,

Please send your comments on the attached. The deadline for comments
is Nov 17, 2008.

Yakov.
------- Forwarded Message

Date:    Fri, 31 Oct 2008 18:29:47 -0400
From:    Jeffrey Haas <[email-masked]>
To:      [email-masked]
Subject: [Idr] WG adoption of draft-dhrao-idr-4octet-extcomm-generic-subtype

Yakov and Sue,

We'd like to request the working group adopt the internet-draft
draft-dhrao-idr-4octet-extcomm-generic-subtype as a working group item.
This draft adds a generic 4 octet extended community to complement the
2-octet AS community behavior publised in RFC 1997.

Although very similar to draft-ietf-l3vpn-as4octet-ext-community, we'd
like to request adoption of this draft in IDR since it has no l3vpn
specific semantics.

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

------- End of Forwarded Message

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

---

From: Danny McPherson <[email-masked]>
Date: Mon, 3 Nov 2008 08:18:11 -0700

> Please send your comments on the attached. The deadline for comments

I support this work, and believe IDR is the right place
for it.

-danny

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 18 Nov 2008 13:50:10 -0500

Yakov,

> Please send your comments on the attached. The deadline for comments

Given the (typical) lack of response in the mail list, I'd like to
request a room poll for this at the upcoming IDR session.  Since the
feature is straight forward, I don't believe we need to take the time to
give a presentation.

If you think the presentation is helpful, I'll prepare the slide.

-- Jeff

---

From: Enke Chen <[email-masked]>
Date: Tue, 18 Nov 2008 10:57:55 -0800

Hi, folks:

I would like to point out that this is not an optional feature. Rather 
it is mandatory for the 4byte AS deployment, and this is something that 
should have been done much earlier.

Yes, please move it forward.

Thanks. -- Enke

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 18 Nov 2008 14:05:36 -0600

Please add my belated support for adoption.

--John

---

From: Geoff Huston <[email-masked]>
Date: Wed, 19 Nov 2008 11:13:33 +1100

I have read this draft

I also (belatedly) suport its adoption as a WG document. My apologies  
for my tardiness in making this response.

   Geoff

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 20 Nov 2008 19:51:31 -0500

> feature is straight forward, I don't believe we need to take the time to

It would appear a presentation would have been helpful.  While we have
gotten an additional few people noting support on the mailing list, the
lack of familiarity with the draft seems to be at issue.

I'd like to encourage all of IDR to take a quick look at
draft-dhrao-idr-4octet-extcomm-generic-subtype and indicate support or
lack of support for this document.  We currently do not have a 4-byte AS
equivalent standard community and this is going to be an increasingly
large issue for operators as we deploy 4 byte ASes.

Per the IDR session, we do not have enough visible support to adopt this
draft.  I find that honestly shocking.

Don't make me go rattling on mailing lists like NANOG for support. :-)

-- Jeff

---

From: "Cayle Spandon" <[email-masked]>
Date: Fri, 21 Nov 2008 09:46:08 -0500

I strongly agree that support for 4-octet AS numbers in extended
communities is a problem which needs to be solved.

Here are some comments on the draft:

Add a reference to [RFC4360].

Only 2 bytes for the Local Administrator field seems very restrictive.

Do we need a capability (for capability negotiation) for this? (Just
because a speaker supports 4-octet AS numbers does not necessarily
imply it supports 4-octet AS numbers in extended communities).

Do we need rules on what to do when a NEW speaker sends an UPDATE with
a 4-octet extended community to an OLD speaker (similar to section
4.2.2. of [RFC4893])?

It seems relatively straightforward to include all relevant
information in this draft and remove the references to
[I-D.ietf-l3vpn-as4octet-ext-community
<http://tools.ietf.org/html/draft-dhrao-idr-4octet-extcomm-generic-subtype-00#ref-I-D.ietf-l3vpn-as4octet-ext-community>]
(this makes it a "stand-alone" draft).

---

From: Paul Jakma <[email-masked]>
Date: Fri, 21 Nov 2008 17:51:52 +0000 (GMT)

This needs to be adopted by the IDR.

Comments:

1. Shouldn't it cite RFC4360?

2. Is it deliberate that the non-transitive-bit-set form of 0x2,
    0x42, is not specified there?

2. I'm probably being dense, but why does it have a fixed sub-type of
    4? I.e. isn't the idea to specify a generic AS4 extcomm, and
    shouldn't it therefore apply to the existing sub-types (rather
    than a new one)?

3. "Deployment Considerations" / Compatibility:

    Could this section perhaps be rephrased so as to encourage maximum
    compatibility? E.g. prefer the AS2 form over the AS4, where the
    values fit? I think this might be important with transitive
    communities.

4. Some people use communities to send AS values to their peers (e.g.
    "please blackhole AS-X"). What's going to happen when someone
    wants to flag some 4-byte-AS to their 4-byte-AS peer? :)

    (I guess this one isn't terribly urgent, but it sounds like we'll
     need to widen extended-communities one day?)

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
SHOP OR DIE, people of Earth!
[offer void where prohibited]
-- Capitalists from outer space, from Justice League Int'l comics
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 21 Nov 2008 14:12:40 -0500

Cayle,

Thanks for your support and comments:

> Only 2 bytes for the Local Administrator field seems very restrictive.

It is, however, consistent with the other similar drafts.

See draft-ietf-l3vpn-as4octet-ext-community-01.txt

> imply it supports 4-octet AS numbers in extended communities).

I don't believe capability negotiation will be required.  Somewhat per
the draft's Deployment Consideration section, if the ISP doesn't support
a 4-octet extended community but does use 4-octet ASes, they can define
a two octet AS as their transition mechanism.

If you believe stronger text to address this point should be in the
Deployment Considerations, I believe that could be added.

> a 4-octet extended community to an OLD speaker (similar to section

I don't believe so.  It is possible to support 4-octet communities
without supporting 4-octet ASes and vice versa.  It is, however,
necessary for ISPs to negotiate which communities they will use for
signalling.  This is no different than ISPs having to decide which
communities they'll send and accept.

My expectation is that transitionally ISPs will provide 2-octet
communities along with 4-octet ones.

> (this makes it a "stand-alone" draft).

Excellent point. Thanks.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 21 Nov 2008 15:00:53 -0500

Paul,

>    0x42, is not specified there?

See RFC 4360, Section 2, "transitive bit".  If the top bit is clear, it
is transitive.

>    shouldn't it therefore apply to the existing sub-types (rather

The first octet represents the format - 0x04 meaning 4 octet global
administrator field.  The second octet represents the subtype - we're
looking to define this as the 'generic' 4-octet extended community type.
The other subtypes have differing semantics.

(I may be misunderstanding your question.)

Note that there is errata registered on RFC 4360 to an incomplete
refactoring of type 0x02 out of the base draft.

>    values fit? I think this might be important with transitive

I believe that's what we're trying to achieve.  Do you have any
suggested wording changes?  In the case of a 2 octet community that has
a 4 octet community representation, our expectations are they should be
expressed in 2 octet format.  In the situation where they are not, this
should be no different than conflicting sets of communities targeted to
a given AS today.  E.g. if I send community 64512:100 and ext comm:
0x0204:0.64512:200, how is this different from having received
64512:200?  The only clear difference is that in the case of mis-coding,
it's possible the receiving router may not understand the second
community due to lack of 4-octet generic extended community support.

>     need to widen extended-communities one day?)

I think that's probably a much larger issue since not only does this
have semantics, but even 4 octets for the local administrator field
isn't sufficient.  We couldn't encode this in an extended community.
This base issue was one of the motivations of Andrew Lange's flexible
community format.

-- Jeff

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 24 Nov 2008 12:46:11 -0800

Jeff,

> draft.  I find that honestly shocking.

Let's extend the time for comments until Nov 30, 2008.

Yakov.

---

From: Andrew Partan <[email-masked]>
Date: Mon, 24 Nov 2008 16:36:48 -0500

> > large issue for operators as we deploy 4 byte ASes.

If this allows me to use communities like 14329.345:120 then lets
get this standardized and implemented as soon as possible.

Andrew Partan

---

From: "Pradosh Mohapatra (pmohapat)" <[email-masked]>
Date: Mon, 24 Nov 2008 23:03:38 -0800

| On Mon, Nov 24, 2008 at 12:46:11PM -0800, Yakov Rekhter wrote:
| > > I'd like to encourage all of IDR to take a quick look at 
| > > draft-dhrao-idr-4octet-extcomm-generic-subtype and 
| indicate support 
| > > or lack of support for this document.  We currently do not have a 
| > > 4-byte AS equivalent standard community and this is going 
| to be an 
| > > increasingly large issue for operators as we deploy 4 byte ASes.
| 
| If this allows me to use communities like 14329.345:120 then 
| lets get this standardized and implemented as soon as possible.

Thanks Andrew. That's what the draft proposes.

- Pradosh

---

From: <[email-masked]>
Date: Tue, 25 Nov 2008 09:44:42 +0100

Support.

In section 3 (Deployment Considerations)

> A speaker with a 4-octet Autonomous System may have a customer or
> peer with a 2-octet Autonomous System.  If such a peer supports
> 4-octet extended communities, then it will be able to tag its routes
> with the 4-octet extended community defined by the speaker.  If the
> peer does not support 4-octet extended communities, then the speaker
> may need to define an appropriate standard community value for the
> same purpose.

Could the document explicitly states whether the reserved AS_TRANS value (ASN 23456 defined in RFC 4893) can (or cannot) be used by a non compliant 2-octet AS peering with a 4-octet AS?

Thanks,
Regards,
Bruno

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la part de Yakov Rekhter
> Envoyé : dimanche 2 novembre 2008 16:27
> À : [email-masked]
> Objet : [Idr] WG adoption of draft-dhrao-idr-4octet-extcomm-generic-subtype
> 
> Folks,
>

---

From: "Dhananjaya Rao (dhrao)" <[email-masked]>
Date: Tue, 25 Nov 2008 00:53:52 -0800

Hi Bruno,

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of [email-masked]
>Sent: Tuesday, November 25, 2008 12:45 AM
>To: [email-masked]; [email-masked]
>Subject: Re: [Idr] WG adoption 
>ofdraft-dhrao-idr-4octet-extcomm-generic-subtype
>
>Support.
>

Thanks for your support.

>Could the document explicitly states whether the reserved 
>AS_TRANS value (ASN 23456 defined in RFC 4893) can (or cannot) 
>be used by a non compliant 2-octet AS peering with a 4-octet AS?
>

Yes, AS_TRANS can be used for the above stated purpose. As discussed,
we will add this to the draft as one example of an appropriate 
standard community.

Regards,
-Dhananjaya

>> Objet : [Idr] WG adoption of 
>draft-dhrao-idr-4octet-extcomm-generic-subtype
>> 
>> Folks,
>> 
>> Subject: [Idr] WG adoption of 
>draft-dhrao-idr-4octet-extcomm-generic-subtype
>> 
>> Yakov and Sue,
>> 
>> Although very similar to 
>draft-ietf-l3vpn-as4octet-ext-community, we'd