Re: [bess] New draft "draft-hr-spring-intentaware-routing-using-color"

[Dhananjaya Rao (dhrao)]

Hi Igor,

Thank you for the quick review. Please see inline (DR##)

From: BESS  on behalf of Igor Malyushkin 

Date: Sunday, July 17, 2022 at 2:50 AM
To: "Dhananjaya Rao (dhrao)" 
Cc: "bess@ietf.org" 
Subject: Re: [bess] New draft "draft-hr-spring-intentaware-routing-using-color"

Accidently unicasted the previous message to Dhananjaya, replying to the group.

Hello Dhananjaya,

Can you please clarify some moments in Section 6.2? First, I don't see any sign 
of Section 5.1.9 (also referred to in Section 6.3.1.7) in the document. Looks 
like missed.

DR ## Thanks; yes, it was a reference to Section 5.9. Missed updating during 
conversion. Will be fixed in next revision.

I'm interested in the next scenario. Let's suppose that for a service instance 
(VPN or a global table) there are two ingress flows per single destination. 
This destination is color-marked and resolved by an intent-aware underlay. 
Also, there is a best-effort path as a fallback. Using per-flow steering that 
is based on 5-tuple IP flow is it possible to send ingress traffic from a 
source S1 via the intent-aware path, and ingress traffic from a source S2 via a 
fallback (best-effort) path at the same time? My reading of Section 6.2 shows 
me that it's not possible. But I strongly believe that there are cases when an 
intent/colored path for a distinct destination must be used only by the subset 
of members of service, and the same destination must be available for the rest 
members of the service via a best-effort path(s) only. I can show some business 
logic behind this if you will.

DR## Sending one IP flow for a destination via an intent-aware path while 
sending another flow for the same destination via a best-effort path (or a 
different intent-aware path) is a valid use-case, which is intended to be 
covered. It was described more explicitly in  
https://datatracker.ietf.org/doc/draft-dskc-bess-bgp-car-problem-statement/  
Section 1.2.11, but reduced in the merged doc. We can make it more explicit.

In fact, this scenario is already supported by existing intent-aware solutions 
such as SR-TE :

https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-22#section-8.6

Regards,
-Dhananjaya


Hope it helps, and thank you!

сб, 16 июл. 2022 г. в 07:15, Dhananjaya Rao (dhrao) 
mailto:40cisco@dmarc.ietf.org>>:

Hello BESS folks,

The co-authors of 
https://datatracker.ietf.org/doc/draft-dskc-bess-bgp-car-problem-statement/ and 
https://datatracker.ietf.org/doc/draft-hegde-spring-mpls-seamless-sr/ have 
published a merged problem statement document :

https://datatracker.ietf.org/doc/draft-hr-spring-intentaware-routing-using-color/

We request working group to review and provide your inputs.

Regards,
-Dhananjaya (for the co-authors)


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

Re: [bess] [Idr] New draft "draft-hr-spring-intentaware-routing-using-color"

[Dhananjaya Rao (dhrao)]

Hi Robert,

Thank you for the rapid review and insightful comments, as usual.

Please see inline (DR##)

From: Robert Raszuk 
Date: Saturday, July 16, 2022 at 4:18 PM
To: "Dhananjaya Rao (dhrao)" 
Cc: "i...@ietf.org" 
Subject: Re: [Idr] New draft "draft-hr-spring-intentaware-routing-using-color"

Hello Dhananjaya,

I have a few higher level questions/comments in respect to the shared document.

#1 - Any well design service will very often try use multiple *independent* 
(ie. not closely cooperating administration) transits. It surprises me that 
none of the documents are trying to normalize at least a few colors such that 
intent aware transit across independent parties can be comparable by end 
customers.

DR## Apt point. In fact, a similar comment has been made by a couple of other 
collaborators as well. Certain well-known common services could in fact be 
assigned well-known colors for use across providers (or independent transits as 
you stated). The analogy was to the current well-known BGP Communities.

The current version does not venture into this aspect. It can certainly be 
included in the document. We would welcome further inputs on it.


#2 - I love requirements as listed in 6.3.3 ! Note that many networks today are 
light years from meeting those requirements. So what this section is 
essentially saying is - if you do not meet those basic requirements forget 
about interaware transit. This is good.

DR## Ack. All requirements may not apply to all intents, and there likely will 
be considerations of trade-offs when enabling them in networks.

#3 - I am disappointed that the presented document does not say a word about 
intent/color to other color(s) or to best effort fallbacks. IMO I think it is 
extremely important and in fact should be part of dynamic signalling.

DR## Can you check the Steering requirements section 6.2 ?
It does include fallback to different colors / best effort. Please do comment .

#4 - How colors are reflected in routing ? In other words if I want to transit 
over paths which do not use satellite links and suddenly there is failure of 
all critical terrestrial paths how do I get as the end customer signalled that 
? Is my unicast route getting withdrawn ? In fact the document does not say 
what are the requirements for the customer CE. All pictures start from PE :).  
Do I as a client need to participate in color aware routing at all ? Or is the 
mapping to a colorful path happening on the provider's edge based on something 
in the packet ?

DR## FWIW, 
https://datatracker.ietf.org/doc/draft-dskc-bess-bgp-car-problem-statement/ did 
have a section (3.2) on VPN Service intent requirements, which covered 
extending intent-aware routing to the CE (and possibly beyond). These may not 
capture all possibilities – if you have suggestions, we will consider them.

Since this current document is a merged effort, it has taken considerable time 
to agree on the content and text that should be included. Hence those 
requirements are not captured in the current version. But they should be 
included in upcoming versions, once reviewed.

#5 - The entire architecture here seems to be locked to transit or connectivity 
service provided by a single set of closely cooperating administration. But as 
we all know more and more connectivity is moving (or has already moved) to 
SD-WAN or NaaS using native best effort transits provided by a number of ISPs 
in the underlay. It is either the edge nodes or even apps to detect the best 
quality end to end path and steer the traffic accordingly. Yet these 
discussions here about color aware transports are sort of stuck with the 
network model where there is a customer attaching to a single SP and using it 
for connectivity service. Is this still so relevant nowadays ? Of course there 
are networks which do all of those color aware forwarding all by themselves 
under a given administrative umbrella. But do they need IETF to define a subset 
of what they have already deployed and operational for years ?

DR## The VPN / Service requirements in the CAR problem statement did anticipate 
a use-case would be SD-WAN or other transit services, of course still carried 
over a intent-aware provider transit network to ensure the desired intent is 
achieved. I agree the scope can be widened.

Regards,
-Dhananjaya

Kind regards,
Robert


On Sat, Jul 16, 2022 at 7:14 AM Dhananjaya Rao (dhrao) 
mailto:40cisco@dmarc.ietf.org>> wrote:


Hello IDR folks,

The co-authors of 
https://datatracker.ietf.org/doc/draft-dskc-bess-bgp-car-problem-statement/ and 
https://datatracker.ietf.org/doc/draft-hegde-spring-mpls-seamless-sr/ have 
published a merged problem statement document :

https://datatracker.ietf.org/doc/draft-hr-spring-intentaware-routing-using-color/

We request working group to review and provide your inputs.

Regards,
-Dhananjaya (for the co-authors)



___
Idr mailin

[bess] New draft "draft-hr-spring-intentaware-routing-using-color"

[Dhananjaya Rao (dhrao)]

Hello BESS folks,

The co-authors of 
https://datatracker.ietf.org/doc/draft-dskc-bess-bgp-car-problem-statement/ and 
https://datatracker.ietf.org/doc/draft-hegde-spring-mpls-seamless-sr/ have 
published a merged problem statement document :

https://datatracker.ietf.org/doc/draft-hr-spring-intentaware-routing-using-color/

We request working group to review and provide your inputs.

Regards,
-Dhananjaya (for the co-authors)


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

Re: [bess] IPR call for draft-dskc-bess-bgp-car-03 (3/4 to 3/10) - Prior to adoption of CAR/CT solutions

[Dhananjaya Rao (dhrao)]

Hello Sue,

I’m not aware of any IPR.

On a related note, we had requested adoption of the BGP CAR draft at the IDR 
interim on Jan 24. Would you want us to send another email for it, or would 
this note suffice ?

Regards,
-Dhananjaya

From: BESS  on behalf of Susan Hares 
Date: Friday, March 4, 2022 at 1:24 AM
To: "bess@ietf.org" , "i...@ietf.org" 
Cc: "spring-cha...@ietf.org" 
Subject: [bess] IPR call for draft-dskc-bess-bgp-car-03 (3/4 to 3/10) - Prior 
to adoption of CAR/CT solutions

Greetings Bess and IDR:

The IDR chairs request that each of the authors of
draft-dskc-bess-bgp-car-03.txt.
submit an IPR statement in response to this email.
The motivation for this IPR call is below.

We expect IPR responses from the authors:
Dhananjaya Rao, Swadesh Agrawal, Clarence Filsfils,
 Ketan Talaulikar, Dirk Steinberg, Luay Jalil,
Yuanchao Su, Bruno Decraene, Jim Guichard,
Keyur Patel, Haibo Wang


There is one  IPR filed against this draft:
https://datatracker.ietf.org/ipr/4844/
Motivation for IPR call
==

Why are the IDR calling for IPR statements?
The authors of draft-kaliraj-idr-bgp-classful-transport-planes-13.txt
have asked for WG Adoption.

We have two drafts that are discussing embedded NLRI (color).
draft-dskc-bess-bgp-car-03.txt
https://datatracker.ietf.org/doc/draft-dskc-bess-bgp-car/
and
draft-kaliraj-idr-bgp-classful-transport-planes-13.txt

https://datatracker.ietf.org/doc/draft-kaliraj-idr-bgp-classful-transport-planes/

Since the IDR chairs know these drafts may overlap,
we expect to work closely with the bess-chairs, spring-chairs,
IDR WG, and BESS WG any WG adoption  and WG LC.

Other Discussions
==
IDR WG held an interim on 1/24/2022 that discussed these two drafts:
The minutes are at:
https://datatracker.ietf.org/meeting/interim-2022-idr-02/materials/minutes-interim-2022-idr-02-202201241000-01


Jeff has started two mail threads for CAR/CT drafts based on 2 Questions:
Question 1: BGP routes with color, Question 1: How does route resolution work 
with your feature?
https://mailarchive.ietf.org/arch/msg/idr/OaNnE5epcaK7GtcV8OlAVdD3ZbI/

Question 2: BGP routes with color, Question 2: Route origination and propagation
https://mailarchive.ietf.org/arch/msg/idr/4MYIFyHWITj8-Kk38AmKlkhh5b8/

Kaliraj began discussion on this email on IDR:
https://mailarchive.ietf.org/arch/msg/idr/_RB9Md01RXUPQ5g-8hzOfJPhT7k/


The BESS email discussion regarding CAR (11/18/2021 to 1/24/2022) can be found 
at:

https://mailarchive.ietf.org/arch/msg/bess/_9oTLaod7z9o_1SYEai0tN5b0EM/


Sue Hares
IDR chair
Document Shepherd

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

Re: [bess] Questions/concerns about BGP Color-Aware Routing (CAR)

[Dhananjaya Rao (dhrao)]

Hello Srihari,

Thank you for your review of the BGP CAR proposal and comments. My apologies 
for the delayed response.

I’d like to mention that some of your comments are similar to ones made earlier 
by your colleague(s), and we’d responded to them with the necessary 
clarifications. However, I will attempt to address them again here.

To reiterate, BGP-CAR is fundamentally an evolution of the BGP-LU paradigm. It 
extends a regular IP prefix with a color since the goal is to support intent 
specific routing to given network endpoint. It is operationally and 
procedurally consistent with BGP-LU.

As such, its way simpler than forcing the IP-VPN paradigm into underlay routing 
as BGP-CT does which brings with it unnecessary overhead and suboptimal 
behaviors as we have commented before.

The objections you pose primarily target the extensibility we’ve defined as 
part of the BGP-CAR NLRI. But those are in some cases incorrect, and in other 
cases unfounded or even vague claims of complexity IMHO. I will try to clarify 
once more inline. That said, we’ll be glad to discuss any valid critiques and 
concrete suggestions for improvement.

Since we are defining a new SAFI to accommodate the color specific NLRI, it is 
apropos to introduce a modern, extensible NLRI definition. Precisely because 
it’s a new SAFI that will be turned on in transport networks.

The NLRI design not only addresses specific operational scenarios that we have 
come across efficiently, but also enables additional extensions to be 
accommodated in future, flexibly and efficiently.

If the goal was to introduce no changes at all or to intentionally retrofit an 
existing SAFI, then BGP-LU alone could be deployed with a separate underlay IP 
assigned for each color or intent. There isn’t a need to do much more IMHO.

Also, we once again respectfully disagree that the CAR NLRI definitions are a 
fundamental change to BGP. Plenty of existing BGP SAFIs have introduced similar 
extensions to NLRI – starting with BGP-LU for label/label-stack to EVPN with 
route-type specific definitions and BGP-LS with TLVs, to name a few.

Rather than make the CAR NLRI extensions hardwired, we are taking the 
opportunity to provide a structured definition with a route-type and TLVs for 
per-route data such as label, SID, prefix-SID etc. Not a fundamental change. 
And there are no rules in IDR that non-key info or TLVs are disallowed in a BGP 
NLRI. Fears regarding arbitrary misuse are misplaced since any definitions do 
go through IDR WG review.

Please also see some of the specific clarifications inline (DR>>)


From: Srihari Sangli 
Date: Tuesday, December 14, 2021 at 10:13 PM
To: "draft-dskc-bess-bgp-...@ietf.org" , 
"i...@ietf.org" , "bess@ietf.org" 
Subject: Re: Questions/concerns about BGP Color-Aware Routing (CAR)
Resent-From: 
Resent-To: , , 
, , , 
, , , 
, , 
Resent-Date: Tuesday, December 14, 2021 at 10:13 PM

Hello,

I am not sure if my email reached the authors and hence resending my email. I 
would like to know the comments from the authors of draft-dskc-bess-bgp-car 
draft. Thanks.

Thanks & Regards,

srihari…


From: Srihari Sangli 
Date: Thursday, 18 November 2021 at 1:06 PM
To: "draft-dskc-bess-bgp-...@ietf.org" , 
"i...@ietf.org" , "bess@ietf.org" 
Subject: Questions/concerns about BGP Color-Aware Routing (CAR)


Hi, Folks:



This is regarding draft-dskc-bess-bgp-car-03 . I have reviewed the previous 
presentations & discussions on IDR wg meetings and mailer. In preparation for 
the upcoming IDR interim, I am raising concerns about CAR proposal to establish 
end-to-end intent-aware paths. Can the authors of the draft respond to these.



IMO BGP CAR is an overkill for what we need.  Some of the proposed changes in 
CAR proposal look to me as pretty fundamental to BGP. While “any” protocol 
extensions are possible, IMHO we should review the trade-offs. I see the CAR 
authors are trying to solve the same problem that BGP Classful Transports aka 
BGP-CT solves in a different way. My objection is – while we want to provide 
alternative solution to classful transports, we don’t want to take BGP protocol 
constructs to orthogonal direction which is not good for both operators and 
vendors.



Personally, when I compare BGP CAR to BGP-CT, the BGP-CT is a natural extension 
of existing IP-VPN mechanism. I have not seen much discussion on what’s missing 
in BGP-CT and I’m sure more discussions may lead to improvements (if any) in 
that proposal.  I propose we review BGP CT proposal and provide suggestions to 
improve it. It seems better bang for buck than introducing new concepts in BGP 
which seems suboptimal and complexity from protocol extensions.



DR>> I’ve addressed this in the introductory responses above. The IP-VPN model 
is not a suitable model nor necessary.



Following is the list comments/objections (not a complete list) to the CAR 
proposal. Please see below for more details.



1.   Color ambiguity: As per details in section 2.9

Re: [bess] WG adoption poll and IPR poll for draft-mohanty-bess-ebgp-dmz-03 [1].

[Dhananjaya Rao (dhrao)]

I support adoption; it’s useful work.

Regards,
-Dhananjaya

From: BESS  on behalf of "Bocci, Matthew (Nokia - GB)" 

Date: Tuesday, September 7, 2021 at 5:42 AM
To: "bess@ietf.org" 
Cc: "draft-mohanty-bess-ebgp-...@ietf.org" 

Subject: [bess] WG adoption poll and IPR poll for 
draft-mohanty-bess-ebgp-dmz-03 [1].

Hello,

This email begins a two-week WG adoption poll for 
draft-mohanty-bess-ebgp-dmz-03 [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 September 21st 2021.

Regards,
Matthew and Stephane


[1] https://datatracker.ietf.org/doc/draft-mohanty-bess-ebgp-dmz-03/


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

Re: [bess] [Idr] Comments, review of - draft-dskc-bess-bgp-car-01 presentation

[Dhananjaya Rao (dhrao)]

Hi Kaliraj,

Thank you for reviewing the BGP CAR draft and your comments. I am top posting 
my responses for better readability since the comments were quite long ☺

1.
BGP CAR extends existing BGP-LU flat hop-by-hop routing semantics by adding 
color-awareness to the NLRI. This approach addresses the requirement for 
diverse color-aware paths using the simplest and most efficient design.

We find this simplicity beneficial both for an implementation and more 
importantly for deployment.

2.
We don’t see a need for using L3VPN semantics with RD/RT and import/export at 
every underlay hop.

While using RD may have been a convenience as you stated, it brings unnecessary 
complexity and limitations.

A good example is the inability to achieve multipathing at an ingress BR (e.g., 
ABR3) within the local domain when two egress ABRs originate BGP routes for a 
PE with different RDs. This leads to slower traffic convergence since an egress 
ABR failure (e.g., ABR1) will need to be propagated across the domains all the 
way to an ingress PE before that path stops getting used. It also causes 
unnecessary churn across multiple domains. (See simplified topology below)


  _ _ --- 
ABR1 ---
 PE1 –( _ _  ) --- ABR3 --|
|--- PE2
--- 
ABR2 ---

The CAR proposal does not have this limitation.

3.
From your comments, there appears to be a basic misunderstanding of the CAR 
proposal and the presentation.

We refer to the solution architecture described in 
[draft-ietf-spring-segment-routing-policy] as the deployed SR-TE solution. It 
specifies a pull model  for a PE (policy head-end) 
to query SR-PCE and get a path with label-stack or SID-list in response. This 
avoids the PE needing to learn any state for all remote PEs by default.

You seem to assume a narrow reference to [ietf-idr-segment-routing-te-policy] 
which is not correct. The BGP-TE SAFI defined there is simply a means to enable 
a controller to signal a path for a policy to a specific SR policy headend 
using BGP instead of PCEP (see Section 2.3 of 
[draft-ietf-spring-segment-routing-policy]).

BGP CAR is regular BGP distribution for hop-by-hop routing (ala BGP-LU), but 
with color/intent-awareness. However, the data model defined for BGP CAR is 
inherently consistent with the one defined for SR-policy regardless of protocol.

4.
Mixing key and non-key values in BGP NLRI is not new, it’s been there since 
RFC3107 (label/label-stack) at least. Other SAFIs have had this too, for 
example, EVPN. There are cases of both fixed and variable values.

In the CAR proposal, we added structured TLVs to support multiple values and 
extensibility, instead of adding ad-hoc definitions and overloading of fields. 
It reduces complexity and provides for consistent handling.

That said, as I mentioned during the presentation, we have received suggestions 
for alternative encoding, and are evaluating them.

5.
Inherently, there is a variable degree of packing with BGP updates. That does 
not mean one should break it by default.

Similarly, just because we are being fore sighted by defining an extensible 
NLRI does not mean that it will invariably lead to a worst-case scenario ☺

Any extensions, such as new route-types that are proposed will go through WG 
review which should ensure proper gatekeeping. Again, there is precedence for 
this with other SAFIs.

And thank you for acknowledging that having route-types is acceptable.

6.
The CAR proposal does support domains with different color diversity. The 
Appendix describes a few examples.

7.
I will defer responding to the specific use-case and filtering comments since 
they are not yet specified in the draft. It will be much easier to discuss once 
we post them. Just a quick comment that the proposal does not at all preclude 
supporting anycast use-cases.

Thank you again for your patient review of the proposal and your feedback.

Regards,
-Dhananjaya






Hi CAR authors,



Thanks for the presentations in IDR and BESS meetings at IETF-110 last week.



We could not discuss in detail during the session because of time constraints. 
So

sharing my comments to the mailing lists.



Starting with follow-up on what Ketan mentioned in the IDR meetecho chat,

regarding SRTE is pull model vs CAR is push model:



I wanted to clarify, that may not be accurate. SRTE is also push model. PCE

provides the ‘pull’ part, which SRTE responds to. So, I think the question

Linda was alluding to remains.



viz: Why do we need another SRTE like family, when we have SRTE already?



Further, following are my own thoughts on the CAR encoding proposal, and 
challenges:



1/ The claim on better packing, and NLRI extensibility:



IMHO, micro-optimizing the NLRI wanting to support better packing introduces 
complexity in

a different dimension. Mixing ke

Re: [bess] About draft-dskc-bess-bgp-car

[Dhananjaya Rao (dhrao)]

Hi Jorge,

Thank you once again for reviewing the draft and for your feedback.

We will update the security considerations in a newer version.

The use of transposition here is to be efficient in bytes consumed in each NLRI 
when multiple routes have shared information such as locator. It provides 
flexibility to encode the common locator portion of SRv6 SIDs in the attribute. 
We will clarify with an example in the newer version.

Regards,
-Dhananjaya

On 3/10/21, 7:03 AM, "BESS on behalf of Rabadan, Jorge (Nokia - US/Mountain 
View)"  wrote:

DJ, Swadesh,

Thanks for your time about these two drafts during the BESS session.
I just wanted to follow up on the two comments I made:

1) About this and the security section

   “The indication of the key length enables BGP Speakers to determine
   the key portion of the NLRI and use it along with the NLRI Type field
   in an opaque manner for handling of unknown or unsupported NLRI
   types.  This can help Route Reflectors (RR) to propagate NLRI types
   introduced in the future in a transparent manner.”

As discussed, this brings a potential security risk, since, for unknown 
route types, the RR only validates the key length without understanding if the 
content is wrong or not for the route type. I think DJ agreed this has to be 
discussed into the Security section (which by the way does not exist in the 
document in rev 01 __).


2) About the srv6 tlv and transposition:

"o  SRv6 SID Information: field of size as indicated by the length
  that either carries the SRv6 SID(s) for the advertised color-aware
  route as one of the following:

  *  A single 128-bit SRv6 SID or a stack of 128-bit SRv6 SIDs

  *  A transposed portion (refer [I-D.ietf-bess-srv6-services]) of
 the SRv6 SID that MUST be of size in multiples of one octet and
 less than 16."

@Swadesh, in the srv6-services draft, transposition is used for efficient 
packing, which *should not* be an issue here since the srv6 tlv is part of the 
NLRI (at least for 1 SID). I 'suspect' the use case here is to *save* some 
bytes when a stack of SIDs need to be advertised with the BGP CAR route, and 
those SIDs have a few common bytes in the locator part? it would be good if you 
can clarify please.

Thank you!
Jorge

___
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

Re: [bess] WGLC and IPR poll on draft-ietf-bess-evpn-ipvpn-interworking-03

[Dhananjaya Rao (dhrao)]

I support the publication of this draft.

I do have a few proposed updates to the draft that would help clarify aspects 
of usage of the Domain-Path. I’ve noted them below for the co-authors to 
consider.

Section 3.

1.  About the BGP D-PATH attribute:
a)  ….
Old: This attribute list may contain zero, one or more segments.

New: This attribute list may contain one or more segments.


2.  c)
Old: The gateway PE MUST NOT add the D-PATH attribute to ISF routes generated 
for IP-VRF prefixes that are not learned via any ISF SAFI, for instance, local 
prefixes.

New: A gateway PE can generate ISF routes for IP-VRF prefixes that are not 
learned via any ISF SAFI, for instance, local prefixes (such as OSPF or 
static). It may distribute the routes to other GW-PEs via an ISF SAFI in one 
domain, considered to be the originating domain. Hence, it MAY add the D-PATH 
attribute to ISF routes advertised in an ISF SAFI to other domains, in order to 
prevent the route from looping back into the originating domain via the other 
GW-PEs.

3.  d)
Old: An ISF route received by a gateway PE with a D-PATH attribute that 
contains one or more of its locally configured domains for the IP-VRF is 
considered to be a looped ISF route and MUST be dropped.

New: An ISF route received by a gateway PE with a D-PATH attribute that 
contains one or more of its locally configured domains for the IP-VRF is 
considered to be a looped ISF route and not installed in that IP-VRF nor 
re-advertised from it.

4.  e)
Old: The number of domains in the D-PATH attribute indicates the number of 
gateway PEs that the ISF route update has transited.

New: The number of domains in the D-PATH attribute indicates the number of 
tenant IP-VRFs on gateway PEs that the ISF route update has transited.

5.  f)
Old: None

New: For ease of configuration, a Domain-ID value on a GW-PE may be assigned 
globally for a peering domain in which case it applies to all tenant networks 
for that domain. However, a Domain-ID may be scoped granularly for an 
individual tenant IP-VRF. One example where a per-IP-VRF domain-ID assignment 
is necessary is when routes received from one domain are leaked from one IP-VRF 
to another and re-advertised back to the same domain, where it must be accepted 
and not treated as a looped route in the new tenant IP-VRF.

Example :
  VPN [Domain1]   GWPE1    EVPN [Domain2] - GWPE2
  ID-6500:1VRF11 ID-6500:2  
  VRF21  

| (route-leak)
  ID-6500:4VRF12 ID-6500:3  
 VRF22  -

[Note for authors : This point is to remove ambiguity about the scope of the 
Domain-ID.
f) could be swapped in order with e) ]

Section 3.1

6.  Old: Gateway GW1 flags the SAFI 128 route as a loop, and does not 
re-advertise it …
New: Gateway GW1 flags the SAFI 128 route as a loop in the tenant IP-VRF, and 
does not re-advertise it…


Regards,
-Dhananjaya

From: BESS  on behalf of "slitkows.i...@gmail.com" 

Date: Monday, November 9, 2020 at 12:20 AM
To: "bess@ietf.org" , 
"draft-ietf-bess-evpn-ipvpn-interwork...@ietf.org" 

Subject: [bess] WGLC and IPR poll on draft-ietf-bess-evpn-ipvpn-interworking-03

Hello WG,

This email starts a three weeks Working Group Last Call on 
draft-ietf-bess-evpn-ipvpn-interworking-03 [1]. We add an additional week due 
to the upcoming IETF meeting.

This poll runs until * the 30th Of  November *.


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 is currently no IPR disclosed.



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.



We are also polling for any existing implementation as per [2].



Thank you,

Stephane & Matthew

[1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-ipvpn-interworking/
[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] WG Adoption and IPR Poll for draft-sajassi-bess-evpn-virtual-eth-segment-03

[Dhananjaya Rao (dhrao)]

Support.

From: BESS  on behalf of "Bocci, Matthew (Nokia - GB)" 

Date: Friday, June 1, 2018 at 5:48 AM
To: "bess@ietf.org" 
Cc: "draft-sajassi-bess-evpn-virtual-eth-segm...@ietf.org" 

Subject: Re: [bess] WG Adoption and IPR Poll for 
draft-sajassi-bess-evpn-virtual-eth-segment-03

We’ve only had a couple of responses from people who are not co-authors of the 
draft. It would be good to see some wider interest, so please review the draft 
and indicate to the list if you support adoption or not, especially if you are 
not a co-author. I will extend the poll for adoption for another week, 
accordingly.

Thanks to those who have already commented.

Regards

Matthew and Stephane

From: BESS  on behalf of "Bocci, Matthew (Nokia - GB)" 

Date: Thursday, 17 May 2018 at 11:24
To: "bess@ietf.org" 
Cc: "draft-sajassi-bess-evpn-virtual-eth-segm...@ietf.org" 

Subject: [bess] WG Adoption and IPR Poll for 
draft-sajassi-bess-evpn-virtual-eth-segment-03

This email begins a two-week poll for adoption of 
draft-sajassi-bess-evpn-virtual-eth-segment-03.txt

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 is one IPR declaration 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 Thursday 31st May 2018.

Regards,
Matthew and Stéphane

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

Re: [bess] WG adoption and IPR poll for draft-sajassi-bess-evpn-fast-df-recovery-02

[Dhananjaya Rao (dhrao)]

As co-author, I support the document for WG adoption.
Not aware of any IPR relevant to this document.

Regards,
-Dhananjaya


From: BESS  on behalf of "stephane.litkow...@orange.com" 

Date: Monday, May 14, 2018 at 2:48 AM
To: "bess@ietf.org" 
Subject: [bess] WG adoption and IPR poll for 
draft-sajassi-bess-evpn-fast-df-recovery-02

Hi WG,

This email begins a two-week poll for BESS working group adoption of 
draft-sajassi-bess-evpn-fast-df-recovery-02 [1].

Please review the draft and post any comments to the BESS working group list, 
stating whether or not you support adoption.

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.

If you are 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.

The poll for working group adoption closes on Monday 28th May.

Regards,
Stéphane and Matthew

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



[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] Poll for adoption: draft-fm-bess-service-chaining-02

[Dhananjaya Rao (dhrao)]

Hi Martin,

As co-author, I support adoption of this draft. I am not aware of any
related IPR apart from the ones that have been disclosed.
 

Thanks,
-Dhananjaya



On 2/22/16, 8:58 AM, "BESS on behalf of Martin Vigoureux"
 wrote:

>Hello working group,
>
>This email starts a two-week poll on adopting
>draft-fm-bess-service-chaining-02 [1] as a working group Document.
>
>Please state on the list if you support adoption or not (in both cases,
>please also state the reasons).
>
>This poll runs until *the 7th of March*.
>
>Note that IPR has been disclosed against an earlier version of this
>document:
>https://datatracker.ietf.org/ipr/2284/
>
>Yet, we are *coincidentally* also polling for knowledge of any other
>IPR that applies to this draft, 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 please
>respond to this email and indicate whether or not you are aware of any
>relevant IPR.
>
>The draft will not be adopted until a response has been received from
>each author and contributor.
>
>If you are not listed as an author or contributor, then please
>explicitly respond only if you are aware of any IPR that has not yet
>been disclosed in conformance with IETF rules.
>
>Thank you,
>
>Martin & Thomas
>bess chairs
>
>[1] https://datatracker.ietf.org/doc/draft-fm-bess-service-chaining/
>
>___
>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

Re: [bess] Poll for adoption: draft-fm-bess-service-chaining-02

[Dhananjaya Rao (dhrao)]

Hello Martin, WG,

It came to our notice recently that there was an old IPR filing on an
earlier related draft that had not been submitted to the IETF. An IPR
statement has now been submitted and is in progress. This was an
inadvertent oversight, and we apologize for the late disclosure.

Regards,
-Dhananjaya



On 2/22/16, 8:58 AM, "BESS on behalf of Martin Vigoureux"
 wrote:

>Hello working group,
>
>This email starts a two-week poll on adopting
>draft-fm-bess-service-chaining-02 [1] as a working group Document.
>
>Please state on the list if you support adoption or not (in both cases,
>please also state the reasons).
>
>This poll runs until *the 7th of March*.
>
>Note that IPR has been disclosed against an earlier version of this
>document:
>https://datatracker.ietf.org/ipr/2284/
>
>Yet, we are *coincidentally* also polling for knowledge of any other
>IPR that applies to this draft, 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 please
>respond to this email and indicate whether or not you are aware of any
>relevant IPR.
>
>The draft will not be adopted until a response has been received from
>each author and contributor.
>
>If you are not listed as an author or contributor, then please
>explicitly respond only if you are aware of any IPR that has not yet
>been disclosed in conformance with IETF rules.
>
>Thank you,
>
>Martin & Thomas
>bess chairs
>
>[1] https://datatracker.ietf.org/doc/draft-fm-bess-service-chaining/
>
>___
>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

Re: [bess] Poll for adoption: draft-fm-bess-service-chaining-02

[Dhananjaya Rao (dhrao)]

Hi Wim,

Thanks again for the support and your suggestions. I believe we did
address them in the latest version, but I¹ll check again.

Regards,
-Dhananjaya


On 2/22/16, 12:54 PM, "BESS on behalf of Henderickx, Wim (Nokia - BE)"
 wrote:

>I support adoption as WG doc but none of my questions have been addressed
>so far
>
>
>
>
>On 22/02/16 17:58, "BESS on behalf of Martin Vigoureux"
> wrote:
>
>>Hello working group,
>>
>>This email starts a two-week poll on adopting
>>draft-fm-bess-service-chaining-02 [1] as a working group Document.
>>
>>Please state on the list if you support adoption or not (in both cases,
>>please also state the reasons).
>>
>>This poll runs until *the 7th of March*.
>>
>>Note that IPR has been disclosed against an earlier version of this
>>document:
>>https://datatracker.ietf.org/ipr/2284/
>>
>>Yet, we are *coincidentally* also polling for knowledge of any other
>>IPR that applies to this draft, 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 please
>>respond to this email and indicate whether or not you are aware of any
>>relevant IPR.
>>
>>The draft will not be adopted until a response has been received from
>>each author and contributor.
>>
>>If you are not listed as an author or contributor, then please
>>explicitly respond only if you are aware of any IPR that has not yet
>>been disclosed in conformance with IETF rules.
>>
>>Thank you,
>>
>>Martin & Thomas
>>bess chairs
>>
>>[1] https://datatracker.ietf.org/doc/draft-fm-bess-service-chaining/
>>
>>___
>>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

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

Re: [bess] WG adoption poll - draft-fang-l3vpn-virtual-pe-05

[Dhananjaya Rao (dhrao)]

I support the adoption, as a co-author. I am not aware of any relevant IPR.

- Dhananjaya

-- Forwarded message --
From: Martin Vigoureux 
mailto:martin.vigour...@alcatel-lucent.com>>
Date: Sun, Oct 19, 2014 at 3:00 PM
Subject: WG adoption poll - draft-fang-l3vpn-virtual-pe-05
To: l3...@ietf.org


Hello Working Group,

This email starts a two-week poll on adopting
draft-fang-l3vpn-virtual-pe-05 [1].

Please send comments to the list and state if you support adoption or
not (in both cases please also state the reasons).

This poll runs until November the 3rd.


Coincidentally, we remind you to check and then state on this list if you are 
aware, or not, of any undisclosed IPR (according to IETF IPR rules, see RFCs 
3979, 4879, 3669 and 5378 for more details) relating to 
draft-fang-l3vpn-virtual-pe-05

If you are listed as a document author or contributor please respond to
this email and state whether or not you are aware of any relevant
IPR. The response needs to be sent to the L3VPN WG mailing list. The document 
will not advance to the next stage until a response has been
received from each author and contributor.

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

Thank you

M&T

---
[1] http://tools.ietf.org/html/draft-fang-l3vpn-virtual-pe-05


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