Re: [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call

[Bidgoli, Hooman (Nokia - CA/Ottawa)]

Hi All

Zzh> I do think BGP signaling for SR P2MP is appropriate. We just need to 
discuss the two ways and figure out how to proceed. The authors have discussed 
before though we have not reached consensus.

HB> yes there was discussion and there was no consensus to merge the 2 drafts 
as their approach is widely different. The authors of this draft have kept the 
implementation very close to unicast BGP SR Policy for the segment list, which 
simplifies the implementation and deployment of the technology. As you said 
there seems to be two way to download this policy and the segment list and we 
can work on both.
Given the solid support I don't see why the adoption of this draft should  be 
delayed because of these arguments.

Thanks
Hooman

From: pim  On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Friday, March 25, 2022 10:47 AM
To: Susan Hares ; i...@ietf.org
Cc: 'p...@ietf.org' ; 'BESS' 
Subject: Re: [pim] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - 
Adoption call

[+ BESS, PIM]

Hi,

I realized that in a hurry I did not respond to the specific questions below. 
Please see zzh> next to the questions.

Looks like that there are some comments on BESS/PIM list and I will go through 
those to see if I have any addition/follow-up on those.



Juniper Business Use Only
From: Idr mailto:idr-boun...@ietf.org>> On Behalf Of 
Jeffrey (Zhaohui) Zhang
Sent: Friday, March 25, 2022 6:30 AM
To: Susan Hares mailto:sha...@ndzh.com>>; 
i...@ietf.org
Subject: Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption 
call

[External Email. Be cautious of content]

I am sorry for responding late. I somehow missed this.

I think we should discuss the relationship with 
daft-ietf-bess-bgp-multicast-controller further before adopting this.

Thanks.
Jeffrey



Juniper Business Use Only
From: Idr mailto:idr-boun...@ietf.org>> On Behalf Of 
Susan Hares
Sent: Thursday, March 10, 2022 10:28 AM
To: i...@ietf.org
Subject: Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption 
call

[External Email. Be cautious of content]

IDR WG:

If you just wish to respond to the IDR list,
you may respond to this email on the adoption call.

Cheers, Sue

From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of Susan Hares
Sent: Thursday, March 10, 2022 9:55 AM
To: i...@ietf.org; p...@ietf.org; 
bess@ietf.org
Subject: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022)

This begins a 2 week WG adoption call for:
draft-hb-idr-sr-p2mp-policy from (3/10 to 3/24/2022)

You can obtain the draft at:
https://datatracker.ietf.org/doc/draft-hb-idr-sr-p2mp-policy/

In your comments for this call please consider:

Zzh> I want to point out that 
https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-multicast-controller/ is 
another way to do the same. I also explained in 
https://mailarchive.ietf.org/arch/msg/idr/KObeSgKPu3HRbd0ZN7L7fWq_Eto/ why it 
was in the bess WG.
Zzh> In addition, the bess draft supports *other* multicast trees (IP, mLDP 
besides SR-P2MP) using a consistent way.

1)  Does this technology support the SR P2MP features
that distributes candidate paths which connect
a multicast distribution tree (tree to leaves).

Zzh> It is one way to use BGP to support that. The bess draft specifies another 
way.

2) Is the technology correctly specified for the
NLRI (AFI/SAFI) and the tunnel encapsulation attribute
additions (sections 2 and 3)?

Zzh> The specified SAFI and tunnel encapsulation attribute additions are one 
way for the BGP signaling for SR-P2MP. The bess draft specifies another way.

3) Does the P2MP policy operation (section 4)
provide enough information for those implementing this
technology and those deploying the technology?

4) Do you think this multicast technology is a good
Place to start for P2MP policy advertisement via BGP?

Zzh> Both ways are good place to start. We just need to figure out how to 
proceed with the two proposals.

5) Do you think this SR P2MP policies should not be advertised
via BGP?

Zzh> I do think BGP signaling for SR P2MP is appropriate. We just need to 
discuss the two ways and figure out how to proceed. The authors have discussed 
before though we have not reached consensus.
Zzh> Thanks!
Zzh> Jeffrey

Cheers, Susan Hares
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [pim] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022)

[Bidgoli, Hooman (Nokia - CA/Ottawa)]

Hi Jie

Inline

Thanks
Hooman

From: Idr  On Behalf Of Dongjie (Jimmy)
Sent: Tuesday, March 22, 2022 3:08 AM
To: Susan Hares ; i...@ietf.org; p...@ietf.org; bess@ietf.org
Subject: Re: [Idr] [pim] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022)

Hi Sue and authors,

I've read the latest version of this document and have some questions,

I understand this document provides one mechanism to build P2MP Trees using the 
tree SIDs and the unicast SR SIDs.  While it is not quite clear to me how much 
it is analogous to SR policy, and whether BGP is the suitable tool for its 
provisioning.


1.   This document introduces 3 route types. The first route type is 
provisioned to the headend node (the root node), the second route type is used 
to provision the replication SID on each replication node individually, and the 
third route type is used to progress each outgoing interface individually for a 
replication cross connect.  This is different from SR Policy which only needs 
to be provisioned on the headend nodes of the path, and it seems that this is 
an extension to BGP for the provisioning of individual transit nodes and 
interfaces with different information.





HB> P2MP policy itself can be used to create a tree or it can be used for 
ingress replication. There was a very lengthy discussion in SPRING and PIM and 
we decided to put the replication segment in the SPRING as replication segment 
has the segment-List for each OIF which can use the source routing concept for 
each OIF.

HB> please have a look at the draft draft-ietf-spring-sr-replication-segment-07 
- SR Replication Segment for Multi-point Service 
Delivery
 and draft-voyer-pim-sr-p2mp-policy-02 - Segment Routing Point-to-Multipoint 
Policy 
(ietf.org) 
for details

HB> this is why we have 3 route type. The P2MP policy is really created a 
policy for PMSIs to steer the traffic into the tree, whether it is a tree or 
source replication.

HB> the replication SID route type is really use to build the replication state 
at the replicating node and the IIF and OIF information and not the 
segment-list itself

HB> the last route type which builds the segment-list it self is more inline 
with SR Policy and is using most of that concept.

HB> again for multicast the segment-list is really the OIF of the replication 
segment and the source routing comes in from one replication segment to the 
next replication segment.



2.   In this document, a P2MP candidate path carried in BGP tunnel encaps 
attribute consists of several path instances, one of the path instance is 
active, the others are used as backup paths. And under a path instance, it may 
contain a protection segment list.



While in BGP SR Policy,  the tunnel encaps attribute consists of multiple 
segment lists under one candidate path, and all the segment lists are used for 
load balancing purpose. Different candidate paths can be used as either active 
or backup paths, but they are carried with different SR Policy NLRIs. Since 
this document says it reuses the concept of candidate path, It would be helpful 
if it could highlight the difference from SR Policy candidate path in the 
structure.

HB> yes correct, if you go with the explanation above, the policy is the 
steering point into the Tree and first replication segment. Hence at the head 
end (p2mp policy) we needed the concept of candidate path redundancy. Each 
candidate path is a separate tree (tree or source replication) with the one 
with highest preference being the active tree. Again because we are trying to 
bring redundancy to a tree, the entire tree and its replication segments need 
to be part of a unique candidate path. Each tree/candidate path can be globally 
optimize, hence the path instance. Where a new path instance is created for 
that tree/candidate path and the MBB procedure will move the traffic from one 
path instance to the next. We tried to leverage the SR policy for programming 
of the OIFs which are in par more with source routing and sr policy.




Best regards,
Jie

From: pim [mailto:pim-boun...@ietf.org] On Behalf Of Susan Hares
Sent: Thursday, March 10, 2022 10:55 PM
To: i...@ietf.org; p...@ietf.org; 
bess@ietf.org
Subject: [pim] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022)

This begins a 2 week WG adoption call for:
draft-hb-idr-sr-p2mp-policy from (3/10 to 3/24/2022)

You can obtain the draft at:
https://datatracker.ietf.org/doc/draft-hb-idr-sr-p2mp-policy/

In your comments for this call please consider:

1)  Does this technology support the SR P2MP features
that distributes candidate paths which connect
a multicast distribution tree (tree to leaves).

2) Is the technology correctly specified for the
NLRI (AFI/SAFI) and the tunnel encapsulation attribute
additions (sections 2 and 3)?

3) 

Re: [bess] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022)

[Bidgoli, Hooman (Nokia - CA/Ottawa)]

Hi All

As an co-author of this draft I support this draft.

Currently there is no answer for multicast in a segment routing domain, 
enabling traditional multicast protocols will create an overhead which is not 
acceptable.

Clean/Lean network from control point of view is the key of future network 
deployments. This means simplifications of the control plane overlay and of 
course single IGP underlay. P2MP policy provides this.

P2MP policy is a controller specific policy where the controller learns of the 
root and the leaves of the tree and calculates the Tree and downloads the 
appropriate replication segments on the path of the tree. To program the policy 
and its replication segments there are 2 technologies, PCEP and BGP. As we all 
know it comes down to the operator choice to implement one or the other or both 
in the network.

In addition the strength of this draft is reusing the unicast BGP SR TE Policy 
infrastructure, objects and SUB-TLVs. This draft basically enhances BGP SR TE 
Policy to P2MP policy.

>From NLRI point of view there are 2 NLRI one for P2MP policy and its candidate 
>paths, which is relevant to the root (head-end) and another for downloading 
>the replication segments which are the forwarding entities and sid-list. There 
>was no need to download the P2MP policy and the candidate paths on the transit 
>and the leaves hence why the separation creates a clean and optimised solution.





Regards

Hooman

From: BESS  On Behalf Of Susan Hares
Sent: Thursday, March 10, 2022 9:55 AM
To: i...@ietf.org; p...@ietf.org; bess@ietf.org
Subject: [bess] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022)

This begins a 2 week WG adoption call for:
draft-hb-idr-sr-p2mp-policy from (3/10 to 3/24/2022)

You can obtain the draft at:
https://datatracker.ietf.org/doc/draft-hb-idr-sr-p2mp-policy/

In your comments for this call please consider:

1)  Does this technology support the SR P2MP features
that distributes candidate paths which connect
a multicast distribution tree (tree to leaves).

2) Is the technology correctly specified for the
NLRI (AFI/SAFI) and the tunnel encapsulation attribute
additions (sections 2 and 3)?

3) Does the P2MP policy operation (section 4)
provide enough information for those implementing this
technology and those deploying the technology?

4) Do you think this multicast technology is a good
Place to start for P2MP policy advertisement via BGP?

5) Do you think this SR P2MP policies should not be advertised
via BGP?

Cheers, Susan Hares
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-pbb-evpn-isid-cmacflush-02

[Bidgoli, Hooman (Nokia - CA/Ottawa)]

I Support this draft, important concept.

Regards
Hooman

From: BESS  On Behalf Of Bocci, Matthew (Nokia - GB)
Sent: Tuesday, June 1, 2021 8:48 AM
To: bess@ietf.org
Cc: draft-ietf-bess-pbb-evpn-isid-cmacfl...@ietf.org; bess-cha...@ietf.org
Subject: [bess] WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-pbb-evpn-isid-cmacflush-02

This email starts a two-week working group last call for 
draft-ietf-bess-pbb-evpn-isid-cmacflush-02  [1]

Please review the draft and send any comments to the BESS list. Also, please 
indicate if you support publishing the draft as a Standards Track RFC.

This poll runs until the 15th June 2021.

We are also polling for knowledge of any undisclosed IPR that applies to this 
document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an author or a contributor of this document please respond 
to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR. The document won't progress without answers from all the 
authors and contributors.
There are currently no IPR disclosures.

In addition, we are polling for knowledge of implementations of this draft, per 
the BESS policy in [2].

Thank you,
Matthew & Stephane


[1] draft-ietf-bess-pbb-evpn-isid-cmacflush-02 - PBB-EVPN ISID-based 
CMAC-Flush
[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw



___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Please send slot request for IETF 111

[Bidgoli, Hooman (Nokia - CA/Ottawa)]

Hi


10 min for draft-hb-idr-sr-p2mp-policy-02

Regards
Hooman

From: BESS  On Behalf Of Mankamana Mishra (mankamis)
Sent: Thursday, June 24, 2021 10:39 AM
To: bess@ietf.org
Subject: [bess] Please send slot request for IETF 111

All,
Please send me slot request for IETF 111. Please do not change the subject, 
last IETF I had missed few reply due to subject change ☺

Mankamana
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Adoption and IPR all for draft-parekh-bess-mvpn-evpn-sr-p2mp-02

[Bidgoli, Hooman (Nokia - CA/Ottawa)]

In addition I am not aware of any relevant IPR applicable to this document

Thanks
Hooman
From: Bidgoli, Hooman (Nokia - CA/Ottawa) 
Sent: Wednesday, November 4, 2020 1:44 PM
To: Bocci, Matthew (Nokia - GB) ; bess@ietf.org; 
draft-parekh-bess-mvpn-evpn-sr-p...@ietf.org
Subject: RE: WG Adoption and IPR all for draft-parekh-bess-mvpn-evpn-sr-p2mp-02

As co-author I Support this draft, needed for P2MP policy.

Thanks
Hooman

From: Bocci, Matthew (Nokia - GB) 
mailto:matthew.bo...@nokia.com>>
Sent: Monday, November 2, 2020 7:42 AM
To: bess@ietf.org<mailto:bess@ietf.org>; 
draft-parekh-bess-mvpn-evpn-sr-p...@ietf.org<mailto:draft-parekh-bess-mvpn-evpn-sr-p...@ietf.org>
Subject: WG Adoption and IPR all for draft-parekh-bess-mvpn-evpn-sr-p2mp-02

Hello,

This email begins a two-weeks WG adoption poll for 
draft-parekh-bess-mvpn-evpn-sr-p2mp [1].

Please review the draft and post any comments to the BESS working group list.

We are also polling for knowledge of any undisclosed IPR that applies to this 
document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an author or a contributor of this document, please 
respond to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR, copying the BESS mailing list. The document will not  progress 
without answers from all of the authors and contributors.

Currently, there are no IPR disclosures against this document.

If you are not listed as an author or a contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.

This poll for adoption closes on Monday 16th November 2020.

Regards,
Matthew and Stephane

[1]  https://datatracker.ietf.org/doc/draft-parekh-bess-mvpn-evpn-sr-p2mp/




___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Adoption and IPR all for draft-parekh-bess-mvpn-evpn-sr-p2mp-02

[Bidgoli, Hooman (Nokia - CA/Ottawa)]

As co-author I Support this draft, needed for P2MP policy.

Thanks
Hooman

From: Bocci, Matthew (Nokia - GB) 
Sent: Monday, November 2, 2020 7:42 AM
To: bess@ietf.org; draft-parekh-bess-mvpn-evpn-sr-p...@ietf.org
Subject: WG Adoption and IPR all for draft-parekh-bess-mvpn-evpn-sr-p2mp-02

Hello,

This email begins a two-weeks WG adoption poll for 
draft-parekh-bess-mvpn-evpn-sr-p2mp [1].

Please review the draft and post any comments to the BESS working group list.

We are also polling for knowledge of any undisclosed IPR that applies to this 
document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an author or a contributor of this document, please 
respond to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR, copying the BESS mailing list. The document will not  progress 
without answers from all of the authors and contributors.

Currently, there are no IPR disclosures against this document.

If you are not listed as an author or a contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.

This poll for adoption closes on Monday 16th November 2020.

Regards,
Matthew and Stephane

[1]  https://datatracker.ietf.org/doc/draft-parekh-bess-mvpn-evpn-sr-p2mp/




___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG adoption poll and IPR poll for draft-snr-bess-evpn-loop-protect

[Bidgoli, Hooman (Nokia - CA/Ottawa)]

Support, useful draft

Regards

Hooman

From: BESS  On Behalf Of Van De Velde, Gunter (Nokia - 
BE/Antwerp)
Sent: Monday, September 30, 2019 10:59 PM
To: Stephane Litkowski ; stephane.litkow...@orange.com
Cc: draft-snr-bess-evpn-loop-prot...@ietf.org; bess-cha...@ietf.org; 
bess@ietf.org
Subject: Re: [bess] WG adoption poll and IPR poll for 
draft-snr-bess-evpn-loop-protect

Yes, Support adoption.

G/

From: BESS mailto:bess-boun...@ietf.org>> On Behalf Of 
Stephane Litkowski
Sent: Thursday, September 19, 2019 16:06
To: stephane.litkow...@orange.com
Cc: 
draft-snr-bess-evpn-loop-prot...@ietf.org;
 bess-cha...@ietf.org; 
bess@ietf.org
Subject: Re: [bess] WG adoption poll and IPR poll for 
draft-snr-bess-evpn-loop-protect

Hi,

The poll has ended.
I haven't seen a lot of support from the various vendor while Jorge has 
mentioned that there are multiple implementations. Before closing definitely 
this poll, I would like to let the opportunity to other vendors to raise their 
voice and support the draft especially if they have implementations.
I will let an additional week.

Stephane


On Mon, Sep 2, 2019 at 4:29 PM 
mailto:stephane.litkow...@orange.com>> wrote:
Hi,

This email begins a two-weeks WG adoption poll for 
draft-snr-bess-evpn-loop-protect-04 [1]
Please review the draft and post any comments to the BESS working group list.

We are also polling for knowledge of any undisclosed IPR that applies to this 
Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an author or a contributor of this document, please 
respond to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.
Currently, there are no IPR disclosures against this document.

If you are not listed as an author or a contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.

This poll for adoption closes on 16th September 2019.

Regards,
Stephane and Matthew

[1] https://datatracker.ietf.org/doc/draft-snr-bess-evpn-loop-protect/




[Orange logo]

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET
Orange Expert Future Networks
phone: +33 2 23 06 49 83 

  NEW !
mobile: +33 6 71 63 27 50 

  NEW !
stephane.litkow...@orange.com


_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG adoption and IP poll for draft-snr-bess-pbb-evpn-isid-cmacflush

[Bidgoli, Hooman (Nokia - CA/Ottawa)]

Support

Regards

Hooman

From: BESS  On Behalf Of Sathappan, Senthil (Nokia - 
US/Mountain View)
Sent: Thursday, September 19, 2019 2:05 PM
To: Stephane Litkowski ; bess@ietf.org; 
bess-cha...@ietf.org
Subject: Re: [bess] WG adoption and IP poll for 
draft-snr-bess-pbb-evpn-isid-cmacflush

As a co-author, support the draft for WG adaption. Not aware of any relevant 
IPR.
Thanks,
Senthil.


From: BESS mailto:bess-boun...@ietf.org>> On Behalf Of 
Stephane Litkowski
Sent: Thursday, September 19, 2019 2:12 AM
To: bess@ietf.org; 
bess-cha...@ietf.org
Subject: [bess] WG adoption and IP poll for 
draft-snr-bess-pbb-evpn-isid-cmacflush

Hi,

This email begins a two-weeks WG adoption poll for 
draft-snr-bess-pbb-evpn-isid-cmacflush [1]
Please review the draft and post any comments to the BESS working group list.

We are also polling for knowledge of any undisclosed IPR that applies to this 
Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an author or a contributor of this document, please 
respond to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.
Currently, there are no IPR disclosures against this document.

If you are not listed as an author or a contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.

This poll for adoption closes on 7th October 2019.

Regards,
Stephane and Matthew

[1] https://datatracker.ietf.org/doc/draft-snr-bess-pbb-evpn-isid-cmacflush/
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Second WG Last Call on draft-ietf-bess-evpn-proxy-arp-nd-06

[Bidgoli, Hooman (Nokia - CA/Ottawa)]

Support

Hooman

From: BESS  On Behalf Of Bocci, Matthew (Nokia - GB)
Sent: Friday, June 7, 2019 5:07 AM
To: bess@ietf.org
Cc: bess-cha...@ietf.org; draft-ietf-bess-evpn-proxy-arp...@ietf.org
Subject: [bess] Second WG Last Call on draft-ietf-bess-evpn-proxy-arp-nd-06

WG

We ran a working group last call on this draft in August 2018. Although we had 
an Ops Area review, we did not get a lot of responses from participants who 
were not already authors of the draft. We are therefore running another working 
group last call on draft-ietf-bess-evpn-proxy-arp-nd-06.

Please indicate to the list if you have read the draft and support its 
publication as an RFC. Please also indicate to the list if you have read the 
draft and do not support its publication.

Please also send any other last call comments to the BESS list.

This last call ends on Friday 21st June 2019.

Regards

Matthew and Stephane
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Second WG Last Call on draft-ietf-bess-vpls-multihoming-02

[Bidgoli, Hooman (Nokia - CA/Ottawa)]

Support

Regards

Hooman

From: BESS  On Behalf Of Rabadan, Jorge (Nokia - 
US/Mountain View)
Sent: Monday, September 24, 2018 11:17 AM
To: Bocci, Matthew (Nokia - GB) ; bess@ietf.org
Subject: Re: [bess] Second WG Last Call on draft-ietf-bess-vpls-multihoming-02

I fully support the publication of this document.
It should have been an RFC long time back. I don’t understand why it took so 
long.

Nokia has an implementation of this draft in SROS.

Thanks.
Jorge

From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
"Bocci, Matthew (Nokia - GB)" 
mailto:matthew.bo...@nokia.com>>
Date: Monday, September 24, 2018 at 1:04 PM
To: "bess@ietf.org" mailto:bess@ietf.org>>
Subject: [bess] Second WG Last Call on draft-ietf-bess-vpls-multihoming-02

All

Since we have received a recent IPR declaration on this draft and the first WG 
last call was so long ago, we are running a second last call to reaffirm WG 
consensus to publish the draft as an RFC.

Therefore, this email begins a two-week working group last call for 
draft-ietf-bess-vpls-multihoming-02.txt

Please review the draft and post any comments to the BESS working group list.

Currently there is one IPR declaration against this document.

We are also polling for any existing implementations.

The working group last call closes on Monday 8th Oct 2018.

Regards,
Matthew and Stéphane



___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Last Call (including implem status) for draft-ietf-bess-evpn-ac-df

[Bidgoli, Hooman (Nokia - CA/Ottawa)]

Support

Regards

Hooman

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Dolganow, Andrew (Nokia 
- SG/Singapore)
Sent: Monday, January 29, 2018 4:57 AM
To: stephane.litkow...@orange.com
Cc: draft-ietf-bess-evpn-ac-df.auth...@ietf.org; bess@ietf.org
Subject: Re: [bess] WG Last Call (including implem status) for 
draft-ietf-bess-evpn-ac-df

Support
Andrew

Sent from my iPhone

On Jan 29, 2018, at 4:27 PM, 
"stephane.litkow...@orange.com" 
> wrote:

Hello Working Group,



This email starts a Working Group Last Call on

draft-ietf-bess-evpn-ac-df-03 [1] which is considered mature and

ready for a final working group review.



Please read this document if you haven't read the most recent version

yet, and send your comments to the list, no later than *12th of February*.

Note that this is *not only* a call for comments on the document; it is

also a call for support (or not) to publish this document as an 
Informational

RFC.



In addition, we are also polling for knowledge of any IPR that

applies to draft-ietf-bess-evpn-ac-df, to ensure that IPR has

been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879,

3669 and 5378 for more details).



If you are listed as a document Author or Contributor of the draft

please respond to this email and indicate whether or not you are aware

of any relevant IPR.



Note that, as of today, no IPR has been disclosed against this document

or its earlier versions.



We are **also polling for knowledge of implementations** of part or all

of what this document specifies. This information is expected as per [2].

Please inform the mailing list, or the chairs, or only one of the chairs.



Thank you,

Stephane & Martin



[1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-ac-df/

[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw






_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess