[bess] Re: Short new WGLC and IPR poll for draft-ietf-bess-evpn-ipvpn-interworking-12

[Gyan Mishra <[e-mail]>]

Agreed. I am good.

Thank you

Gyan

On Mon, Feb 3, 2025 at 8:31 AM Jorge Rabadan (Nokia) <
[e-mail]> wrote:

> Hi Gyan,
>
>
>
> The key difference between a regular and a composite domain is that in a
> composite domain, multiple ISF SAFIs are used to advertise ISF prefixes of
> an IP-VRF, whereas a regular domain uses only one. As discussed in the case
> of gateway procedures for regular domains, the procedures on composite PEs
> remain unchanged regarding how they advertise EVPN and/or IPVPN routes for
> a given encapsulation.
>
>
>
> Regarding the wording of “reorigination” versus “readvertisement” — it
> depends on the perspective IMO.
>
>
>
> Consider Figure 2, where PE1 advertises an EVPN VXLAN IP Prefix route for
> 10.0.0.0/24. GW1 imports 10.0.0.0/24 into the IP-VRF route table and then
> reoriginates an IPVPN route, treating the prefix as if it were locally
> learned (from the perspective of IPVPN, although if needed you can
> ‘propagate’ some bgp path attributes between SAFIs as discussed in section
> 5).
>
>
>
> From the perspective of how the route is advertised to a BGP peer with its
> encapsulation parameters, this is a reorigination, as discussed, and it
> follows existing specifications. However, from the viewpoint of the prefix
> and certain path attributes, the route is effectively propagated through
> the gateways all the way to PE2.
>
>
>
> Personally, I don’t think it matters much, since the spec is clear. The
> proof is that it has been implemented by multiple vendors (at least 5
> implementations that I’m aware of) and interoperability has been proven for
> a few years now. So I don’t think there is ambiguity in the text.
>
> Thanks.
>
> Jorge
>
>
>
>
>
> *From: *Gyan Mishra <[e-mail]>
> *Date: *Friday, January 31, 2025 at 9:29 PM
> *To: *Jorge Rabadan (Nokia) <[e-mail]>
> *Cc: *Stephane Litkowski (slitkows) <slitkows=[e-mail]>,
> [e-mail] <
> [e-mail]>, [e-mail] <
> [e-mail]>, Bernier, Daniel <[e-mail]>
> *Subject: *Re: [bess] Short new WGLC and IPR poll for
> draft-ietf-bess-evpn-ipvpn-interworking-12
>
>
>
> *CAUTION:* This is an external email. Please be very careful when
> clicking links or opening attachments. See the URL nok.it/ext for
> additional information.
>
>
>
> Hi Jorge
>
>
>
> In section 7 composite PE with congruent IPVPN & EVPN PEs at the inter
> domain boundary between the domains, I wanted to confirm that this is also
> underlay independent and hence the IPVPN and EVPN prefixes would be
> automatically propagated between domains without any reorigination.
>
>
>
> The composite case applies to this draft below and so could be an
> alternative to draft below drafts service interworking solution.  The other
> alternative I had come up with that I mentioned is inter-as opt-a for 7.2
> service IW.
>
>
>
> Your composite PE section 7 is much better as it’s a single peer.
>
>
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-mpls-interworking-00
>
>
>
> Last question on reorigination versus readvertisement.  We have the new
> paragraph addition which says reorigination but I don’t see anywhere in the
> draft saying reorigination but do see readvertising.  If we are using
> reorigination in the paragraph then then the draft maybe  wherever we say
> readvertising we should change reorigination to match or vice versa.  I
> believe for service interworking there is a reorigination keyword used for
> GW/IW function going from safi-x to safi-y.
>
>
>
> Thanks
>
>
>
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email **[e-mail]* <[e-mail]>
>
> *M 301 502-1347*
>
>
>
>
>
>
>
> On Fri, Jan 31, 2025 at 11:06 PM Gyan Mishra <[e-mail]>
> wrote:
>
>
>
> Hi Jorge
>
>
>
> Please see in-line
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email **[e-mail]* <[e-mail]>
>
> *M 301 502-1347*
>
>
>
>
>
>
>
> On Fri, Jan 31, 2025 at 11:16 AM Jorge Rabadan (Nokia) <
> [e-mail]> wrote:
>
> Hi Gyan,
>
>
>
> Please see in-line.
>
>
>
>
>
> *From: *Gyan Mishra <[e-mail]>
> *Date: *Thursday, January 30, 2025 at 11:19 PM
> *To: *Jorge Rabadan (Nokia) <[e-mail]>
> *Cc: *Stephane Litkowski (slitkows) <slitkows=[e-mail]>,
> [e-mail] <
> [e-mail]>, [e-mail] <
> [e-mail]>, Bernier, Daniel <[e-mail]>
> *Subject: *Re: [bess] Short new WGLC and IPR poll for
> draft-ietf-bess-evpn-ipvpn-interworking-12
>
>
>
> *CAUTION:* This is an external email. Please be very careful when
> clicking links or opening attachments. See the URL nok.it/ext for
> additional information.
>
>
>
> Hi Jorge
>
>
>
> Responses in-line
>
>
>
> On Thu, Jan 30, 2025 at 8:02 AM Jorge Rabadan (Nokia) <
> [e-mail]> wrote:
>
> Hi Gyan,
>
>
>
> Thank you for your comments.
>
> I added this text at the end of the introduction section:
>
>
>
> "The interworking procedures in this document always require creating an
> IP-VRF on the interworking PE. When connecting different domains, the
> interworking PE follows these steps: it receives routes from one domain
> (along with that domain’s encapsulation parameters), installs them in the
> IP-VRF route table, and then reoriginates the routes with the encapsulation
> parameters of the adjacent domain before advertising them. This
> reorigination process ensures that the procedures remain independent of the
> specific transport tunnels used in each domain.”
>
>
>
> I hope it helps.
>
>
>
>    Gyan> I want to make sure I understand the reorigination with the
> gateway function see below:
>
>
>
> So this solution is definitely service interworking with the reorigination
> which makes it underlay protocol independent.  Please mention service
> interworking and transport protocol independence
>
> *[jorge] Since the procedures mention IP-VPN and EVPN AFI-SAFIs, I think
> it is clear that the procedures happen in the context of a VRF, i.e. a
> service. But sure, no issue in adding “service interworking” to the
> clarification text.*
>
>     Gyan> Thank you
>
>
>
>
>
> In a composite domain or PE, IPVPN and EVPN must have different VRF as the
> different SAFI cannot share the same VRF.
>
> *[jorge] Gyan, I have to say that is not true. In our implementations and
> a few others, IP-VRFs support multiple intersubnet forwarding families in
> the same IP-VRF. IPVPN and EVPN (L3) can definitively use the same IP-VRF.
> As described in the text, the IP-VRF in figure 1 can be programmed with ISF
> routes of different types at the same.*
>
>  Gyan> I was not sure and was thinking that using a different VRF would be
> a way to identify an IPVPN peer from EVPN peer, and the reorigination of
> the routes,  however I see now EVPN (L3) can be the same VRF as IPVPN as
> you said.  I was thinking L2/L3 but as this is L3 for both SAFI, as ISF
> routes can be different route types.  Agreed.
>
>
>
> GW
>
> IPVPN = VRF IPVPN
>
> EVPN = VRF EVPN
>
>
>
> Domain 1                     Domain 2
>
> VXLAN                          SRv6
>
>    R1 - EVPN  - GW - PE1 EVPN / IPVPN
>
>
>
> GW receives the EVPN routes on EVPN peer (safi-x) and reoriginates the
> routes on IPVPN peer (safi-y)
>
>
>
> So basically we are just taking the routes from safi-x EVPN peer and
> reoriginating the routes on safi-y IPVPN peer.  In my original examples the
> unicast SAFI on both ends of peering does not require any reorigination
> since it’s the same safi.  However here we are taking the NLRI and
> translating the SAFI from EVPN to IPVPN.  So in that case all the RT-2 mac
> VRF host routes and RT-5 prefix would all get propagated out to PE1 as
> IPVPN routes using the new RT/RD defined for the IPVPN VRF.  Same would
> happen in the opposite direction.  The gateway is configured with
> encapsulation for vxlan domain with NVE tunnnel and also has SRv6 locator
> config and under VRF peer has SRv6 sid allocation mode per-VRF so it’s not
> really underlay independent but underlay dependent since both left vxlan
> domain underlay and right side SRv6 domain are stretched to the GW which is
> siting on both transports.  So in that way it’s doing transport
> interworking by butting up the two adjacent domain types to the GW box.  In
> the case GW box is the VXLAN DCI or ASBR and so sits on the VXLAN side
> already so only have to extend the SRv6 domain over to the GW box on the
> right side.
>
> *[jorge] it is independent of the underlay in the sense that importing
> routes with certain encapsulation parameters and exporting routes with
> certain encapsulation parameters is something specified in other specs and
> this one does not change anything about that termination/origination. For
> instance, import/export of EVPN VXLAN routes is specified in RFC8365, IPVPN
> or EVPN for SRv6 routes is specified in RFC9252 (and so forth)*
>
>     Gyan> Since on the Gateway the link to safi-x on left has the left
> domain encapsulation parameters and the link to safi-y on right has left
> domain different encapsulation parameters so by doing so I can see the
> underlay does not come into play making it underly independent.  I’m in
> agreement.
>
>
>
>
>
> Please let me know if I got it right.
>
>
>
> I modified the paragraph slightly based on my understanding.  Figure 8 is
> a bit confusing for GW diagram.  I would think the GW box since it sits in
> the DC side and is the EVPN Denmark PE to the core it should have EVPN
> MAC-VRF  like Figure 7 being a composite PE.  The diagram shows the NVO
> tunnels on PE1 and PE2 and the stretched MPLS tunnels to the gateway which
> is perfect for the transport interworking.  The point I am making about
> gateway placement is important as it would always sit on the DC side and
> connect to the core PE.  You may have to redraw a bit the diagrams so they
> all match up.
>
> Since you have 2 DC one on left and one on right with core in the middle
> we are missing a few routers.
>
> I would make PE1-4 core boxes.  I would give different names for DC side
> call it leaf for very left and right PE device and add a single GW PE on
> left and right side that connects to PE5 and PE1 and PE2.  On the right
> side GW PE that sits between PE3 PE4 and PE6.  We can clean up figure 9 to
> also have the clear core & dc demark.  The device that connects to the
> gateway PE in the DC call if a leaf.
>
> *[jorge] I believe Figure 8 accurately represents the example we want to
> illustrate. For a given tenant, the Gateways can have a single IP-VRF
> (without a MAC-VRF) and handle IPVPN (RFC 4364) and EVPN IFL (RFC 9136)
> routes within that IP-VRF*
>
>  Gyan> I see now it does since it’s EVPN (L3) and both IPVPN and EVPN
> share the same VRF so the drawing illustrates correctly showing  all nodes
> having IP-VRF.
>
>
>
>
>
> I would label core & dc so you know the demark point for each domain. That
> way it matches as well the paragraph below.
>
>
> "The interworking gateway procedures in this document always require
> creating an IP-VRF on the gateway  PE. When connecting to the core
>  domains, the gateway PE follows these steps: it receives routes from dc
> domain (along with that domain’s dc underlay encapsulation parameters),
> installs them in the MAC-VRF  route table, and then reoriginates the routes
> with the core underlay encapsulation parameters  before advertising them to
> core PE.  This reorigination process as it happens on the core IPVPN peers
> with the underlay encapsulation to core PE, it provides the transport
> interworking congruence dependency on the specific transport tunnel type by
> extending that transport tunnel to the gateway.
>
> *[jorge] The issue with your text is that core and dc domains are only one
> very specific example. This spec covers interworking in any type of
> network. Also, as discussed there is no MAC-VRF involved in the procedures
> for ISF routes. How about:*
>
>
>
> *“The interworking procedures in this document always require creating an
> IP-VRF on the interworking PE. When connecting different domains, the
> interworking PE follows these steps: it receives routes from one domain
> (along with that domain’s encapsulation parameters), installs them in the
> IP-VRF route table, and then reoriginates the routes with the encapsulation
> parameters of the adjacent domain before advertising them. This
> reorigination process ensures that the procedures remain independent of the
> specific transport tunnels used in each domain, as it functions as a
> service interworking solution.”*
>
> Gyan> Agreed to make generic with the node naming keep as-is.  Text looks
> perfect!!
>
>
>
>     Excellent job with this work as it’s extremely helpful for operators
> for IW between mix technologies.
>
> *Thanks!*
>
> *Jorge*
>
>
>
>
>
>
>
>
>
> About this:
>
> Example of draft for MPLS/SR-MPLS to SRv6 GW/IW uses a GW for transport
> translation interworking
>
> & service interworking. This is just one draft but their are many drafts
> on interworking between technologies and both transport and service
> interworking concepts.
>
>
>
>
> https://datatracker.ietf.org/doc/html/draft-agrawal-spring-srv6-mpls-interworking-15
>
>
>
> We spoke with the authors before draft-ietf-spring-srv6-mpls-interworking
> <https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-mpls-interworking-00#name-gateway-interworking>
> was adopted by SPRING. They will add references to our document for their
> section 7.2.1 Gateway Interworking, which is a high level description of
> the gateway model we are specifying in our document in detail for
> intersubnet forwarding. As discussed,
> draft-ietf-bess-evpn-ipvpn-interworking procedures work irrespective of the
> encapsulation of the domains, since there is always an IP-VRF instantiation
> and the routes are reoriginated with the encapsulation parameters of the
> destination domain.
>
>
>
> About this:
>
> Gyan> yes this example is subinterfaces and not tunnels in my opt-a
> example.  Since this draft is talking about the all the permutations and
> details of service interworking and transport independence I wonder if it
> would be possible to include as it does not require any gateway feature and
> the routes get propagated between domains.
>
> I don’t think there is anything new to specify with respect to RFC4364
> section 10 option a to guarantee interoperability, and that is not already
> described. It would be good to hear from others too, in case I’m
> missing something.
>
>
>
>      Gyan> I understand this gateway procedures much better now and agree
> nothing additional is needed.
>
>
>
> Thanks.
>
> Jorge
>
>
>
>
>
> *From: *Gyan Mishra <[e-mail]>
> *Date: *Wednesday, January 29, 2025 at 10:46 PM
> *To: *Jorge Rabadan (Nokia) <[e-mail]>
> *Cc: *Stephane Litkowski (slitkows) <slitkows=[e-mail]>,
> [e-mail] <
> [e-mail]>, [e-mail] <
> [e-mail]>, Voyer, Daniel <[e-mail]>, Bernier, Daniel <
> [e-mail]>
> *Subject: *Re: [bess] Short new WGLC and IPR poll for
> draft-ietf-bess-evpn-ipvpn-interworking-12
>
>
>
> *CAUTION:* This is an external email. Please be very careful when
> clicking links or opening attachments. See the URL nok.it/ext for
> additional information.
>
>
>
>
> Hi Jorge
>
>
>
> Responses in-line
>
>
>
> Thanks
>
>
>
> Gyan
>
>
>
>
>
>
>
>
>
> On Wed, Jan 29, 2025 at 8:28 AM Jorge Rabadan (Nokia) <
> [e-mail]> wrote:
>
> Hi Gyan,
>
>
>
> Thanks for reviewing the draft.
>
> Please see my comments in-line.
>
>
>
> *From: *Gyan Mishra <[e-mail]>
> *Date: *Tuesday, January 28, 2025 at 9:02 PM
> *To: *Stephane Litkowski (slitkows) <slitkows=[e-mail]>
> *Cc: *[e-mail] <
> [e-mail]>, [e-mail] <
> [e-mail]>, Voyer, Daniel <[e-mail]>, Bernier, Daniel <
> [e-mail]>
> *Subject: *Re: [bess] Short new WGLC and IPR poll for
> draft-ietf-bess-evpn-ipvpn-interworking-12
>
>
>
> *CAUTION:* This is an external email. Please be very careful when
> clicking links or opening attachments. See the URL nok.it/ext for
> additional information.
>
>
>
>
>
>  I support progressing this draft with some slight modifications below.
>
>
>
> I have a very important addition to the draft that I think is pertinent
> that I would like to share.
>
>
>
> Before I get to that I had a comment on the draft as it exists today.
>
>
>
> The draft does not talk about underlay mismatch at the domain boundary
> which is very important.
>
> *[jorge] the procedures we're outlining are independent of the underlying
> infrastructure in each domain. I don’t think the draft needs to discuss any
> underlay aspects. If you think the scope should clarify that the procedures
> are independent of the underlay, we can do it in the introduction.*
>
>
>
>     Gyan> yes please clarify in the introduction why the procedures are
> independent of the underlay and why.
>
>
>
> There are a variety of different underlays and depending on the underlay
> type the solution maybe completely different as it would require a special
> gateway / IW feature specific to the two underlays that need to communicate
> with some type of translation.  Also the underlay protocol maybe a mismatch
> IPv4 on one side and IPv6 on the other and that poses a another problem.
> In my initial email I mentioned inter-as opt-a because it is plain IP back
> to back VRF and the underlay transport IW is taken out of the picture and
> only service IW is dealt with and it works seamlessly and is thus underlay
> independent.
>
>
>
> Example of draft for MPLS/SR-MPLS to SRv6 GW/IW uses a GW for transport
> translation interworking
>
> & service interworking. This is just one draft but their are many drafts
> on interworking between technologies and both transport and service
> interworking concepts.
>
>
>
>
> https://datatracker.ietf.org/doc/html/draft-agrawal-spring-srv6-mpls-interworking-15
>
>
>
>
>
> The draft does not talk about intra-domain scenario within a NVO VXLAN or
> MPLS / SR-MPLS / SRv6 fabric.
>
> *[jorge] the document defines a domain as follows:*
>
> *Domain: Two PEs are in the same domain if they are attached to the same
> tenant and the packets between them do not require a data path IP lookup
> (in the tenant space) in any intermediate router. A gateway PE is always
> configured with multiple DOMAIN-IDs. The domain boundaries are not limited
> to an Autonomous System or an IGP instance. The PEs in a domain can all be
> part of the same or different Autonomous System, and an Autonomous System
> can also contain multiple domains.*
>
> *So it is independent of the underlay “domains”. *
>
>
>
>     Domain is not the same think as underlay.  Domain is very generic.
> When I say underlay I am talking about the technology used in the underlay
> that may require some sort of translation or gateway interworking at the
> transport underlay level.  Along the same lines for any technology their is
> transport interworking which is for the underlay technology and service
> interworking which is the overlay.
>
>
>
> Also this draft talks mostly all about the new D-PATH path attribute but
> does not talk about any details of the gateway function going from ISF to
> SAFI 128 and how that would work.  Is the RT reoriginated at the domain
> boundary as the other type of SAFI in either direction I am guessing maybe
> but the draft does not talk about it at all.
>
> *[jorge] Not sure what you mean by “from ISF to SAFI 128”. SAFI 128 routes
> are deined as ISF routes too in the document. Also if by “RT” you mean
> route targets, sections 5 and 8 describe how route targets are treated when
> routes are readvertised into the adjacent domain. *
>
>
>
>     Gyan> Sorry I should be more by ISF I meant L2 VPN EVPN and SAFI 128 I
> meant IP VPN.  Yes by RT I mean route target.  So in a composite domain the
> tenant VRFs are advertised in both EVPN & IP VPN and so they have identical
> set of prefixes.  I would think the difference would be EVPN has MAC VRF
> RT-2 so not identical but would be preferred due to longer matches. In
> figure 9 it’s not clear is PE1 have EVPN and IPVPN peer to IPVPN? I did not
> think that was possible?  In section 8 figure 8 the gateway device has a
> safi-x peer and a safi-y peer and is able to propagate the prefixes from
> any of the 4 NLRI let’s say safi-x is RT-2 / RT-5 and safi-y is IPVPN.  How
> is that possible as the SAFI are different I would not think the safi-x
> routes would automatically propagate to safi-y and vice versa.  Am I
> missing something..
>
>
>
> I think this is critical to the progression of the draft.
>
>
>
> My recommendation is to rename the draft to “EVPN to IPVPN  IW with
> D-PATH” would make more sense the way the draft is written.
>
> *[jorge] I'm not sure I agree. D-PATH is only one aspect. The spec also
> talks about Path attribute propagation, route selection across ISF routes,
> composite and gateway procedures, error handling, etc.*
>
>
>
> In the context of IPVPN & EVPN interaction and ISF and SAFI 128 there is a
> myriad of scenarios that can exist.
>
> This is an extremely important topic as it comes up all the time for inter
> domain boundaries propagating  of L2 & L3 NLRI successfully across domain
> boundaries and within a domain a translation gateway.
>
>
>
> In most all cases generally the composite PE, composite domain works
> seamlessly no issues as two ships in the night that don’t touch each other.
>
>
>
> The complexity and possible loops that D-PATH solves the Gateway scenario.
>
>
>
> A typical method which is very commonly done for eBGP peering  to
> propagate EVPN RT-5 prefixes to IP VPN.  One end of eBGP peering is NVO
> VXLAN/GENEVE ASBR (CE) and other end is MPLS IP VPN SAFI 128 PE.  The
> peering is inter-as opt-a back to back VRF IPv4 Unicast and IPv6 unicast
> peering. This works extremely well and both ends can be pretty much any
> kind of underlay data plane mismatch and you don’t require any special
> gateway transport or service interworking in the case of any of the
> following:
>
>
>
> MPLS / SR-MPLS to SRv6.
>
> MPLS / SR-MPLS to VXLAN
>
> SRv6 to VXLAN
>
>
>
> Stick diagram (eBGP)
>
>
>
>                      Inter-as opt-a
>
>
>
> If the underlay  on core & dc is the same then you still have to use
> inter-as opt-a
>
>
>
> ASBR (DC EVPN) <-> PE (Core IP VPN)
>
> *[jorge] I’m not sure if I follow. RFC4364 section 10 option a is IP-VRF
> to IP-VRF connectivity via subinterfaces, not tunnels. This spec does not
> introduce any procedures for option “a".*
>
>
>
>     Gyan> yes this example is subinterfaces and not tunnels in my opt-a
> example.  Since this draft is talking about the all the permutations and
> details of service interworking and transport independence I wonder if it
> would be possible to include as it does not require any gateway feature and
> the routes get propagated between domains.
>
>
>
> If you have underlay  mismatch then there is also IW/GW transport or
> service interworking
>
>
>
> This same concept works with iBGP peering within the data center where the
> concept requires an intermediate router we can call a Gateway and can be
> solved by NVO VXLAN/GENEVE EVPN  on one end iBGP to  PE with IP VPN SAFI
> 128 PE.  The EVPN leaf-1  advertises the routes IPv4 unicast / IPv6 unicast
> routes RT-5 prefixes to an intermediate router (GW) PE SAFI 128 -> VPNv4 /
> VPNv6 (RR) -> propagates VPNv4/VPNv6 to rest of fabric.
>
>
>
> Stick diagram (iBGP)
>
>
>
> leaf-1 <-> GW <-> (RR) <-> rest of fabric
>
> *[jorge] this falls under the gateway procedures in the draft. Please
> check out section 8.  *
>
>
>
>     Gyan> Agreed.  I did please see my comments on section 8.
>
>
>
> In both the eBGP & iBGP use case we are trying to get the EVPN mac VRF
> routes reachability imported into SAFI 128 but all we need is the RT-5
> prefixes and not the MAC VRF RT-2 host routes so the RT-5 summary suffices.
>
>
> *[jorge] this spec is about ISF routes, that is, Inter Subnet Forwarding
> routes, and not layer-2 information. For EVPN that includes routes that are
> processed in the context of an IP-VRF route table, which includes IP Prefix
> routes and MAC/IP routes when processed as in RFC9135 symmetric IRB model.
> That’s because both types are used for inter subnet forwarding in EVPN
> networks. Please let me know if I’m missing something.*
>
> *Thank you.*
>
> *Jorge*
>
>
>
>     Gyan> Understood.  I was excluding the RT-2 for summarization with
> RT-5 only advertised inter domain but agreed for consistency the RT-2
> should be included.
>
>
>
> Using this solution it’s very simple and elegant and no loops.
>
>
>
> Is it possible to add my comments to the draft.
>
>
>
> Many Thanks!!
>
>
>
> Gyan
>
>
>
>
>
> On Mon, Jan 27, 2025 at 5:25 AM Stephane Litkowski (slitkows) <slitkows=
> [e-mail]> wrote:
>
> Hi,
>
>
>
> As draft-ietf-bess-evpn-ipvpn-interworking went through multiple
> discussions that seem to be closed now. We would like to do a new short
> WGLC of 1-week to gather any additional comment before we move forward with
> the draft.
>
>
>
> The WGLC poll starts today and will end on 2/3.
>
>
>
> Similarly, as the last IPR poll was done a long time back. We are also
> polling for knowledge of any undisclosed IPR that applies to this document
> (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
>
>
>
>
> Thank you
>
>
>
> Brgds,
>
>
>
>
>
> Stephane, Matthew, Jeffrey (BESS chairs)
>
>
>
>
>
>
>
> _______________________________________________
> BESS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>