Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: draft-ietf-grow-bmp-adj-rib-out-00.txt)

[Tim Evens (tievens)]

Sorry, I jumped to state compression since that would reduce the repeats even 
if they aren't the same in terms of attributes.

I completely agree that peer group is not always the same.  Hence we need the 
protocol to not limit what can be exported.

> On Jul 11, 2017, at 6:41 PM, Jakob Heitz (jheitz)  wrote:
> 
> I said run-length-encoding.
> That's data compression, not state compression.
> The peers in a peer-group do not always get exactly the same updates.
> 
> Thanks,
> Jakob.
> 
> 
>> -Original Message-
>> From: Tim Evens (tievens)
>> Sent: Tuesday, July 11, 2017 6:34 PM
>> To: Jakob Heitz (jheitz) ; Jeffrey Haas 
>> Cc: grow@ietf.org
>> Subject: Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: 
>> draft-ietf-grow-bmp-adj-rib-out-00.txt)
>> 
>> 
>> 
>> On 7/11/17, 6:03 PM, "Jakob Heitz (jheitz)"  wrote:
>> 
>>How about some compression, like run-length-encoding instead of peer 
>> groups to reduce the firehose?
>>A bunch of peers being sent nearly the same updates should compress very 
>> nicely
>>and you wouldn't get all the confusion that comes with peer-groups.
>> 
>> [TE] This is reasonable and per RFC78564 Route-monitoring is state 
>> compressed.  Adj-RIB-Out follows that
>> and supports both route-mirroring and route-monitoring.  The 
>> interval/throttle used for the state-compression
>> should be platform specific, but it should be documented so that we know the 
>> granularity to expect.
>> State-compression should help reduce the number of updates but monitoring 
>> 100 peers that belong to the
>> same update/peer group will likely be wasteful as there will be a lot of 
>> duplication.  In this case,
>> I go back to needing some engineering love.
>> 
>> IMO, it does not make sense to monitor all of those peers if they in fact 
>> are conveying the identical advertisements.
>> In either case, we need that peer group name in the PEER UP so that we can 
>> correlate the peers to groups for proper
>> de-duplication. Unless we are monitoring for software bugs, the engineering 
>> team/operators know which peers should
>> be monitored in order to get a proper group representation based on 
>> egress/export policies. Although, this does put
>> a bit of a burden on engineering deployment.
>> 
>> To address the engineering deployment use-case of monitoring only the 
>> peer-group (export policy), it would be nice
>> to ease the monitoring configuration with the ability on the router to 
>> dynamic select the peer to be monitored.  For
>> instance, under the peer-group configuration for BMP monitoring, enable 
>> "adj-rib-out best 2".  The router then would
>> select the best 2 peers that represent the peer-group advertisements. This 
>> can change over time as peers are added,
>> removed, or experience stability issues.  In terms of BMP, normal 
>> PEER_UP/PEER_DOWN with INFO TLV's would be used so
>> that the receiving system can easily correlate and de-dup as needed by 
>> peer-group.  If the doing peer-group
>> monitoring, the peer itself wouldn't matter as much.
>> 
>> Peer group (including template) monitoring is not limited to Adj-RIB-Out.  
>> The same use-case for monitoring the
>> peer-group for export policy can be said for Adj-RIB-In as well.   The same 
>> engineering/deployment configuration of
>> which peer is to be monitored for the peer-group name can be used for 
>> Adj-RIB-In as well. Easing this configuration
>> for groups is beneficial.
>> 
>> BTW… we absolutely need the OPEN message to convey the capabilities.  This 
>> is required to correctly parse the NRLI's
>> and attributes.
>> 
>> 
>> 
>> 
>>Thanks,
>>Jakob.
>> 
>> 
>> 
> 

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: draft-ietf-grow-bmp-adj-rib-out-00.txt)

[Jakob Heitz (jheitz)]

I said run-length-encoding.
That's data compression, not state compression.
The peers in a peer-group do not always get exactly the same updates.

Thanks,
Jakob.


> -Original Message-
> From: Tim Evens (tievens)
> Sent: Tuesday, July 11, 2017 6:34 PM
> To: Jakob Heitz (jheitz) ; Jeffrey Haas 
> Cc: grow@ietf.org
> Subject: Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: 
> draft-ietf-grow-bmp-adj-rib-out-00.txt)
> 
> 
> 
> On 7/11/17, 6:03 PM, "Jakob Heitz (jheitz)"  wrote:
> 
> How about some compression, like run-length-encoding instead of peer 
> groups to reduce the firehose?
> A bunch of peers being sent nearly the same updates should compress very 
> nicely
> and you wouldn't get all the confusion that comes with peer-groups.
> 
> [TE] This is reasonable and per RFC78564 Route-monitoring is state 
> compressed.  Adj-RIB-Out follows that
> and supports both route-mirroring and route-monitoring.  The 
> interval/throttle used for the state-compression
> should be platform specific, but it should be documented so that we know the 
> granularity to expect.
> State-compression should help reduce the number of updates but monitoring 100 
> peers that belong to the
> same update/peer group will likely be wasteful as there will be a lot of 
> duplication.  In this case,
> I go back to needing some engineering love.
> 
> IMO, it does not make sense to monitor all of those peers if they in fact are 
> conveying the identical advertisements.
> In either case, we need that peer group name in the PEER UP so that we can 
> correlate the peers to groups for proper
> de-duplication. Unless we are monitoring for software bugs, the engineering 
> team/operators know which peers should
> be monitored in order to get a proper group representation based on 
> egress/export policies. Although, this does put
> a bit of a burden on engineering deployment.
> 
> To address the engineering deployment use-case of monitoring only the 
> peer-group (export policy), it would be nice
> to ease the monitoring configuration with the ability on the router to 
> dynamic select the peer to be monitored.  For
> instance, under the peer-group configuration for BMP monitoring, enable 
> "adj-rib-out best 2".  The router then would
> select the best 2 peers that represent the peer-group advertisements. This 
> can change over time as peers are added,
> removed, or experience stability issues.  In terms of BMP, normal 
> PEER_UP/PEER_DOWN with INFO TLV's would be used so
> that the receiving system can easily correlate and de-dup as needed by 
> peer-group.  If the doing peer-group
> monitoring, the peer itself wouldn't matter as much.
> 
> Peer group (including template) monitoring is not limited to Adj-RIB-Out.  
> The same use-case for monitoring the
> peer-group for export policy can be said for Adj-RIB-In as well.   The same 
> engineering/deployment configuration of
> which peer is to be monitored for the peer-group name can be used for 
> Adj-RIB-In as well. Easing this configuration
> for groups is beneficial.
> 
> BTW… we absolutely need the OPEN message to convey the capabilities.  This is 
> required to correctly parse the NRLI's
> and attributes.
> 
> 
> 
> 
> Thanks,
> Jakob.
> 
> 
> 

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: draft-ietf-grow-bmp-adj-rib-out-00.txt)

[Tim Evens (tievens)]

On 7/11/17, 6:03 PM, "Jakob Heitz (jheitz)"  wrote:

How about some compression, like run-length-encoding instead of peer groups 
to reduce the firehose?
A bunch of peers being sent nearly the same updates should compress very 
nicely
and you wouldn't get all the confusion that comes with peer-groups.

[TE] This is reasonable and per RFC78564 Route-monitoring is state compressed.  
Adj-RIB-Out follows that
and supports both route-mirroring and route-monitoring.  The interval/throttle 
used for the state-compression
should be platform specific, but it should be documented so that we know the 
granularity to expect.  
State-compression should help reduce the number of updates but monitoring 100 
peers that belong to the
same update/peer group will likely be wasteful as there will be a lot of 
duplication.  In this case, 
I go back to needing some engineering love.  

IMO, it does not make sense to monitor all of those peers if they in fact are 
conveying the identical advertisements.   In either case, we need that peer 
group name in the PEER UP so that we can correlate the peers to groups for 
proper de-duplication. Unless we are monitoring for software bugs, the 
engineering team/operators know which peers should be monitored in order to get 
a proper group representation based on egress/export policies. Although, this 
does put a bit of a burden on engineering deployment. 

To address the engineering deployment use-case of monitoring only the 
peer-group (export policy), it would be nice to ease the monitoring 
configuration with the ability on the router to dynamic select the peer to be 
monitored.  For instance, under the peer-group configuration for BMP 
monitoring, enable "adj-rib-out best 2".  The router then would select the best 
2 peers that represent the peer-group advertisements. This can change over time 
as peers are added, removed, or experience stability issues.  In terms of BMP, 
normal PEER_UP/PEER_DOWN with INFO TLV's would be used so that the receiving 
system can easily correlate and de-dup as needed by peer-group.  If the doing 
peer-group monitoring, the peer itself wouldn't matter as much. 

Peer group (including template) monitoring is not limited to Adj-RIB-Out.  The 
same use-case for monitoring the peer-group for export policy can be said for 
Adj-RIB-In as well.   The same engineering/deployment configuration of which 
peer is to be monitored for the peer-group name can be used for Adj-RIB-In as 
well. Easing this configuration for groups is beneficial.

BTW… we absolutely need the OPEN message to convey the capabilities.  This is 
required to correctly parse the NRLI's and attributes.  



   
Thanks,
Jakob.

 


___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: draft-ietf-grow-bmp-adj-rib-out-00.txt)

[Jakob Heitz (jheitz)]

How about some compression, like run-length-encoding instead of peer groups to 
reduce the firehose?
A bunch of peers being sent nearly the same updates should compress very nicely
and you wouldn't get all the confusion that comes with peer-groups.

Thanks,
Jakob.


> -Original Message-
> From: Tim Evens (tievens)
> Sent: Tuesday, July 11, 2017 5:58 PM
> To: Jeffrey Haas ; Jakob Heitz (jheitz) 
> Cc: grow@ietf.org
> Subject: Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: 
> draft-ietf-grow-bmp-adj-rib-out-00.txt)
> 
> Jeff,
> 
> On 7/11/17, 5:20 PM, "GROW on behalf of Jeffrey Haas"  on behalf of jh...@pfrc.org> wrote:
> 
> 
> In such cases - use the per peer rib-out.  I do believe it has good use
> cases.  However, discussions with our customers have suggested that in 
> most
> cases it's excessively chatty and threatens to swamp the rib-in portion of
> the control channel they're actually interested in.  For them, a general
> indication of rib-out content is sufficient, even when there's some minor
> variations with specifications they may be comfortable with.
> 
> [TE] IMO, limitations around transmission of X number of peers with *-rib-* 
> monitoring should be BMP
>  sender implementation specific.  I do not believe anyone in their right mind 
> would configure a platform/sender
> for *-rib-* on all peers, but you never know. This is why limits should 
> exist, a line in the sand,
> for the platform.   Limits that apply to one platform are not necessarily 
> required to be applied to another.
> We want to enable the ability to monitor the five collection points of BGP 
> (Adj-RIB-In/pre, Adj-RIB-In/post,
> Adj-RIB-Out/pre, Adj-RIB-Out/post, and Loc-RIB) but this doesn't mean the 
> platform can't restrict combinations.
> 
> I'm also open to alternative encodings that permit better clustering of 
> the
> messages to avoid redundant noise.
> 
> [TE] YES, PEER UP INFO "peer/update group" TLV with engineered deployment 
> will do.  I can't imagine any sizable
> network
> that has been configured without design/engineering.  I do not believe or 
> suggest that is different with
> BGP monitoring.  BGP is big data, like IPFIX in that sense, and therefore 
> should get some engineering love,
> not willy-nilly turn it on everywhere and hope for the best.
> 
> 
> --Tim

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: draft-ietf-grow-bmp-adj-rib-out-00.txt)

[Tim Evens (tievens)]

Jeff,

On 7/11/17, 5:20 PM, "GROW on behalf of Jeffrey Haas"  wrote:


In such cases - use the per peer rib-out.  I do believe it has good use
cases.  However, discussions with our customers have suggested that in most
cases it's excessively chatty and threatens to swamp the rib-in portion of
the control channel they're actually interested in.  For them, a general
indication of rib-out content is sufficient, even when there's some minor
variations with specifications they may be comfortable with.

[TE] IMO, limitations around transmission of X number of peers with *-rib-* 
monitoring should be BMP
 sender implementation specific.  I do not believe anyone in their right mind 
would configure a platform/sender
for *-rib-* on all peers, but you never know. This is why limits should exist, 
a line in the sand,
for the platform.   Limits that apply to one platform are not necessarily 
required to be applied to another.
We want to enable the ability to monitor the five collection points of BGP 
(Adj-RIB-In/pre, Adj-RIB-In/post,
Adj-RIB-Out/pre, Adj-RIB-Out/post, and Loc-RIB) but this doesn't mean the 
platform can't restrict combinations.

I'm also open to alternative encodings that permit better clustering of the
messages to avoid redundant noise.

[TE] YES, PEER UP INFO "peer/update group" TLV with engineered deployment will 
do.  I can't imagine any sizable network
that has been configured without design/engineering.  I do not believe or 
suggest that is different with
BGP monitoring.  BGP is big data, like IPFIX in that sense, and therefore 
should get some engineering love, 
not willy-nilly turn it on everywhere and hope for the best. 


--Tim

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: draft-ietf-grow-bmp-adj-rib-out-00.txt)

[Tim Evens (tievens)]

The use-case to monitor Adj-RIB-Out for a peer-group is definitely something 
this draft
addresses but appears to need more clarification. 

Noisy and likely duplicate/wasteful, yes… if one configures every peer to send 
Adj-RIB-Out
for peers that convey the same data, to which is likely not what folks will do 
or what I would
recommend doing.  I believe this can be addressed by adding "Other 
Considerations" section to
explain how one should go about using adj-rib-out.  For example, in the 
use-case of monitoring
peer-group egress policy advertisements, which is what I believe you are 
addressing with your
comment, the operator should configure at least two reliable peers in a group
to be monitored. This provides redundancy should one peer fail. This would 
easily provide peer-group
level conveyance of the egress policy. What's missing is the peer-group name so 
that on
the receiving side we can correlate (group) the peers that represent the same 
peer-group. 
Providing we have the group name for the peer, the receiver can group the peers 
that have the same
group name.  If the use-case is only to monitor the peer-group policy, not 
specific overrides per peer,
then the receiver can easily de-dup the X (redundant) peers for a single 
representation of the peer-group.

This is use-case specific as there are use-cases where we need to still monitor 
each peer even if they are 
part of the same peer/update group.  

In either case, this is really a receiver knob to correlate based
on intended operator configuration/deployment.  Although we do need the 
peer-group advertised as part
of the PEER INFO TLV, which we talked about at the BoF.  This was meant to be 
added, but I forgot to
add that.

Based on your proposal statements, it seems that this is only a method to 
correlate/map peers, 
peers that still need PEER_UP/per-peer RM messages, into a group. IMO, this 
complicates 
both the implementation (router/sender) and the receiver unnecessarily 
considering we can accommodate
this with a simple PEER_UP INFO TLV. RFC7854 doesn't include any info TLV's
for PEER_UP, but we do introduce them in draft-ietf-grow-bmp-loc-rib.   By 
adding
a PEER_UP info TLV to convey peer/update group name enables the receiver to 
easily correlate
peers that belong to the same group.  How we treat and understand those peers 
is very much specific to the 
operator configuration/deployment/implementation on the receiver side.   The 
operator can
decide if they just need one peer per peer-group or if they want fault 
tolerance by including more peers.
This allows both the peer-group monitoring as well as the cases where an 
operator needs
to monitor each individual peer within a peer group or otherwise. 


Thanks,
Tim


On 7/10/17, 2:15 PM, "GROW on behalf of Jeffrey Haas"  wrote:

Authors,

We briefly discussed this during the bar BoF for BMP last IETF.  My
apologies for not presenting text before this point.

While there are use cases where an end-user may want per-peer rib-out state,
some applications may not quite that level of granularity of information.
In many cases, it is sufficient to know what route will be sent to the peers
that belong to the BGP's peer-group/update-group.  (I'll be using peer-group
for the remainder of this e-mail.)

In such cases, the adj-rib-out in its current form can be quite noisy.  It
effectively can turn the BMP feed into trying to squeeze the entire firehose
of BGP traffic through the straw of a single session.

I'd offer the following proposal for per-group BMP rib-out:

The Per-Peer BMP header (RFC 7854, section 4.2) gets a new "peer-type" of
"Rib-Out Group" (value TBD).

For this new value, the Peer Distinguisher is set to a system-wide group-ID.
The Peer-Address, Peer AS and Peer BGP ID is zero-filled.  The group-ID is
sufficient to determine the contents of the BGP data sent to the peer-group.

A new message is allocated, called "BGP Rib-Out Groups".
Its contents are:

Flags (1 byte), a Delete flag is specified.
Group-Id (8 bytes)
Group-Name Length (1 byte)
Group-Name A UTF-8 string of up to 255 bytes representing the group name.
Number of Peers (2 bytes)
Peer-List Section: (for each peer)
  Peer Type (1 byte)
  Peer Flags (1 byte)
  Peer Distinguisher (8 bytes)
  Peer Address (16 bytes)
  Peer AS (4 bytes)
  Peer BGP ID (4 bytes)

The peer-list section is filled as per RFC 7854, section 4.2.

The BGP Rib-Out Groups message should be sent prior to sending Route
Monitoring or Route  Mirroring messages.  However, the application should be
prepared to receive such messages without the group mapping.

A group mapping by ID may be updated by sending a replacement with the same
Group Id.

A group mapping may be deleted by sending a truncated message 

Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: draft-ietf-grow-bmp-adj-rib-out-00.txt)

[Jeffrey Haas]

Jakob,

Thanks for raising the logical discussion points. :-)

On Tue, Jul 11, 2017 at 09:52:46PM +, Jakob Heitz (jheitz) wrote:
> The message sent to a peer group is not always the same as what's
> sent to the peer.
> Some fields are rewritten at the io-write stage. Nexthop is common.
> When it's written to the peer-group, it is not yet written to the peer.

That's absolutely true.  You give the example of nexthop.  My employer's
implementation also may do AS-substitution for prepending, insertion of
communities for things like LLGR, etc.

In such cases, it's not possible to get exactly what is sent out to a given
peer.

> If there is a slow peer in the group, anything could happen before the
> message actually gets to the peer: It could go down; it could leave the
> peer-group, ...

This is potentially a problem in the BMP architecture anyway.  There's no
guarantee that the BMP messaging is in sync with BGP, including potential
state compression.  The same is true for mirroring since  it'd imply
infinite buffering which is not feasible.

> Some vendors (eg. IOS-XR) have several types of peer grouping.
> There are a number of ways to group configurations.
> In addition, the peers are automatically grouped into update groups such that
> each member gets (mostly) the same update message.

In cases where peers are fully dynamically grouped rather than clustered in
a way that is mostly static, my proposal wouldn't be terribly helpful.
That said:

> peer-groups will add significant confusion and complexity, especially
> when different vendors or even different versions from the same vendor
> do different things.

In such cases - use the per peer rib-out.  I do believe it has good use
cases.  However, discussions with our customers have suggested that in most
cases it's excessively chatty and threatens to swamp the rib-in portion of
the control channel they're actually interested in.  For them, a general
indication of rib-out content is sufficient, even when there's some minor
variations with specifications they may be comfortable with.

I'm also open to alternative encodings that permit better clustering of the
messages to avoid redundant noise.


-- Jeff

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: draft-ietf-grow-bmp-adj-rib-out-00.txt)

[Jakob Heitz (jheitz)]

The message sent to a peer group is not always the same as what's
sent to the peer.
Some fields are rewritten at the io-write stage. Nexthop is common.
When it's written to the peer-group, it is not yet written to the peer.
If there is a slow peer in the group, anything could happen before the
message actually gets to the peer: It could go down; it could leave the
peer-group, ...

Some vendors (eg. IOS-XR) have several types of peer grouping.
There are a number of ways to group configurations.
In addition, the peers are automatically grouped into update groups such that
each member gets (mostly) the same update message.

peer-groups will add significant confusion and complexity, especially
when different vendors or even different versions from the same vendor
do different things.

Thanks,
Jakob.

> -Original Message-
> From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Gert Doering
> Sent: Tuesday, July 11, 2017 1:55 AM
> To: Jeffrey Haas 
> Cc: grow@ietf.org
> Subject: Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: 
> draft-ietf-grow-bmp-adj-rib-out-00.txt)
> 
> Hi,
> 
> On Mon, Jul 10, 2017 at 05:15:09PM -0400, Jeffrey Haas wrote:
> > We briefly discussed this during the bar BoF for BMP last IETF.  My
> > apologies for not presenting text before this point.
> >
> > While there are use cases where an end-user may want per-peer rib-out state,
> > some applications may not quite that level of granularity of information.
> > In many cases, it is sufficient to know what route will be sent to the peers
> > that belong to the BGP's peer-group/update-group.  (I'll be using peer-group
> > for the remainder of this e-mail.)
> >
> > In such cases, the adj-rib-out in its current form can be quite noisy.  It
> > effectively can turn the BMP feed into trying to squeeze the entire firehose
> > of BGP traffic through the straw of a single session.
> 
> "per peer group" would actually match our use-case for rib-out much
> better than "per individual peer".  So, support for that idea.
> 
> On the actual implementation, I abstain, as I haven't read up on the
> technical details enough to make a qualified comment.
> 
> Gert Doering
> -- NetMaster
> --
> have you enabled IPv6 on something today...?
> 
> SpaceNet AGVorstand: Sebastian v. Bomhard
> Joseph-Dollinger-Bogen 14  Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen   HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444   USt-IdNr.: DE813185279
> 
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: draft-ietf-grow-bmp-adj-rib-out-00.txt)

[Gert Doering]

Hi,

On Mon, Jul 10, 2017 at 05:15:09PM -0400, Jeffrey Haas wrote:
> We briefly discussed this during the bar BoF for BMP last IETF.  My
> apologies for not presenting text before this point.
> 
> While there are use cases where an end-user may want per-peer rib-out state,
> some applications may not quite that level of granularity of information.
> In many cases, it is sufficient to know what route will be sent to the peers
> that belong to the BGP's peer-group/update-group.  (I'll be using peer-group
> for the remainder of this e-mail.)
> 
> In such cases, the adj-rib-out in its current form can be quite noisy.  It
> effectively can turn the BMP feed into trying to squeeze the entire firehose
> of BGP traffic through the straw of a single session.

"per peer group" would actually match our use-case for rib-out much
better than "per individual peer".  So, support for that idea.

On the actual implementation, I abstain, as I haven't read up on the
technical details enough to make a qualified comment.

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AGVorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14  Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444   USt-IdNr.: DE813185279

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow