I pasted from the draft.

Thanks,
Jakob.


> On Mar 3, 2017, at 9:18 PM, Keyur Patel <[email protected]> wrote:
> 
> Jacob,
> 
> Ebgp Peers are out of scope. Imho, implementations are free to implement 
> receipt and processing of a community from a ebgp peer as a knob. The 
> standard doesn't have to accommodate knobs.
> 
> Regards,
> Keyur
> 
> Sent from my iPhone
> 
>> On Mar 3, 2017, at 8:40 PM, Jakob Heitz (jheitz) <[email protected]> wrote:
>> 
>>  However it SHOULD be possible to
>>  configure an implementation to send or accept the community when
>>  warranted.  An example of a case where the community would reasonably
>>  be received from, or sent to, an EBGP peer is when two adjacent ASes
>>  are under control of the same administration.  A second example is
>>  documented in [I-D.ietf-sidr-route-server-rpki-light].
>> 
>> Thanks,
>> Jakob.
>> 
>>> -----Original Message-----
>>> From: Chris Morrow [mailto:[email protected]]
>>> Sent: Friday, March 03, 2017 8:38 PM
>>> To: Randy Bush <[email protected]>
>>> Cc: Jakob Heitz (jheitz) <[email protected]>; Chris Morrow 
>>> <[email protected]>; Montgomery, Douglas (Fed)
>>> <[email protected]>; Alvaro Retana (aretana) <[email protected]>; 
>>> [email protected];
>>> [email protected]; [email protected]; [email protected]
>>> Subject: Re: [sidr] Protocol Action: 'BGP Prefix Origin Validation State 
>>> Extended Community' to Proposed Standard
>>> (draft-ietf-sidr-origin-validation-signaling-11.txt)
>>> 
>>> At Sat, 04 Mar 2017 13:36:05 +0900,
>>> Randy Bush <[email protected]> wrote:
>>>> 
>>>>> The ext-comm may come from an ebgp neighbor.
>>> 
>>> ebgp neighbor? the text talks about ibgp, and about explicitly ignoring 
>>> ebgp senders of this community (by default).
>>> 
>>> right?
>>> 
>>>> 
>>>> ok.  saves a character.  my kind of change :)
>>>> 
>>>> "Similarly, a receiving BGP speaker, in the absence of validation
>>>>  state set based on local data, SHOULD derive a validations state from
>>>>  the last octet of the extended community, if present."
>>>> 
>>>> randy

_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr

Reply via email to