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

[Xiejingrong (Jingrong)]

Hi,

I have always had my opinion that Multicast Tree Building procedure is a very 
dynamic procedure, however BGP is skilled at stable-data (like prefix, or 
aggregated MVPN state on edge of a provider) driven “PUSH” thing.

I have almost forget the detail of the draft-ietf-bess-bgp-multicast-controller 
through I had read it long ago.

I would suggest that the relationship of the draft-ietf-bess and the polling 
draft can be re-evaluated.

Thanks,
Jingrong


From: pim [mailto:pim-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: Monday, March 28, 2022 4:47 PM
To: Susan Hares 
Cc: i...@ietf.org; Shraddha Hegde ; 
p...@ietf.org; BESS ; Jeffrey (Zhaohui) Zhang 

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

Hi,

It also needs to be observed that  draft-ietf-bess-bgp-multicast-controller has 
a broader scope and also covers mLDP functionality what may be extremely useful 
for networks which are not green field and would like to transition from 
current to new multicast trees.

Having solution in IDR which covers multicast tree setup partially and at the 
same time a more complete one which has been already adopted and is progressing 
as a WG document is never a good thing.

Besides I am puzzled since when IDR is accepting protocol extensions which are 
used to setup multicast distribution trees ?

When the first version of the draft was written (Sep 2017) we went to BESS with 
draft-ietf-bess-bgp-multicast-controller since that WG is center of gravity for 
all VPN/multi-tenant multicast related work.

Kind regards,
Robert


On Mon, Mar 28, 2022 at 7:39 AM Shraddha Hegde 
mailto:40juniper@dmarc.ietf.org>> 
wrote:
WG,

I agree with Jeffrey that the BESS adopted draft 
draft-ietf-bess-bgp-multicast-controller provides
Solution in the same problem space. It is good to discuss the two drafts before 
adopting
draft-hb-idr-sr-p2mp-policy in IDR.

Rgds
Shraddha



Juniper Business Use Only
From: Idr mailto:idr-boun...@ietf.org>> On Behalf Of 
Jeffrey (Zhaohui) Zhang
Sent: Friday, March 25, 2022 8:17 PM
To: Susan Hares mailto:sha...@ndzh.com>>; 
i...@ietf.org
Cc: 'p...@ietf.org' 
mailto:p...@ietf.org>>; 'BESS' 
mailto:bess@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]

[+ 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* 

Re: [bess] Cross WG review request for draft-ietf-bier-evpn

[Xiejingrong (Jingrong)]

Hi Jeffrey, WG,

Thanks for the further discussions.

“Didn’t we have such “unified” encoding already – an MPLS label?”
I agree and I would prefer to impl & use MPLS label for service delimiting in 
vxlan/nvgre/geneve environment if I have to implement the following 6 options:
BIER+vxlan/nvgre/geneve for unicast vxlan/nvgre/geneve alignment, and BIER + 
ip-udp-vxlan/ip-nvgre/ip-udp-geneve for alignment & php.

However there may still be a problem: the MPLS label is short than 24-bit VNI 
needed in vxlan/nvgre/geneve enviroment!
Given this I will consider {L2 header + BIER + unified-overlay-header(UOH) },  
where the UOH is used for service delimiting and inclusive to 24-bit VNI of any 
type.
The UOH can be designed to support L2 header + UOH as well considering the PHP.

Anyway, I know it’s a trade-off between implement cost and market value.
I have no other question/problem with the processing of this draft even if I 
think it is wrong direction to me as I see it from implementation view.

Thanks!
Jingrong


From: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net]
Sent: Monday, May 10, 2021 10:28 PM
To: Xiejingrong (Jingrong) ; slitkows.i...@gmail.com; 
bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: RE: [bess] Cross WG review request for draft-ietf-bier-evpn

Hi Jingrong,

Please see zzh> below.

From: Xiejingrong (Jingrong) 
mailto:xiejingr...@huawei.com>>
Sent: Friday, May 7, 2021 8:19 AM
To: Jeffrey (Zhaohui) Zhang mailto:zzh...@juniper.net>>; 
slitkows.i...@gmail.com<mailto:slitkows.i...@gmail.com>; 
bess@ietf.org<mailto:bess@ietf.org>
Cc: bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>
Subject: RE: [bess] Cross WG review request for draft-ietf-bier-evpn

[External Email. Be cautious of content]

Hi Jeffrey, all,

First of all, I am not against the process of this draft.

What I really want to discuss is about the “right” design of BIER service 
solution to make it really implementable and deployable, before it goes to a 
wrong direction IMO.

Zzh> I am not sure if there is a question/problem of “wrong direction” here.

The first design of BIER is based on MPLS, and the first BIER overlay encoding 
is an VPN Label following BIER header, to make it more aligned with the 
“BIER-MPLS” underlay.

However, is this a good design to be just “more aligned”, first with MPLS , 
then with IP based vxlan/nvgre/geneve ?

When MPLS is not preferred encapsulation but BIER is, then MPLS Label encoding 
after BIER header may not be preferred, and one have to choose a better 
“aligned” BIER overlay encoding, for example Vxlan.

When Vxlan is not preferred for unicast but BIER is preferred for multicast, 
then a better “aligned” BIER overlay encoding is needed, say NVGRE.

When Nvgre is not preferred for unicast but BIER is preferred for multicast, 
then a better “aligned” BIER overlay encoding is needed, say GENEVE.

Zzh> As I mentioned in the previous reply, using VXLAN/NVGRE/GENEVE after BIER 
is *NOT* a random and single choice. It is based whether an operator uses for 
unicast. If operator 1 uses VXLAN for unicast, then for BUM it’s BIER header 
followed by the VXLAN header (w/ or w/o the IP/UDP header depending on whether 
PHP is needed); if operator 2 uses NVGRE for unicast, then for BUM it’s BIER 
header followed by the NVGRE header and so on so forth.

Remind that Vxlan and Nvgre is informational encapsulation and Geneve is 
standard, however a router may not support Geneve but support vxlan, and may or 
may not support BIER.

Also remind that, when considering IPv6 encapsulation, vxlan/nvgre/geneve may 
have another alternative of SRv6-network-programming [RFC8986].

Zzh> If an operator uses SRv6 network programing instead of VXLAN/NVGRE/GENEVE, 
then of course VXLAN/NVGRE/GENEVE won’t be used with BIER.

How about designing one “unified” encoding that is “independent” of these IP 
based vxlan/nvgre/geneve encodings? say a longer-than-20-bit integer value 
without Vxlan/Nvgre/Geneve encoding.

Zzh> Didn’t we have such “unified” encoding already – an MPLS label? 
Zzh> In our previous discussions, I had said that while I understand that an 
operator may not want to use MPLS for transport purpose, I really don’t see why 
MPLS labels can’t be used for service delimiting purpose. No matter how/what it 
is encoded/presented/called, a number is used to represent something and an 
action is performed when that number is matched. It could be an mpls label, or 
a VNI, or some SRv6 function/argument bits.

The design of such a “unified” encoding can also consider the requirements that 
have seen: PHP and the problem that the BFIR node information is lost (then 
basic function like MVPN RPF is lost) etc.

If the vxlan/nvgre/geneve is implemented in BIER, then please just ignore these 
discussions. If it is not, then I think such discussions may make some sense.

Zzh> Let me ask it this way – say you’re an operator/vendor who prefers SRv6 
for unicast se

Re: [bess] Cross WG review request for draft-ietf-bier-evpn

[Xiejingrong (Jingrong)]

Hi Jeffrey, all,

First of all, I am not against the process of this draft.

What I really want to discuss is about the "right" design of BIER service 
solution to make it really implementable and deployable, before it goes to a 
wrong direction IMO.

The first design of BIER is based on MPLS, and the first BIER overlay encoding 
is an VPN Label following BIER header, to make it more aligned with the 
"BIER-MPLS" underlay.

However, is this a good design to be just "more aligned", first with MPLS , 
then with IP based vxlan/nvgre/geneve ?

When MPLS is not preferred encapsulation but BIER is, then MPLS Label encoding 
after BIER header may not be preferred, and one have to choose a better 
"aligned" BIER overlay encoding, for example Vxlan.

When Vxlan is not preferred for unicast but BIER is preferred for multicast, 
then a better "aligned" BIER overlay encoding is needed, say NVGRE.

When Nvgre is not preferred for unicast but BIER is preferred for multicast, 
then a better "aligned" BIER overlay encoding is needed, say GENEVE.

Remind that Vxlan and Nvgre is informational encapsulation and Geneve is 
standard, however a router may not support Geneve but support vxlan, and may or 
may not support BIER.

Also remind that, when considering IPv6 encapsulation, vxlan/nvgre/geneve may 
have another alternative of SRv6-network-programming [RFC8986].

How about designing one "unified" encoding that is "independent" of these IP 
based vxlan/nvgre/geneve encodings? say a longer-than-20-bit integer value 
without Vxlan/Nvgre/Geneve encoding.

The design of such a "unified" encoding can also consider the requirements that 
have seen: PHP and the problem that the BFIR node information is lost (then 
basic function like MVPN RPF is lost) etc.

If the vxlan/nvgre/geneve is implemented in BIER, then please just ignore these 
discussions. If it is not, then I think such discussions may make some sense.

What's your opinion ? Can the BESS chair also provide your points on this?

Thanks
Jingrong



From: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net]
Sent: Tuesday, May 4, 2021 2:39 AM
To: Xiejingrong (Jingrong) ; slitkows.i...@gmail.com; 
bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: RE: [bess] Cross WG review request for draft-ietf-bier-evpn

Hi Jingrong, WG,

I somehow missed this email. Sorry for replying late.

Please see zzh> below.

From: BESS mailto:bess-boun...@ietf.org>> On Behalf Of 
Xiejingrong (Jingrong)
Sent: Wednesday, April 7, 2021 3:20 AM
To: slitkows.i...@gmail.com<mailto:slitkows.i...@gmail.com>; 
bess@ietf.org<mailto:bess@ietf.org>
Cc: bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>
Subject: Re: [bess] Cross WG review request for draft-ietf-bier-evpn

[External Email. Be cautious of content]

Hi,

I have some comments on this draft.

1. There are 3 different encapsulations VXLAN/NVGRE/GENEVE defined in this 
draft, but it is not clear if there is a mandatory one for  interoperable 
implementation, or all are mandatory ?

Zzh> For a particular deployment, only one is needed - whichever one that is 
used for (known) unicast.

The effort to make BIER-EVPN "unified" with Unicast-EVPN (by using 3 BIER proto 
values) doesn't seem to be convenient:
1) For implementation, the existing NVO3 VXLAN/NVGRE/GENEVE forwarding module 
(HW or SW) doesn't help much because the major gap is BIER.
2) For trouble-shooting like offline LAN analyzing (rfc8279), the existing NVO3 
VXLAN/NVGRE/GENEVE header doesn't help much because the major part is BIER.

>From my point of view, one uniform encapsulation is better because it is used 
>for one single purpose - to distinguish the tenant and still keep aligned with 
>NVO3 style where "VNI" is used.

Zzh> From operational point of view, if a customer uses VXLAN for unicast, it 
does not make sense if he is forced to use NVGRE/GENEVE as BIER payload?

2. In section 2.1:
 A well-known IP multicast address (to be assigned by IANA) is used as
the destination address and the egress PEs MUST be set up to receive
and process packets addressed to the address.

It is not clear what are the "set up" and "process" implying. For example:
1) For implementation, does the "set up" mean an MFIB entry populated into 
forwarding table ? A packet with well-known IP multicast address as destination 
address (like 224.0.0.1) is usually sent to CPU in a multicast router in my 
opinion.

Zzh> 224.0.0.1 is a good example for what "set up" and "processing" means - the 
router is prepared to process packets addressed to the well-know address. 
Whether it is sent to CPU for processing is a local implementation detail - a 
sane/normal implementation would handle it in fast path but the spec does not 
have to mandate that.

2) For error-handling, how to "process" if the TTL/H

Re: [bess] WG Adoption and IPR Poll for draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03

[Xiejingrong (Jingrong)]

Hi,

I have read the document and support the adoption.

Thanks,
Jingrong

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Bocci, Matthew (Nokia - 
GB)
Sent: Tuesday, April 13, 2021 5:37 PM
To: draft-mishra-bess-deployment-guide-ipv4nlri-ipv...@ietf.org; bess@ietf.org
Subject: [bess] WG Adoption and IPR Poll for 
draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03

Hello,

This email begins a two-weeks WG adoption poll for 
draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-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 April 27th 2021.

Regards,
Matthew and Stephane


[1] 
https://datatracker.ietf.org/doc/draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh/


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

Re: [bess] Cross WG review request for draft-ietf-bier-evpn

[Xiejingrong (Jingrong)]

Hi,

I have some comments on this draft.

1. There are 3 different encapsulations VXLAN/NVGRE/GENEVE defined in this 
draft, but it is not clear if there is a mandatory one for  interoperable 
implementation, or all are mandatory ?

The effort to make BIER-EVPN "unified" with Unicast-EVPN (by using 3 BIER proto 
values) doesn't seem to be convenient:
1) For implementation, the existing NVO3 VXLAN/NVGRE/GENEVE forwarding module 
(HW or SW) doesn't help much because the major gap is BIER.
2) For trouble-shooting like offline LAN analyzing (rfc8279), the existing NVO3 
VXLAN/NVGRE/GENEVE header doesn't help much because the major part is BIER.

>From my point of view, one uniform encapsulation is better because it is used 
>for one single purpose - to distinguish the tenant and still keep aligned with 
>NVO3 style where "VNI" is used.


2. In section 2.1:
 A well-known IP multicast address (to be assigned by IANA) is used as
the destination address and the egress PEs MUST be set up to receive
and process packets addressed to the address.

It is not clear what are the "set up" and "process" implying. For example:
1) For implementation, does the "set up" mean an MFIB entry populated into 
forwarding table ? A packet with well-known IP multicast address as destination 
address (like 224.0.0.1) is usually sent to CPU in a multicast router in my 
opinion.
2) For error-handling, how to "process" if the TTL/Hop limit field in the IP 
header is 0/1/254/255 ?

>From my point of view, the cost to support BIER-PHP this way is fairly high. I 
>am not sure if some words like "recommend" or "not recommend" can help to do 
>the trade-off for implementation/deployment.


Thanks
Jingrong


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of slitkows.i...@gmail.com
Sent: Friday, April 2, 2021 2:47 PM
To: bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: [bess] Cross WG review request for draft-ietf-bier-evpn

HI folks,

The BIER WG is in the last mile of review for draft-ietf-bier-evpn and requests 
our review on the document before progressing further.
Please have a deep look at it and provide your feedback or concerns.

Please close the review by April 20th.


Thanks in advance,


Stephane

https://datatracker.ietf.org/doc/draft-ietf-bier-evpn/

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

Re: [bess] Éric Vyncke's Abstain on draft-ietf-bess-mvpn-fast-failover-13: (with COMMENT)

[Xiejingrong (Jingrong)]

Hi Eric,

You say "because of the use outside of a node of the IPv4-mapped IPv6 addresses 
in section 3.1.6.1. A reply on this topic will be welcome."

I understand your point about using IPv4-mapped IPv6 address 
":::127.0.0.0/104", as it is assumed to never leave a node and should never 
be transmitted over the Internet (RFC5156).

This I believe is something borrowed into IETF since RFC4379, which is almost 
the SAME time as RFC4291, when the RFC5156 hadn't been produced.

Beyond this timeline reason, the use of ":::127.0.0.0/104" still has some 
other reasons.
One reason I can see, a SINGLE loopback IPv6 address "::1" is not enough then 
for RFC4379 use cases ! 
Because RFC4379 originally designed for MPLS, so it requires a "randomly 
chosen" loopback address for ECMP! See below RFC4379 section 4.3:

4.3.  Sending an MPLS Echo Request

   An MPLS echo request is a UDP packet.  The IP header is set as
   follows: the source IP address is a routable address of the sender;
   the destination IP address is a (randomly chosen) IPv4 address from
   the range 127/8 or IPv6 address from the range
   0:0:0:0:0::127/104.

Ever since SRv6/IPv6 native approach is produced as an alternative of MPLS in a 
limited-domain, the need of "randomly chosen" loopback address is relieved 
because the IPv6 Flow Label could do the ECMP thing.

However, many different OAM tools like Ping/trace, Twamp/Stamp, BFD need to use 
mechanism like RFC4379 (now updated to RFC8029), with an IPv4/IPv6 loopback 
address as destination address of a tunneled packet, and with different UDP 
destination ports to distinguish different OAM tools.

Unfortunately this will open more attack threats because of the UDP ports 
opened.

I think there is still strong need for OAM to have IPv6 loopback address 
block(s) instead of a SINGLE one currently in RFC4291, thus the many UDP ports 
for differentiating OAM tools may be reduced by using many IPv6 loopback 
addresses. 

There is also other observations and discussions from the view of internet/app 
(by comparison, the OAM case is from the view of limited-domain), stating that 
IPv6 loopback address block(s) are needed. See 
.

Thanks
Jingrong


-Original Message-
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of éric Vyncke via 
Datatracker
Sent: Wednesday, December 16, 2020 6:06 PM
To: The IESG 
Cc: slitkows.i...@gmail.com; bess-cha...@ietf.org; 
draft-ietf-bess-mvpn-fast-failo...@ietf.org; bess@ietf.org
Subject: [bess] Éric Vyncke's Abstain on draft-ietf-bess-mvpn-fast-failover-13: 
(with COMMENT)

Éric Vyncke has entered the following ballot position for
draft-ietf-bess-mvpn-fast-failover-13: Abstain

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-fast-failover/



--
COMMENT:
--

Thank you for the work put into this document.

I have balloted ABSTAIN in the sense of "I oppose this document but understand 
that others differ and am not going to stand in the way of the others." because 
of the use outside of a node of the IPv4-mapped IPv6 addresses in section 
3.1.6.1. A reply on this topic will be welcome.

Stéphane in his doc shepherd's write up states that no implementation is known 
for a document born in 2008... Does the IETF really want to have this on the 
proposed standards track ?

Please find below my ABSTAIN point, some non-blocking COMMENT points (but 
replies would be appreciated), and one nits.

I hope that this helps to improve the document,

Regards,

-éric

== ABSTAIN ==
-- Section 3.1.6.1 --
I appreciate that the BFD WG relies on ":::127.0.0.0/104" but those 
IPv4-mapped IPv6 addresses are assumed to never leave a node and should never 
be transmitted over the Internet (see 
https://tools.ietf.org/html/rfc5156#section-2.2). This is the cause of my 
ABSTAIN. As the inner packet is sent over a tunnel, why not using the a 
link-local address or the ff02::1 link-local multicast group ?

== COMMENTS ==

-- Section 2.3 --
The use of "upstream" and "Upstream" could be confusing... The latter could 
have been "Upstream PE/ABSR" (often used later in the document) or "ingress 
node"

-- Section 3.1.6 --
Could the "BFD Discreminator" attribute be used for other purpose than this 
document? If so, then why not specifying it in *another* document?

Should this document clearly state that it does not define any TLV ?

== NITS ==

As I am probably not the only reader have difficulties to remember RFC contents 
by their number, may I suggest to 

Re: [bess] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-mvpn-evpn-aggregation-label-04

[Xiejingrong (Jingrong)]

Yes, support publishing the draft.

Thanks
Jingrong

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of slitkows.i...@gmail.com
Sent: Friday, December 11, 2020 11:53 PM
To: draft-ietf-bess-mvpn-evpn-aggregation-la...@ietf.org; bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: [bess] WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-mvpn-evpn-aggregation-label-04

This email starts a two-week working group last call for 
draft-ietf-bess-mvpn-evpn-aggregation-label-04 [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 28th December 2020

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 one IPR disclosure.

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

Thank you,
Matthew & Stephane


[1] 
https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-evpn-aggregation-label/
[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] IGMP / MLD Proxy Draft update (NLRI change)

[Xiejingrong (Jingrong)]

I think John’s point is very reasonable, especially when considering that the 
current format of EVPN 8# route has been in current shape for many years.
The cleanest solution is to keep the format depicted in draft -04 (and its 
predecessors) on code point 8, and to allocate a new code point for the new 
format.

The fact of  “divergent implementations” has been taken into consideration 
already, otherwise the solution may be much more simple using the “customary 
way”.
The customary way of dealing with this would be to mark the field “reserved”, 
but evidently there are multiple divergent implementations in the field that 
use different formats…

Thanks
Jingrong

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of John Scudder
Sent: Saturday, April 25, 2020 6:01 AM
To: Mankamana Mishra (mankamis) 
Cc: draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org; bess@ietf.org
Subject: Re: [bess] IGMP / MLD Proxy Draft update (NLRI change)

Hi All,

Regarding the proposal to remove the Leave Group Synchronization field from the 
Multicast Leave Synch Route, the current proposal is inadequate. Below I 
discuss why, and provide an alternate suggestion. For those who don’t want to 
read my wall of text, my key motivation is simple:

- The current proposal is a ticking time bomb because it leaves in the field a 
situation where two incompatible implementations can exist undetectably.

And my proposal boils down to two things:

- For the new format NLRI that omits the field, allocate a new code point. 
Deprecate [*] code point 8 going forward.
- Optionally provide a somewhat more sophisticated interworking option for 
backward compatibility.

Nitty-gritty below including considerations for how to transition from code 
point 8 to the TBD code point.

As far as I can tell, there is consensus that the field is not useful. That’s a 
good start. The customary way of dealing with this would be to mark the field 
“reserved”, but evidently there are multiple divergent implementations in the 
field that use different formats for the Multicast Leave Synch Route, some that 
include the field and some that don’t. (I should disclose here that my 
employer’s implementation is in the “include” camp.)

There is an obvious interoperability problem here: BGP implementations are 
required to sanity-check the NLRI they receive (see RFC 4271 section 6.3, RFC 
4760 section 7, and RFC 7606 section 5.3). This checking is required whether or 
not there’s a route target present to cause the router to consume the NLRI, the 
standards require the NLRI to be checked regardless. The consequence of 
malformed NLRI is a session reset. This turns out to be a difficult problem in 
BGP, even though we’ve worked to reduce the number of error cases that require 
a session reset, malformed NLRI are one of the very bad cases we can’t paper 
over. The IDR WG worked on this very hard during the development of RFC 7606, 
it is a real problem. When an implementation expects one NLRI format and 
receives another, that’s a malformed NLRI, and can be expected to cause a 
session reset. To leave this situation in place would be BGP protocol 
malpractice.

As far as I can tell, this means it is only through dumb luck that we have had 
two different NLRI formats in the wild without a network meltdown. This seems 
like a ticking time bomb situation.

The implementations are in the field already, we can’t just stamp our feet and 
say “you should have followed the spec” and make the problem go away. So we 
have to think about how to migrate to one agreed format, whatever it may be. 
(The idea that interoperability concerns can be addressed by simply never 
mixing old and new implementations in the same network can be dismissed out of 
hand. That amounts to “there are no interoperability problems if there’s no 
interoperation”, and are we not a standards organization, and is our goal not 
interoperability?)

Let’s take as a given that the agreed format will end up being the one that 
removes the Leave Group Synchronization field. Since something has to change, 
it may as well be the thing that removes the vestigial field.

The cleanest solution is to keep the format depicted in draft -04 (and its 
predecessors) on code point 8, and to allocate a new code point for the new 
format. The old code point would be deprecated, the new code point would be the 
standardized version. It turns out that moving code points is exactly the 
strategy prescribed (or at least strongly recommended) by RFC 7120 section 3.2:

  If at some point changes that are not backward compatible are
  nonetheless required, a decision needs to be made as to whether
  previously allocated code points must be deprecated (see Section 3.3
  for more information on code point deprecation).  The considerations
  include aspects such as the possibility of existing deployments of
  the older implementations and, hence, the possibility for a collision
  between older and newer implementations in the field.

There 

[bess] FW: [Technical Errata Reported] RFC6625 (5605)

[Xiejingrong (Jingrong)]

Hi WG,
Just read another mail about Errata process 
<https://ietf.org/about/groups/iesg/statements/processing-rfc-errata/>
It reminds me about a very old Errata raised 1 year before. 
I have this confusion about the text of RFC6625 (as raised in the Errata) even 
longer before when the RFC8534 (updates this 6625) was in its very early 
version.
Please the WG have a look and give comments/discussions/suggestions on it.

Thanks
Jingrong

-Original Message-
From: RFC Errata System [mailto:rfc-edi...@rfc-editor.org] 
Sent: Wednesday, January 16, 2019 2:36 PM
To: ero...@cisco.com; ya...@juniper.net; wim.henderi...@alcatel-lucent.be; 
r...@huawei.com; db3...@att.com; aretana.i...@gmail.com; 
martin.vigour...@nokia.com; martin.vigour...@alcatel-lucent.com; 
thomas.mo...@orange.com
Cc: Xiejingrong ; l3...@ietf.org; 
rfc-edi...@rfc-editor.org
Subject: [Technical Errata Reported] RFC6625 (5605)

The following errata report has been submitted for RFC6625, "Wildcards in 
Multicast VPN Auto-Discovery Routes".

--
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5605

--
Type: Technical
Reported by: Jingrong Xie 

Section: 3.2.1

Original Text
-
  - If there is an installed S-PMSI A-D route originated by PE2,
whose NLRI contains (C-S,C-G), then (C-S,C-G) matches that
route.

  - Otherwise, if there is an installed S-PMSI A-D route originated
by PE2, whose NLRI contains (C-S,C-*), AND if C-G is an SSM
multicast group address, then (C-S,C-G) matches that route.

  - Otherwise, if there is an installed S-PMSI A-D route originated
by PE2, whose NLRI contains (C-*,C-G), AND if C-G is an ASM
multicast group address, then (C-S,C-G) matches that route.

  - Otherwise, if there is an installed S-PMSI A-D route originated
by PE2, whose NLRI contains (C-*,C-*), then (C-S,C-G) matches
that route.

Corrected Text
--
  - If there is an installed S-PMSI A-D route originated by PE2,
whose NLRI contains (C-S,C-G), then (C-S,C-G) matches that
route.

  - If there is an installed S-PMSI A-D route originated
by PE2, whose NLRI contains (C-S,C-*), AND if C-G is an SSM
multicast group address, then (C-S,C-G) matches that route too.

  - If there is an installed S-PMSI A-D route originated
by PE2, whose NLRI contains (C-*,C-G), AND if C-G is an ASM
multicast group address, then (C-S,C-G) matches that route too.

  - If there is an installed S-PMSI A-D route originated
by PE2, whose NLRI contains (C-*,C-*), then (C-S,C-G) matches
that route too.

Notes
-
The 'Match for data reception' is an behavior on the MVPN receiver-site PE. If 
an SPMSI A-D route is matched for data reception, it means that the 
receiver-site PE will respond to this SPMSI A-D route, either send a responded 
Leaf A-D route in case there is an explicit-tracking flag (LIR or LIRpF), or 
join the PMSI tunnel in the SPMSI A-D route in case the tunnel type is mLDP/PIM 
etc. This usage of 'match for data reception' is not explicitly explained in 
this RFC but it is used in . 
There is clear inclusive-selective relationship between S-PMSI A-D (*,*) and 
S-PMSI A-D(S,G).
Thinking the S-PMSI A-D (*,*) as an Inclusive one, the receiver site PE with a 
(C-S,C-G) state should keep its join state on both the S-PMSI A-D (*,*) and 
S-PMSI A-D(S,G), and setup the 'reception state' on both the (*,*) PMSI-tunnel 
and (S,G) PMSI-tunnel. So the 'match for reception' should be one or more SPMSI 
A-D routes.  The 'if/othersize/othersize' sentences make the wrong meaning.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please use "Reply 
All" to discuss whether it should be verified or rejected. When a decision is 
reached, the verifying party can log in to change the status and edit the 
report, if necessary. 

--
RFC6625 (draft-ietf-l3vpn-mvpn-wildcards-02)
--
Title   : Wildcards in Multicast VPN Auto-Discovery Routes
Publication Date: May 2012
Author(s)   : E. Rosen, Ed., Y. Rekhter, Ed., W. Hendrickx, R. Qiu
Category: PROPOSED STANDARD
Source  : Layer 3 Virtual Private Networks
Area: Routing
Stream  : IETF
Verifying Party : IESG
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG adoption poll for draft-sajassi-bess-evpn-mvpn-seamless-interop

[Xiejingrong (Jingrong)]

I support the adoption.

Thanks
Jingrong

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of slitkows.i...@gmail.com
Sent: Monday, October 28, 2019 6:10 PM
To: bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: [bess] WG adoption poll for 
draft-sajassi-bess-evpn-mvpn-seamless-interop

Hello,

This email begins a two-weeks WG adoption poll for 
draft-sajassi-bess-evpn-mvpn-seamless-interop [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 11th November 2019.

Regards,
Matthew and Stephane

[1] 
https://datatracker.ietf.org/doc/draft-sajassi-bess-evpn-mvpn-seamless-interop/

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

Re: [bess] WG adoption and IPR poll for draft-dawra-bess-srv6-services-02

[Xiejingrong]

I support the adoption.

Thanks
Jingrong

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Bocci, Matthew (Nokia - 
GB)
Sent: Friday, September 27, 2019 7:00 PM
To: draft-dawra-bess-srv6-servi...@ietf.org; bess@ietf.org
Subject: [bess] WG adoption and IPR poll for draft-dawra-bess-srv6-services-02

Hello,

This email begins a two-weeks WG adoption poll for 
draft-dawra-bess-srv6-services-02 [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 Friday 11th October 2019.

Regards,
Matthew and Stephane

[1] https://datatracker.ietf.org/doc/draft-dawra-bess-srv6-services/


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

Re: [bess] New Version Notification for draft-dawra-bess-srv6-services-01.txt

[Xiejingrong]

Hi
I didn't see the reply to my recent comments on the previous rev of this draft……

Thanks
Jingrong
发件人：Gaurav Dawra 
收件人：bess-cha...@ietf.org ;bess@ietf.org 
时间：2019-07-08 13:36:08
主 题：Re: [bess] New Version Notification for 
draft-dawra-bess-srv6-services-01.txt

Hi Bess WG,

To facilitate the review of latest update - here is some more context.

The new revision addresses all comments received from the WG, including the 
following.

  *   When Function part of SRv6 SID is unique per NLRI(example EVPN VPWS 
service), encoding it in SID attribute may introduce some degradation in BGP 
packing assuming other BGP attributes are shared for set of NLRI’s.

Specifically, in order to address the BGP packing issue, we are proposing the 
following in the new version:


  *   Flexibility of advertising Function and Arguments of SRv6 SID in label 
field of route NLRI. This addresses BGP packing concern when SID is unique per 
NLRI(example EVPN VPWS service), assuming other BGP attributes are shared for 
set of NLRI’s.
  *   Advertisement of SRv6 SID structure sub-sub tlv in SID attribute. It also 
provides ability to create SRv6 SID when individual fields are available 
separately.
These updates are completely backward compatible with previous version.

Gaurav

Sent from my iPhone

On Jul 5, 2019, at 12:55 PM, Gaurav Dawra 
mailto:gdawra.i...@gmail.com>> wrote:

Hi Bess WG,

We have posted a new version of SRv6 Services document.

Cheers,

Gaurav

-- Forwarded message -
From: mailto:internet-dra...@ietf.org>>
Date: Fri, Jul 5, 2019 at 12:55 PM
Subject: New Version Notification for draft-dawra-bess-srv6-services-01.txt
To: Jonn Leddy 
mailto:john_le...@cable.comcast.com>>, Swadesh 
Agrawal mailto:swaag...@cisco..com>>, Robert Raszuk 
mailto:rob...@raszuk.net>>, Dirk Steinberg 
mailto:d...@steinberg.net>>, 
daniel.vo...@bell.ca 
mailto:daniel.vo...@bell.ca>>, Bruno Decraene 
mailto:bruno..decra...@orange.com>>, Jorge Rabadan 
mailto:jorge.raba...@nokia.com>>, Gaurav Dawra 
mailto:gdawra.i...@gmail.com>>, Shunwan Zhuang 
mailto:zhuangshun...@huawei.com>>, 
daniel.bern...@bell.ca 
mailto:daniel.bern...@bell.ca>>, Clarence Filsfils 
mailto:cfils...@cisco.com>>, Patrice Brissette 
mailto:pbris...@cisco.com>>, Satoru Matsushima 
mailto:satoru.matsush...@g.softbank.co.jp>>



A new version of I-D, draft-dawra-bess-srv6-services-01.txt
has been successfully submitted by Gaurav Dawra and posted to the
IETF repository.

Name:   draft-dawra-bess-srv6-services
Revision:   01
Title:  SRv6 BGP based Overlay services
Document date:  2019-07-03
Group:  Individual Submission
Pages:  28
URL:
https://www.ietf.org/internet-drafts/draft-dawra-bess-srv6-services-01.txt
Status: 
https://datatracker.ietf.org/doc/draft-dawra-bess-srv6-services/
Htmlized:   https://tools.ietf.org/html/draft-dawra-bess-srv6-services-01
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-dawra-bess-srv6-services
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-dawra-bess-srv6-services-01

Abstract:
   This draft defines procedures and messages for SRv6-based BGP
   services including L3VPN, EVPN and Internet services.  It builds on
   RFC4364 "BGP/MPLS IP Virtual Private Networks (VPNs)" and RFC7432
   "BGP MPLS-Based Ethernet VPN".





Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at 
tools.ietf.org.

The IETF Secretariat

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

[bess] Comments on draft-sajassi-bess-evpn-mvpn-seamless-interop-04

[Xiejingrong]

Hi

Thanks the authors to introduce this very useful, very clear draft.
I do think it deserves very much the adoption by the WG as an solution option.

Here are some minor comments after I read the latest draft (which I think does 
not affect the adoption):

6.  Solution Overview
   This section describes a multicast VPN solution based on [RFC6513]
   and [RFC6514] for EVPN PEs operating in IRB mode that want to perform
   seamless interoperability with their counterparts MVPN PEs.
[XJR] with or without their counterparts MVPN PEs (since this document covers 
both).


   EVPN-PEs advertise unicast routes as host routes using EVPN route
   type 2 for sources that are directly attached to a tenant BD that has
   been extended in the EVPN fabric. EVPN-PE may summarize sources (IP
   networks) behind a router that are attached to EVPN-PE or sources
   that are connected to a BD, which is not extended across EVPN fabric
   and advertises those routes with EVPN route type 5. EVPN host-routes
   are advertised as IPVPN host-routes to MVPN-PEs only incase of
   seamless interop mode.
[XJR] Editorial error. Incase of -> in case of


   In gateway model, EVPN-PE advertises unicast routes as IPVPN routes
   along with VRI extended community for all multicast sources attached
   behind EVPN-PEs. All IPVPN routes SHOULD be summarized while
   adverting to MVPN-PEs.
[XJR] VRI is used before its definition  VRF Route Import(6514) or IPv6 VRF 
Route Import(rfc6515) in my opinion.


   VRI is constructed as following:
  -  The 4-octet Global Administrator field MUST be set to an IP
 address of the PE.  This address SHOULD be common for all the
 IP-VRFs on the PE (e.g., this address may be the PE's loopback
 address or VTEP address).
  -  The 2-octet Local Administrator field associated with a given
 IP-VRF contains a number that uniquely identifies that IP-VRF
 within the PE that contains the IP-VRF.
[XJR] Does this document want to cover Underlay IPv6 network (described in 
RFC6515) ? If it does(I guess), then the VRI can be IPv6 VRF Route Import as 
pointed above, and the Global Administrator can be a 16-octet field.


   EVPN PE MUST have Route Target Extended Community to import/export
   MVPN routes. In data center environment, it is desirable to have this
   RT configured using auto-generated method than static configuration.
[XJR] is it a new specification for EVPN PE to have RT Extended Community ? if 
it does not, then MUST word is unnecessary.


   The following is one recommended model to auto-generate MVPN RT:
  - The Global Administrator field of the MVPN RT MAY be set
to BGP AS Number.
  - The Local Administrator field of the MVPN RT MAY be set to
the VNI associated with the tenant VRF.
[XJR] It's very helpful to have a method to auto-generate RT. Should this case 
be pointed out to help decision of using this method or not : the VNI is 24bit, 
and the Local Administrator is 16bit ?


9.2.3.  Other Encapsulation
   In order to signal a different tunneling encapsulation such as NVGRE,
  GPE, or GENEVE the corresponding BGP encapsulation extended community
   [TUNNEL-ENCAP] SHOULD be appended to the MVPN I-PMSI and S-PMSI A-D
   routes. If the Tunnel Type field in the encapsulation extended-
   community is set to a type which requires Virtual Network Identifier
   (VNI), e.g., VXLAN-GPE or NVGRE [TUNNEL-ENCAP], then the MPLS label
   in the PMSI Tunnel Attribute MUST be the VNI associated with the
   customer MVPN. Same as in VXLAN case, a gateway is needed for inter-
   operation between the EVPN-IRB PEs and non-EVPN MVPN PEs.
[XJR] I suggest remove the over-thought about various Encapsulation, we have 
seen different BGP attribute other than the TUNNEL-ENCAP attribute in 
https://datatracker.ietf.org/doc/draft-geng-bier-ipv6-inter-domain/
Hope you have a look at that one, and see if this kind of BIERv6 tunnel be 
useful for some scenario this document want to solve  to have a 
non-segmented P2MP tunnel from TOR in SPDC to BNGs outside of the SPDC.
Welcome your comments as well.


Thanks
Jingrong

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

[bess] Comments on

[Xiejingrong]

Hi
I have read this documents several times.
I think it is useful and stable to advance as a solution of L3VPN/EVPN service 
over IPv6 networks.
Here are some minor comments:

   SRv6 Service SID refers to an SRv6 SID that MAY be associated with
   one of the service specific behavior on the advertising Provider
   Edge(PE) router, such as (but not limited to), in the case of L3VPN
   service, END.DT (Table lookup in a VRF) or END.DX (crossconnect to a
   nexthop) functions
[xjr] what are the things "but not limited to" ? Please specify explicitly or 
delete the words in this paragraph and other places.

   To provide SRv6 service with best-effort connectivity, the egress PE
   signals an SRv6 Service SID with the BGP overlay service route.  The
   ingress PE encapsulates the payload in an outer IPv6 header where the
   destination address is the SRv6 Service SID provided by the egress
   PE.  The underlay between the PEs only need to support plain IPv6
   forwarding [RFC2460].
[xjr]"with best-effort connectivity" is not clear to me.
[xjr] I suggest a section can be added to say about "not using color and SRH", 
"using color and SRH" for easy-deployment and for path-optimization 
respectively.
[xjr] s/RFC2460/RFC8200/g

   To provide SRv6 service in conjunction with an underlay SLA from the
   ingress PE to the egress PE, the egress PE colors the overlay service
   route with a Color extended
   community[I-D.ietf-idr-segment-routing-te-policy].  The ingress PE
   encapsulates the payload packet in an outer IPv6 header with an SRH
   that contains the SR policy associated with the related SLA followed
   by the SRv6 Service SID associated with the route.  The underlay
   nodes whose SRv6 SID's are part of the SRH must support SRv6 data
   plane.
[xjr] see above suggestion.

SRv6 Service Sub-TLV Type (1 octet): This field is set to 1 to
  represent SRv6 SID Informaton Sub-TLV.
[xjr] s/Informaton/information/g

   Egress PEs which supports SRv6 based L3 services advertises overlay
   service prefixes along with a Service SID enclosed in a SRv6 L3
   Service TLV within the BGP SID attribute.  This TLV serves two
   purposes - first, it indicates that the egress PE is reachable via an
   SRv6 underlay and the BGP ingress PE receiving this route MAY choose
   to encapsulate or insert an SRv6 SRH; second ,it indicates the value
   of the SID to include in the SRH encapsulation.
[xjr] The two purposes I can see, the indication of the reachability to this 
PE, and the indication of a specific Service this SRv6 SID bound to.
[xjr] Use of SRH or not is determined by Color Extended Community, or more 
precisely, the SR-policy installed on Ingress Node, not this TLV.

4.6.  EVPN multicast routes (Route Types 6, 7, 8) over SRv6 core
   These routes do not require the advertisement of SRv6 Service TLVs
   along with them.  Similar to EVPN Route Type 4, the BGP Nexthop is
   equal to the IPv6 address of egress PE.  More details may be added in
   future revisions of this document.
[xjr] is this determined that No SRv6 Service TLVs required ? the document 
 had seen the use of SRv6 Service TLV in multicast 
VPN.
[xjr] Suggest to say simply this is outside of this document, which I think 
covers unicast service only, and helpful to advance.

Thanks
Jingrong

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

Re: [bess] MPLS Label value 3 in

[Xiejingrong]

s/6556/8556/g

7432 section 8.2.1
The MPLS label in the NLRI MUST be set to 0.

8556 section 3
The MPLS label field SHOULD be set to zero.
From:Xiejingrong 
To:draft-dawra-bess-srv6-servi...@ietf.org 
;bess@ietf.org 
Date:2019-06-27 19:57:30
Subject:[bess] MPLS Label value 3 in

Hi folks,

One question about MPLS Label value 3 used in 
:

the Label value in any service route NLRI encoding MUST be set to Implicit NULL 
[RFC3032].

Label = Implicit NULL

I think the more common use of MPLS Label to represent “invalid” is to use 
zero, as in RFC7432 and RFC6556.

Why this document use value 3 (Implicit NULL as defined in RFC3032) ?

Thanks
Jingrong

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

[bess] MPLS Label value 3 in

[Xiejingrong]

Hi folks,

One question about MPLS Label value 3 used in 
:

the Label value in any service route NLRI encoding MUST be set to Implicit NULL 
[RFC3032].

Label = Implicit NULL

I think the more common use of MPLS Label to represent "invalid" is to use 
zero, as in RFC7432 and RFC6556.

Why this document use value 3 (Implicit NULL as defined in RFC3032) ?

Thanks
Jingrong

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

Re: [bess] [Idr] [Softwires] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549

[Xiejingrong]

Hi Robert:

I was convinced. All of your points:

(1) No need to relax the check of nexthop as my previous suggestion.

(2) No need to update 5549/6515, and the nexthops defined in 
 section 3.1 to 3.4 are all right to me now.

(3) if we would be defining new SAFI we can write anything we like to the 
rules. Old SAFIs follow the RFCs already defind.

(4) next hop length = 32 is bizarre, and so does length = 48 as in 
 section 3.2.

Thank you very much !
Jingrong

From: Robert Raszuk [mailto:rob...@raszuk.net]
Sent: Thursday, June 27, 2019 6:50 PM
To: Xiejingrong 
Cc: Alexander Okonnikov ; softwi...@ietf.org; 
i...@ietf.org; bess@ietf.org; draft-dawra-bess-srv6-servi...@ietf.org
Subject: Re: [Idr] [bess] [Softwires] Regarding the Next Hop Network Address 
coding for IPv4 VPN over IPv6 Core in RFC5549

> Back to my suggestion: implementation should interpret nexthop RD+IPv4 and 
> nexthop IPv4 the same, and interpret nexthop RD+IPv6 and nexthop IPv6 the 
> same.

When elements of BGP UPDATE message are being parsed code must know what to 
expect. Note that we are dealing here with deployed SAFI 128 for nearly 20 
years.

So today there are two ways to know what format of next hop is in MP_REACH:

a) Inferring it from AFI/SAFI per section 3 of RFC4760

or (in addition to the above coarse assumption)

b) Inferring it from the discrete value of next hop length field as defined in 
section 3 of RFC5549

Note that if we would be defining new SAFI we can write anything we like to the 
rules of constructing the update message. But here again we are dealing with 
something which is deployed so sort of operating on the plane in flight.

If implementation can infer next hop type from length we are safe to define all 
sections to have next hop length = 16 octets and be done. But if there are some 
implementations which would only take AFI/SAFI to check if the next hop is 
correct or even further to check if the next hop length is correct then we have 
a problem.

/* Btw this notion of next hop length = 32 is bizarre ! I have never seen any 
BGP implementation sending two next hops (global IPv6 address followed by link 
local IPv6 address) not I am able to find any docs describing how any BGP stack 
would handle it. IMHO we should move this 32 next hop length to historic asap. 
*/

To the msg from Martin,

> maybe the WG would like to reach a conclusion on how to treat that erratum:
> http://www.rfc-editor.org/errata/eid5738

I would vote to reject the errata. There is no value of stuffing 8 octet of 
zeros in the next hop field. If the RFC got defined in 2012 that really means 
that most implementations are capable of inferring next hop format from the 
length field - which is very good. Accepting the errata would be a step 
backwords.

Thx,
R.

On Thu, Jun 27, 2019 at 11:15 AM Xiejingrong 
mailto:xiejingr...@huawei.com>> wrote:
Thanks for the RFC historical lessons.
--there was historically some assumption that next hop must be of the same AF 
as prefix.
--RFC 2858 says that Next Hop field should match AFI. On the other hand, RFC 
4760 says that Next Hop Field should match combination of AFI/SAFI.
--authors of RFC 4364 were trying to make it consistent with 4760.
--Also, drafts of RFC 4364 and RFC 4760 were being developed practically at the 
same time period.

The problem is clear, the nexthop field has been inconsistent between different 
L3VPN/MVPN scenarios and different implementations in the long history.

 is the latest draft, but it has different 
nexthop in section 3.1 to 3.4, in the year 2019.

Back to my suggestion: implementation should interpret nexthop RD+IPv4 and 
nexthop IPv4 the same, and interpret nexthop RD+IPv6 and nexthop IPv6 the same.

I think it may be helpful for  to add the 
above text, and update RFC4364/4659/4760/5549, to eliminate the worries about 
interoperation. is there any worries about interoperation ?

Thanks
Jingrong


From: Alexander Okonnikov 
[mailto:alexander.okonni...@gmail.com<mailto:alexander.okonni...@gmail.com>]
Sent: Wednesday, June 26, 2019 9:38 PM
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: UTTARO, JAMES mailto:ju1...@att.com>>; Xiejingrong 
mailto:xiejingr...@huawei.com>>; 
softwi...@ietf.org<mailto:softwi...@ietf.org>; 
i...@ietf.org<mailto:i...@ietf.org>; 
ian.far...@telekom.de<mailto:ian.far...@telekom.de>; 
bess@ietf.org<mailto:bess@ietf.org>; ianfar...@gmx.com<mailto:ianfar...@gmx.com>
Subject: Re: [Idr] [bess] [Softwires] Regarding the Next Hop Network Address 
coding for IPv4 VPN over IPv6 Core in RFC5549

Hi Robert,

Sorry, I was not so precise :-) Of course, RD part in Next Hop is not copied 
from RD of NLRI, but zeroed. I was trying to explain why Next Hop field in RFC 
4364 and RFC 4659 has format RD:IP (VPNvX address) rather than just IP.

Thank you!


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

Re: [bess] [Idr] [Softwires] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549

[Xiejingrong]

Please reject this erratum. 
RFC6515 is mandatory to require 4/16 bytes nexthop, and mandatory to reject 
12/24 bytes nexthop. 

Thanks.
Jingrong.

-Original Message-
From: Vigoureux, Martin (Nokia - FR/Paris-Saclay) 
[mailto:martin.vigour...@nokia.com] 
Sent: Thursday, June 27, 2019 6:37 PM
To: Xiejingrong ; Alexander Okonnikov 
; Robert Raszuk ; 
bess@ietf.org
Cc: softwi...@ietf.org; i...@ietf.org
Subject: Re: [Idr] [bess] [Softwires] Regarding the Next Hop Network Address 
coding for IPv4 VPN over IPv6 Core in RFC5549

since we are discussing that topic,

maybe the WG would like to reach a conclusion on how to treat that erratum:
http://www.rfc-editor.org/errata/eid5738

Thanks
-m

Le 2019-06-27 à 11:15, Xiejingrong a écrit :
> Thanks for the RFC historical lessons.
> 
> --there was historically some assumption that next hop must be of the 
> same AF as prefix.
> 
> --RFC 2858 says that Next Hop field should match AFI. On the other 
> hand, RFC 4760 says that Next Hop Field should match combination of AFI/SAFI.
> 
> --authors of RFC 4364 were trying to make it consistent with 4760.
> 
> --Also, drafts of RFC 4364 and RFC 4760 were being developed 
> practically at the same time period.
> 
> The problem is clear, the nexthop field has been inconsistent between 
> different L3VPN/MVPN scenarios and different implementations in the 
> long history.
> 
>  is the latest draft, but it has 
> different nexthop in section 3.1 to 3.4, in the year 2019.
> 
> Back to my suggestion: implementation should interpret nexthop RD+IPv4 
> and nexthop IPv4 the same, and interpret nexthop RD+IPv6 and nexthop
> IPv6 the same.
> 
> I think it may be helpful for  to 
> add the above text, and update RFC4364/4659/4760/5549, to eliminate 
> the worries about interoperation. is there any worries about 
> interoperation ?
> 
> Thanks
> 
> Jingrong
> 
> *From:*Alexander Okonnikov [mailto:alexander.okonni...@gmail.com]
> *Sent:* Wednesday, June 26, 2019 9:38 PM
> *To:* Robert Raszuk 
> *Cc:* UTTARO, JAMES ; Xiejingrong 
> ; softwi...@ietf.org; i...@ietf.org; 
> ian.far...@telekom.de; bess@ietf.org; ianfar...@gmx.com
> *Subject:* Re: [Idr] [bess] [Softwires] Regarding the Next Hop Network 
> Address coding for IPv4 VPN over IPv6 Core in RFC5549
> 
> Hi Robert,
> 
> Sorry, I was not so precise :-) Of course, RD part in Next Hop is not 
> copied from RD of NLRI, but zeroed. I was trying to explain why Next 
> Hop field in RFC 4364 and RFC 4659 has format RD:IP (VPNvX address) 
> rather than just IP.
> 
> Thank you!
> 
> 
> 
> 
> 
> ___
> Idr mailing list
> i...@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
> 
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [Idr] [Softwires] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549

[Xiejingrong]

Thanks for the RFC historical lessons.
--there was historically some assumption that next hop must be of the same AF 
as prefix.
--RFC 2858 says that Next Hop field should match AFI. On the other hand, RFC 
4760 says that Next Hop Field should match combination of AFI/SAFI.
--authors of RFC 4364 were trying to make it consistent with 4760.
--Also, drafts of RFC 4364 and RFC 4760 were being developed practically at the 
same time period.

The problem is clear, the nexthop field has been inconsistent between different 
L3VPN/MVPN scenarios and different implementations in the long history.

 is the latest draft, but it has different 
nexthop in section 3.1 to 3.4, in the year 2019.

Back to my suggestion: implementation should interpret nexthop RD+IPv4 and 
nexthop IPv4 the same, and interpret nexthop RD+IPv6 and nexthop IPv6 the same.

I think it may be helpful for  to add the 
above text, and update RFC4364/4659/4760/5549, to eliminate the worries about 
interoperation. is there any worries about interoperation ?

Thanks
Jingrong


From: Alexander Okonnikov [mailto:alexander.okonni...@gmail.com]
Sent: Wednesday, June 26, 2019 9:38 PM
To: Robert Raszuk 
Cc: UTTARO, JAMES ; Xiejingrong ; 
softwi...@ietf.org; i...@ietf.org; ian.far...@telekom.de; bess@ietf.org; 
ianfar...@gmx.com
Subject: Re: [Idr] [bess] [Softwires] Regarding the Next Hop Network Address 
coding for IPv4 VPN over IPv6 Core in RFC5549

Hi Robert,

Sorry, I was not so precise :-) Of course, RD part in Next Hop is not copied 
from RD of NLRI, but zeroed. I was trying to explain why Next Hop field in RFC 
4364 and RFC 4659 has format RD:IP (VPNvX address) rather than just IP.

Thank you!



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

Re: [bess] [Softwires] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549

[Xiejingrong]

Hi folks,

I guess this is an inconsistency due to past carelessness. Is there anyone can 
tell us the history of this inconsistency ?
RFC4364(VPNv4 over IPv4 network) and RFC4659(VPNv6 over IPv4 or IPv6 network) 
both require to use RD+IP(v4 or v6 respectively) as nexthop.
RFC5549(VPNv4/IPv4 over IPv6 network) requires to use IPv6 without RD as 
nexthop.
This same question also occur in MVPN: RFC6515, which talks about MVPN6 over 
IPv4/IPv6, or MVPN over IPv6, but does imply loosely to use IPv4/IPv6 without 
RD as nexthop (see below).
   The purpose of this document is to make clear that whenever a PE
   address occurs in an MCAST-VPN route (whether in the NLRI or in an
   attribute), the IP address family of that address is determined by
   the length of the address (a length of 4 octets for IPv4 addresses, a
   length of 16 octets for IPv6 addresses), NOT by the AFI field of the
   route.

My suggestion: implementation should interpret nexthop RD+IPv4 and nexthop IPv4 
the same, and interpret nexthop RD+IPv6 and nexthop IPv6 the same.
The RFC5549/SRv6-VPN/RFC6515 can keep as current shape, while interoperate can 
meet between different implementations.
Need a new draft to clarify this and to give a guide on further FooService over 
FooNetwork ?

Thanks
Jingrong

From: Softwires [mailto:softwires-boun...@ietf.org] On Behalf Of 
ian.far...@telekom.de
Sent: Tuesday, June 25, 2019 11:12 PM
To: Zhuangshunwan ; ianfar...@gmx.com
Cc: softwi...@ietf.org; bess@ietf.org
Subject: Re: [Softwires] Regarding the Next Hop Network Address coding for IPv4 
VPN over IPv6 Core in RFC5549

Hi Shunwan,

I’ve just re-checked RFC5539, and the referenced section 3 of RFC2545 and I can 
find nothing about using VPN-IPv6 for encoding the next-hop. Section 3 of 
RFC5539 is very clear that it’s a 16-byte GU IPv6 address or 32-bytes with a GU 
and LL address.

Can you point me to the text that gives you the impression that VPN-IPv6 is 
correct?

Note – I see that there is reported Errata on RFC5549, (not verified) saying 
that the length should be 24 or 48 to include the RD. However, as mentioned 
above, the supporting text in multiple places in the RFC and its references 
support the use of an IPv6 address (or 2) with no RD at 16 or 32 bytes, so this 
does seem to be the intention of the document as written.
https://www.rfc-editor.org/errata_search.php?rfc=5549

Thanks,
Ian

From: Softwires mailto:softwires-boun...@ietf.org>> 
on behalf of Zhuangshunwan 
mailto:zhuangshun...@huawei.com>>
Date: Tuesday, 25. June 2019 at 13:18
To: "ianfar...@gmx.com" 
mailto:ianfar...@gmx.com>>
Cc: "softwi...@ietf.org" 
mailto:softwi...@ietf.org>>, 
"bess@ietf.org" mailto:bess@ietf.org>>
Subject: Re: [Softwires] Regarding the Next Hop Network Address coding for IPv4 
VPN over IPv6 Core in RFC5549

Hi Ian,

Thanks for your response!

The opinion I have collected is:
Per RFC4634, the IPv4-VPN routes shall carry the V4 Next-hop, beginning with an 
8-octet RD and ending with a 4-octet IPv4 address.
Per RFC4659, the IPv6-VPN routes shall carry the V6 Next-hop, beginning with an 
8-octet RD and ending with a 16-octet IPv6 address.
When we start to implement the IPv4 VPN over IPv6 Core,  it is a natural way to 
encode the IPv4-VPN routes with VPN-IPv6 next-hop (i.e. beginning with an 
8-octet RD and ending with a 16-octet IPv6 address) .

I believe this is not just a minority opinion, and some of the current 
implementations are also doing this way.

I hope that the WGs can give a consistent opinion on this issue and avoid 
interoperability problem in the future.

Thanks,
Shunwan

From: ianfar...@gmx.com [mailto:ianfar...@gmx.com]
Sent: Monday, June 24, 2019 8:08 PM
To: Zhuangshunwan mailto:zhuangshun...@huawei.com>>
Cc: bess@ietf.org; 
softwi...@ietf.org
Subject: Re: [Softwires] Regarding the Next Hop Network Address coding for IPv4 
VPN over IPv6 Core in RFC5549

Hi,

My reading of Section 3 of RFC5549 is that the v6 next-hop is encoded as an 
IPv6 address:

   The BGP speaker receiving the advertisement MUST use the Length of
   Next Hop Address field to determine which network-layer protocol the
   next hop address belongs to.  When the Length of Next Hop Address
   field is equal to 16 or 32, the next hop address is of type IPv6.

It’s also worth noting that RFC4659 Section 2 states:

A VPN-IPv6 address is a 24-octet quantity, beginning with an 8-octet
   "Route Distinguisher" (RD) and ending with a 16-octet IPv6 address.

So, not 16 or 32 bytes.

Thanks,
Ian



On 22. Jun 2019, at 09:59, Zhuangshunwan 
mailto:zhuangshun...@huawei.com>> wrote:

Dear authors and WGs,

RFC5549 Section 6.2 says:

. 6.2.  IPv4 VPN over IPv6 Core
.
.The extensions defined in this document may be used for support of
.IPV4 VPNs over an IPv6 backbone.  In this application, PE routers
.would advertise VPN-IPv4 NLRI 

Re: [bess] RFC 8534 on Explicit Tracking with Wildcard Routes in Multicast VPN

[Xiejingrong]

Congratulations for the production of this RFC!

This draft is useful not only for MVPN using mLDP/RSVP-TE/IR(which is covered 
by this RFC), but also for MVPN using BIER (which is covered by BIER-MVPN 
draft).

It can be leveraged to Segmented MVPN too, by using a 'loose stitching' between 
mLDP/RSVP-TE/IR/BIER. This is described in 
draft-xie-bess-mvpn-segmented-updates-00.

Jeffrey generalize it and extended to EVPN case, and described in 
draft-zzhang-bess-mvpn-evpn-segmented-forwarding-00.

Hope they are right to be in BESS WG, and please offer suggestions/comments on 
them.

Thanks,
Jingrong


-Original Message-
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of rfc-edi...@rfc-editor.org
Sent: Wednesday, February 20, 2019 2:58 PM
To: ietf-annou...@ietf.org; rfc-d...@rfc-editor.org
Cc: drafts-update-...@iana.org; bess@ietf.org; rfc-edi...@rfc-editor.org
Subject: [bess] RFC 8534 on Explicit Tracking with Wildcard Routes in Multicast 
VPN

A new Request for Comments is now available in online RFC libraries.


RFC 8534

Title:  Explicit Tracking with Wildcard Routes 
in Multicast VPN 
Author: A. Dolganow, 
J. Kotalwar,
E. Rosen, Ed.,
Z. Zhang
Status: Standards Track
Stream: IETF
Date:   February 2019
Mailbox:andrew.dolga...@nokia.com, 
jayant.kotal...@nokia.com, 
erose...@gmail.com,
zzh...@juniper.net
Pages:  21
Characters: 49896
Updates:RFC 6514, RFC 6625, RFC 7524, RFC 7582, RFC 7900

I-D Tag:draft-ietf-bess-mvpn-expl-track-13.txt

URL:https://www.rfc-editor.org/info/rfc8534

DOI:10.17487/RFC8534

The base Multicast VPN (MVPN) specifications (RFCs 6513 and 6514) provide 
procedures to allow a multicast ingress node to invoke "explicit tracking" for 
a multicast flow or set of flows, thus learning the egress nodes for that flow 
or set of flows.  However, the specifications are not completely clear about 
how the explicit tracking procedures work in certain scenarios.  This document 
provides the necessary clarifications.  It also specifies a new, optimized 
explicit-tracking procedure.  This new procedure allows an ingress node, by 
sending a single message, to request explicit tracking of each of a set of 
flows, where the set of flows is specified using a wildcard mechanism.  This 
document updates RFCs 6514, 6625, 7524, 7582, and 7900.

This document is a product of the BGP Enabled Services Working Group of the 
IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track protocol 
for the Internet community, and requests discussion and suggestions for 
improvements.  Please refer to the current edition of the Official Internet 
Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this memo 
is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search For 
downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the author of 
the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless specifically 
noted otherwise on the RFC itself, all RFCs are for unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


___
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] Question regarding RFC6625 and this draft-->//RE: I-D Action: draft-ietf-bess-mvpn-expl-track-13.txt

[Xiejingrong]

Hi Jeffrey,

Wildcard S-PMSI A-D routes is less specific and more “inclusive” than the 
normal S-PMSI.
Among which, Wildcard (*,*)S-PMSI A-D route is the most “inclusive”, almost 
equal to I-PMSI A-D route. See RFC6625 “S-PMSI only”.
Leaf will not leave the real I-PMSI tunnel, so it should not leave the 
Wildcard(*,*)/(*,G)/(S,*) S-PMSI tunnel either, because they are “partially 
inclusive” tunnel.

Jingrong

From: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net]
Sent: Thursday, January 24, 2019 9:50 PM
To: Robert Raszuk 
Cc: Xiejingrong ; 
draft-ietf-bess-mvpn-expl-tr...@ietf.org; bess@ietf.org
Subject: RE: [bess] Question regarding RFC6625 and this draft-->//RE: I-D 
Action: draft-ietf-bess-mvpn-expl-track-13.txt

Robert,

You may want to leave the previous tunnel (if it is no longer needed for other 
traffic). E.g., sending an mldp label withdrawal or withdrawing a Leaf A-D 
route.

Jeffrey

From: Robert Raszuk [mailto:rras...@gmail.com]
Sent: Thursday, January 24, 2019 8:36 AM
To: Jeffrey (Zhaohui) Zhang mailto:zzh...@juniper.net>>
Cc: Xiejingrong mailto:xiejingr...@huawei.com>>; 
draft-ietf-bess-mvpn-expl-tr...@ietf.org<mailto:draft-ietf-bess-mvpn-expl-tr...@ietf.org>;
 bess@ietf.org<mailto:bess@ietf.org>
Subject: Re: [bess] Question regarding RFC6625 and this draft-->//RE: I-D 
Action: draft-ietf-bess-mvpn-expl-track-13.txt

Hi Jeffrey,

Isn't this just a matter of how you would be implementing "tunneling" ?

For vast majority of decapsulations there is no state as such, but it is just 
part of one of normal switching vectors in the router.

Best,
R.

On Wed, Jan 23, 2019, 21:40 Jeffrey (Zhaohui) Zhang 
mailto:zzh...@juniper.net> wrote:
The receiver PE cannot keep its state to receive on both tunnels forever. After 
some time, it has to leave the old tunnel.

Jeffrey

> -Original Message-
> From: Xiejingrong 
> [mailto:xiejingr...@huawei.com<mailto:xiejingr...@huawei.com>]
> Sent: Wednesday, January 23, 2019 9:09 PM
> To: Jeffrey (Zhaohui) Zhang mailto:zzh...@juniper.net>>; 
> draft-ietf-bess-mvpn-expl-
> tr...@ietf.org<mailto:tr...@ietf.org>
> Cc: bess@ietf.org<mailto:bess@ietf.org>
> Subject: RE: Question regarding RFC6625 and this draft-->//RE: [bess] I-D
> Action: draft-ietf-bess-mvpn-expl-track-13.txt
>
> Hi Jeffrey,
>
> Thanks for the explaination.
> I have the same understanding "the text in RFC6625 is really/mainly about
> which tunnel to send/receive on in a steady state."
> What confusing me is the "which tunnel to receive" decision, obviously on
> receiver site PE.
>
> In my opinion, the receiver site PE should not do the decision, but be 
> prepared
> to *any possible tunnel* that will be used by the sender site PE for a 
> specific
> (S,G) flow.
> Even in a steady state the sender site PE are using the (S,G) PMSI-tunnel for 
> a
> (S,G) flow, the preparation on the (*,*)PMSI-tunnel should be kept on the
> receiver site PE.
>
> Below is the errata report I have raised, and I hope it can be clarified.
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-
> 2Deditor.org_errata_eid5605=DwIFAg=HAkYuh63rsuhr6Scbfh0UjBXeMK
> -
> ndb3voDTXcWzoCI=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&
> m=uchRmclZ5z8wB9eN53Kr24c9zLtM9RBRe8OnA3FK1fM=cbCycqc2jZy8SjT
> LHS4AEL_UhljIoaGGWAnycB0VvrY=
>
>
> -Original Message-
> From: Jeffrey (Zhaohui) Zhang 
> [mailto:zzh...@juniper.net<mailto:zzh...@juniper.net>]
> Sent: Thursday, January 24, 2019 12:32 AM
> To: Xiejingrong mailto:xiejingr...@huawei.com>>; 
> draft-ietf-bess-mvpn-expl-
> tr...@ietf.org<mailto:tr...@ietf.org>
> Cc: bess@ietf.org<mailto:bess@ietf.org>
> Subject: RE: Question regarding RFC6625 and this draft-->//RE: [bess] I-D
> Action: draft-ietf-bess-mvpn-expl-track-13.txt
>
> Hi Jingrong,
>
> You're right that to avoid disruption and duplication a switchover delay is
> needed on the source PE and desired on the receiver PE, and that means the
> forwarding state needs to accommodate that.
>
> However, the text is in RFC6625 is really/mainly about which tunnel to
> send/receive on in a steady state. That's not explicitly spelled out, but 
> that's
> the intention per my understanding.
>
> To be more accurate, the text is about which PMSI route to match. In theory a
> PMSI can be instantiated with one particular tunnel at one time and then
> switch to another tunnel. In that case the PMSI route is updated with a
> different PTA - the match to sending/receiving does not change yet the
> switchover delay referred to RFC6513 still applies.
>
> Jeffrey
>
> > -Original Message-
> > From: Xiejingrong 
> > [mailto:xiejingr...@huawei.com<mailto:xiejingr...@huawei.com>]
&

Re: [bess] Question regarding RFC6625 and this draft-->//RE: I-D Action: draft-ietf-bess-mvpn-expl-track-13.txt

[Xiejingrong]

Hi Jeffrey,

Thanks for the explaination.
I have the same understanding "the text in RFC6625 is really/mainly about which 
tunnel to send/receive on in a steady state."
What confusing me is the "which tunnel to receive" decision, obviously on 
receiver site PE.

In my opinion, the receiver site PE should not do the decision, but be prepared 
to *any possible tunnel* that will be used by the sender site PE for a specific 
(S,G) flow.
Even in a steady state the sender site PE are using the (S,G) PMSI-tunnel for a 
(S,G) flow, the preparation on the (*,*)PMSI-tunnel should be kept on the 
receiver site PE.

Below is the errata report I have raised, and I hope it can be clarified.
https://www.rfc-editor.org/errata/eid5605


-Original Message-
From: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net] 
Sent: Thursday, January 24, 2019 12:32 AM
To: Xiejingrong ; 
draft-ietf-bess-mvpn-expl-tr...@ietf.org
Cc: bess@ietf.org
Subject: RE: Question regarding RFC6625 and this draft-->//RE: [bess] I-D 
Action: draft-ietf-bess-mvpn-expl-track-13.txt

Hi Jingrong,

You're right that to avoid disruption and duplication a switchover delay is 
needed on the source PE and desired on the receiver PE, and that means the 
forwarding state needs to accommodate that.

However, the text is in RFC6625 is really/mainly about which tunnel to 
send/receive on in a steady state. That's not explicitly spelled out, but 
that's the intention per my understanding.

To be more accurate, the text is about which PMSI route to match. In theory a 
PMSI can be instantiated with one particular tunnel at one time and then switch 
to another tunnel. In that case the PMSI route is updated with a different PTA 
- the match to sending/receiving does not change yet the switchover delay 
referred to RFC6513 still applies.

Jeffrey

> -Original Message-
> From: Xiejingrong [mailto:xiejingr...@huawei.com]
> Sent: Tuesday, January 22, 2019 8:47 PM
> To: Jeffrey (Zhaohui) Zhang ; 
> draft-ietf-bess-mvpn-expl- tr...@ietf.org
> Cc: bess@ietf.org
> Subject: RE: Question regarding RFC6625 and this draft-->//RE: [bess] 
> I-D
> Action: draft-ietf-bess-mvpn-expl-track-13.txt
> 
> Hi Jeffrey,
> 
> The sender PE need to work on (*,*) tunnel for a while (switch-over 
> timer) and then switch to the (S,G) tunnel.
> 
> To quote RFC6513 section 7.1.1
>The decision to bind a particular C-flow (designated as (C-S,C-G)) to
>a particular P-tunnel, or to switch a particular C-flow to a
>particular P-tunnel, is always made by the PE that is to transmit the
>C-flow onto the P-tunnel.
> 
>When a C-flow is switched from one P-tunnel to another, the purpose
>of running a switch-over timer is to minimize packet loss without
>introducing packet duplication.
> 
> Jingrong
> 
> -Original Message-
> From: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net]
> Sent: Saturday, January 12, 2019 3:29 AM
> To: Xiejingrong ; draft-ietf-bess-mvpn-expl- 
> tr...@ietf.org
> Cc: bess@ietf.org
> Subject: RE: Question regarding RFC6625 and this draft-->//RE: [bess] 
> I-D
> Action: draft-ietf-bess-mvpn-expl-track-13.txt
> 
> Jingrong,
> 
> > It is determined by the sender site PE whether to steer the flow of 
> > (C-S, C-G)
> into (*,*) PMSI-tunnel or (S,G)PMSI-tunnel, and the receiver site PE 
> should work correctly in any case.
> 
> Why would the sender PE send into (*, *) when there is a match for (S,G)?
> 
> Jeffrey
> 
> > -Original Message-
> > From: Xiejingrong [mailto:xiejingr...@huawei.com]
> > Sent: Thursday, January 10, 2019 11:10 PM
> > To: draft-ietf-bess-mvpn-expl-tr...@ietf.org
> > Cc: bess@ietf.org
> > Subject: Question regarding RFC6625 and this draft-->//RE: [bess] I-D 
> > Action:
> > draft-ietf-bess-mvpn-expl-track-13.txt
> >
> > Hi,
> >
> > I have a question regarding RFC6625 and this draft, since this draft 
> > is based on the RFC6625.
> >
> > In RFC6625 section "3.2.1 Finding the match for (C-S,C-G) for Data
> > Reception":
> > It defined the rules for Finding the matched S-PMSI A-D route for a
> > (C-S,C-G) state on a receiver site PE.
> > It seems to me that, the receiver site PE will respond only to the
> > *ONE* 'Match for Reception' S-PMSI A-D route, and setup the 
> > 'reception state' only for the 'Matched' S-PMSI A-D route.
> > But it is not true for an inclusive-selective relation between 
> > S-PMSI A-D (*,*) and S-PMSI A-D(S,G).
> > Thinking the S-PMSI A-D (*,*) as an Inclusive one, the receiver site 
> > PE with a
> > (C-S,C-G) state should keep its join state on both the S-PMSI A-D
> > (*,*) and S- PMSI A-D(S,G), and setup the 'reception state'

Re: [bess] Question regarding RFC6625 and this draft-->//RE: I-D Action: draft-ietf-bess-mvpn-expl-track-13.txt

[Xiejingrong]

Hi Jeffrey,

The sender PE need to work on (*,*) tunnel for a while (switch-over timer) and 
then switch to the (S,G) tunnel.

To quote RFC6513 section 7.1.1
   The decision to bind a particular C-flow (designated as (C-S,C-G)) to
   a particular P-tunnel, or to switch a particular C-flow to a
   particular P-tunnel, is always made by the PE that is to transmit the
   C-flow onto the P-tunnel.

   When a C-flow is switched from one P-tunnel to another, the purpose
   of running a switch-over timer is to minimize packet loss without
   introducing packet duplication.

Jingrong

-Original Message-
From: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net] 
Sent: Saturday, January 12, 2019 3:29 AM
To: Xiejingrong ; 
draft-ietf-bess-mvpn-expl-tr...@ietf.org
Cc: bess@ietf.org
Subject: RE: Question regarding RFC6625 and this draft-->//RE: [bess] I-D 
Action: draft-ietf-bess-mvpn-expl-track-13.txt

Jingrong,

> It is determined by the sender site PE whether to steer the flow of (C-S, 
> C-G) into (*,*) PMSI-tunnel or (S,G)PMSI-tunnel, and the receiver site PE 
> should work correctly in any case.

Why would the sender PE send into (*, *) when there is a match for (S,G)?

Jeffrey

> -Original Message-
> From: Xiejingrong [mailto:xiejingr...@huawei.com]
> Sent: Thursday, January 10, 2019 11:10 PM
> To: draft-ietf-bess-mvpn-expl-tr...@ietf.org
> Cc: bess@ietf.org
> Subject: Question regarding RFC6625 and this draft-->//RE: [bess] I-D Action:
> draft-ietf-bess-mvpn-expl-track-13.txt
> 
> Hi,
> 
> I have a question regarding RFC6625 and this draft, since this draft 
> is based on the RFC6625.
> 
> In RFC6625 section "3.2.1 Finding the match for (C-S,C-G) for Data
> Reception":
> It defined the rules for Finding the matched S-PMSI A-D route for a 
> (C-S,C-G) state on a receiver site PE.
> It seems to me that, the receiver site PE will respond only to the 
> *ONE* 'Match for Reception' S-PMSI A-D route, and setup the 'reception 
> state' only for the 'Matched' S-PMSI A-D route.
> But it is not true for an inclusive-selective relation between S-PMSI 
> A-D (*,*) and S-PMSI A-D(S,G).
> Thinking the S-PMSI A-D (*,*) as an Inclusive one, the receiver site 
> PE with a
> (C-S,C-G) state should keep its join state on both the S-PMSI A-D 
> (*,*) and S- PMSI A-D(S,G), and setup the 'reception state' on both 
> the (*,*) PMSI-tunnel and (S,G) PMSI-tunnel.
> It is determined by the sender site PE whether to steer the flow of 
> (C-S, C-G) into (*,*) PMSI-tunnel or (S,G)PMSI-tunnel, and the 
> receiver site PE should work correctly in any case.
> 
> My question:
> Is the section 3.2.1 or RFC6625 wrong and should the 'Match for Reception'
> include *one or many* S-PMSI A-D routes ?
> Is it a problem that can affect this draft ?
> 
> Thanks
> Jingrong.
> 
> 
> -Original Message-
> From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of internet- 
> dra...@ietf.org
> Sent: Thursday, November 29, 2018 12:27 AM
> To: i-d-annou...@ietf.org
> Cc: bess@ietf.org
> Subject: [bess] I-D Action: draft-ietf-bess-mvpn-expl-track-13.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the BGP Enabled ServiceS WG of the IETF.
> 
> Title   : Explicit Tracking with Wild Card Routes in 
> Multicast VPN
> Authors : Andrew Dolganow
>   Jayant Kotalwar
>   Eric C. Rosen
>   Zhaohui Zhang
>   Filename: draft-ietf-bess-mvpn-expl-track-13.txt
>   Pages   : 21
>   Date: 2018-11-28
> 
> Abstract:
>The Multicast VPN (MVPN) specifications provide procedures to allow a
>multicast ingress node to invoke "explicit tracking" for a multicast
>flow or set of flows, thus learning the egress nodes for that flow or
>set of flows.  However, the specifications are not completely clear
>about how the explicit tracking procedures work in certain scenarios.
>This document provides the necessary clarifications.  It also
>specifies a new, optimized explicit tracking procedure.  This new
>procedure allows an ingress node, by sending a single message, to
>request explicit tracking of each of a set of flows, where the set of
>flows is specified using a wildcard mechanism.  This document updates
>RFCs 6514, 6625, 7524, 7582, and 7900.
> 
> 
> The IETF datatracker status page for this draft is:
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dbess-2Dmvpn-2Dexpl-
> 2Dtrack_=DwIFAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&am

[bess] Question regarding RFC6625 and this draft-->//RE: I-D Action: draft-ietf-bess-mvpn-expl-track-13.txt

[Xiejingrong]

Hi,

I have a question regarding RFC6625 and this draft, since this draft is based 
on the RFC6625.

In RFC6625 section "3.2.1 Finding the match for (C-S,C-G) for Data Reception":
It defined the rules for Finding the matched S-PMSI A-D route for a (C-S,C-G) 
state on a receiver site PE.
It seems to me that, the receiver site PE will respond only to the *ONE* 'Match 
for Reception' S-PMSI A-D route, and setup the 'reception state' only for the 
'Matched' S-PMSI A-D route.
But it is not true for an inclusive-selective relation between S-PMSI A-D (*,*) 
and S-PMSI A-D(S,G).
Thinking the S-PMSI A-D (*,*) as an Inclusive one, the receiver site PE with a 
(C-S,C-G) state should keep its join state on both the S-PMSI A-D (*,*) and 
S-PMSI A-D(S,G), and setup the 'reception state' on both the (*,*) PMSI-tunnel 
and (S,G) PMSI-tunnel.
It is determined by the sender site PE whether to steer the flow of (C-S, C-G) 
into (*,*) PMSI-tunnel or (S,G)PMSI-tunnel, and the receiver site PE should 
work correctly in any case.

My question: 
Is the section 3.2.1 or RFC6625 wrong and should the 'Match for Reception' 
include *one or many* S-PMSI A-D routes ?
Is it a problem that can affect this draft ?

Thanks
Jingrong.


-Original Message-
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org
Sent: Thursday, November 29, 2018 12:27 AM
To: i-d-annou...@ietf.org
Cc: bess@ietf.org
Subject: [bess] I-D Action: draft-ietf-bess-mvpn-expl-track-13.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the BGP Enabled ServiceS WG of the IETF.

Title   : Explicit Tracking with Wild Card Routes in Multicast 
VPN
Authors : Andrew Dolganow
  Jayant Kotalwar
  Eric C. Rosen
  Zhaohui Zhang
Filename: draft-ietf-bess-mvpn-expl-track-13.txt
Pages   : 21
Date: 2018-11-28

Abstract:
   The Multicast VPN (MVPN) specifications provide procedures to allow a
   multicast ingress node to invoke "explicit tracking" for a multicast
   flow or set of flows, thus learning the egress nodes for that flow or
   set of flows.  However, the specifications are not completely clear
   about how the explicit tracking procedures work in certain scenarios.
   This document provides the necessary clarifications.  It also
   specifies a new, optimized explicit tracking procedure.  This new
   procedure allows an ingress node, by sending a single message, to
   request explicit tracking of each of a set of flows, where the set of
   flows is specified using a wildcard mechanism.  This document updates
   RFCs 6514, 6625, 7524, 7582, and 7900.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-expl-track/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bess-mvpn-expl-track-13
https://datatracker.ietf.org/doc/html/draft-ietf-bess-mvpn-expl-track-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-mvpn-expl-track-13


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
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 early allocation request for draft-ietf-bess-mvpn-evpn-aggregation-label

[Xiejingrong]

Hi Jeffrey,

Thanks for clarifying that there is nothing special on data-plane comparing to 
the Upstream-assigned label following a P2MP label as mentioned in RFC6513. It 
help me much.

About the case (maybe the worst case) when it is difficult to allocate a 
'domain-wide unique' DCB-context-label,
do you think it helpful for an allocation of 'reserved' label (value from 0 to 
15) to represent a 'Context-label' to make the interoperability mandatory ?

Jingrong


From: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net]
Sent: Friday, December 14, 2018 11:10 PM
To: Xiejingrong ; stephane.litkow...@orange.com; 
bess@ietf.org
Subject: RE: Poll for early allocation request for 
draft-ietf-bess-mvpn-evpn-aggregation-label

Please see zzh3> below.

From: Xiejingrong mailto:xiejingr...@huawei.com>>
Sent: Friday, December 14, 2018 2:10 AM
To: Jeffrey (Zhaohui) Zhang mailto:zzh...@juniper.net>>; 
stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com>; 
bess@ietf.org<mailto:bess@ietf.org>
Subject: RE: Poll for early allocation request for 
draft-ietf-bess-mvpn-evpn-aggregation-label

Hi Jeffrey,

Please see xjr3>> below.

From: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net]
Sent: Thursday, December 13, 2018 10:32 PM
To: Xiejingrong mailto:xiejingr...@huawei.com>>; 
stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com>; 
bess@ietf.org<mailto:bess@ietf.org>
Subject: RE: Poll for early allocation request for 
draft-ietf-bess-mvpn-evpn-aggregation-label

Hi Jingrong,

Please see zzh2> below.

From: BESS mailto:bess-boun...@ietf.org>> On Behalf Of 
Xiejingrong
Sent: Wednesday, December 12, 2018 9:24 PM
To: Jeffrey (Zhaohui) Zhang mailto:zzh...@juniper.net>>; 
stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com>; 
bess@ietf.org<mailto:bess@ietf.org>
Subject: Re: [bess] Poll for early allocation request for 
draft-ietf-bess-mvpn-evpn-aggregation-label


s/inter-area/intra-area/g

From: Xiejingrong
Sent: Thursday, December 13, 2018 10:22 AM
To: 'Jeffrey (Zhaohui) Zhang' mailto:zzh...@juniper.net>>; 
stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com>; 
bess@ietf.org<mailto:bess@ietf.org>
Subject: RE: Poll for early allocation request for 
draft-ietf-bess-mvpn-evpn-aggregation-label

Hi Jeffrey,

Let me take the section 2.2.3 for explaination:

   In summary, labels can be allocated and advertised the following
   ways:

   1.  A central authority allocates per-VPN/BD/ES labels from the DCB.
   PEs advertise the labels with an indication that they are from
   the DCB.

   2.  A central authority allocates per-VPN/BD/ES labels from a few
   common context label spaces, and allocate labels from the DCB to
   identify those context label spaces.  PEs advertise the VPN/BD
   labels along with the context-identifying labels.

   3.  A central authority assigns disjoint label blocks from those a //
   few context label spaces to each PE, and allocate labels from the
   DCB to identify the context label spaces.  Each PE allocates
   labels from its assigned label block independently for its
   segmented S-PMSI, along with the context-identifying labels.

   Option 1 is simplest, but it requires that all the PEs set aside a
   common label block for the DCB that is large enough for all the
   VPNs/BDs/ESes combined.  Option 3 is needed only for segmented
   selective tunnels that are set up dynamically.  Multiple options
   could be used in any combination depending on the deployment
   situation.

Option-1 is simplest and I like it very much (anyone who don't like 
simplification?). For Inter-area EVPN deployment scenarios, it is strong and 
simple enough I think.

Zzh2> So I assume you're not objecting to the early allocation for DCB-flag at 
least?
XJR3>> I don't understand how a DCB-flag in PTA is necessary in opinion-1.  
Does it used to do consistency check ?

Zzh3> If you don't carry that flag, how do you know if the label is upstream 
assigned or from the DCB?

But when it is not the suitable case, and Option-2 has to be used, I think 
things are becoming complex: You still need a DCB from 'main/default' 
label-space, though this DCB is very small, which maybe only include ONE label. 
And then the ONE label is used as 'context-label'. While for BIER case, BIER 
header itself can act as a 'BIER-Context' naturally. Am I understanding 
correctly ?

Zzh2> Nowadays with the adoption of SR, allocating SAME SRGBs across routers is 
not difficult and is the preferred way. If you use DCB (could just be the SRGB 
itself) for non-segmented case, what's the concern with allocating a context 
label from the DCB/SRGB? See later comment about BIER-context.
XJR3>> OK for non-segmented case (mainly intra-area, at least intra-AS case).

For Option-3, I do understand it as two sub-options, Option-3a if there is 
enough 

Re: [bess] Poll for early allocation request for draft-ietf-bess-mvpn-evpn-aggregation-label

[Xiejingrong]

Hi Stephane,

Thank you for raising the meaningful discussion on this draft.

I am not against the early allocation, because the allocation needed by the 
DCB-context-label can help the aggregated  P2MP/MP2MP for MVPN/EVPN as an 
extension to the current RFC6513.

I am not convinced to follow the DCB-context-label for BIER/SegmentedMVPN 
cases,  but this can be discussed later.

Thanks,
Jingrong.


From: stephane.litkow...@orange.com [mailto:stephane.litkow...@orange.com]
Sent: Thursday, December 13, 2018 4:40 PM
To: Xiejingrong ; Jeffrey (Zhaohui) Zhang 
; bess@ietf.org
Subject: RE: Poll for early allocation request for 
draft-ietf-bess-mvpn-evpn-aggregation-label

Hi Jingrong,

Speaking as co-chair, what I need to know from this discussion is if there is a 
blocking point for the early allocation.
Yes, of course the draft will require some polishing, clarifications... as 
Jeffrey has mentioned, this is not a WGLC.

Based on your last sentence (and the overall discussion), I don't see any real 
blocking point but I want this to be crystal clear. So please state clearly if 
you object to the early allocation or not and why. What is important to me is 
to ensure that the encoding is stable and does not require any change.


Thanks,

Stephane



From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Xiejingrong
Sent: Thursday, December 13, 2018 03:24
To: Jeffrey (Zhaohui) Zhang; LITKOWSKI Stephane OBS/OINIS; 
bess@ietf.org<mailto:bess@ietf.org>
Subject: Re: [bess] Poll for early allocation request for 
draft-ietf-bess-mvpn-evpn-aggregation-label


s/inter-area/intra-area/g

From: Xiejingrong
Sent: Thursday, December 13, 2018 10:22 AM
To: 'Jeffrey (Zhaohui) Zhang' mailto:zzh...@juniper.net>>; 
stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com>; 
bess@ietf.org<mailto:bess@ietf.org>
Subject: RE: Poll for early allocation request for 
draft-ietf-bess-mvpn-evpn-aggregation-label

Hi Jeffrey,

Let me take the section 2.2.3 for explaination:

   In summary, labels can be allocated and advertised the following
   ways:

   1.  A central authority allocates per-VPN/BD/ES labels from the DCB.
   PEs advertise the labels with an indication that they are from
   the DCB.

   2.  A central authority allocates per-VPN/BD/ES labels from a few
   common context label spaces, and allocate labels from the DCB to
   identify those context label spaces.  PEs advertise the VPN/BD
   labels along with the context-identifying labels.

   3.  A central authority assigns disjoint label blocks from those a //
   few context label spaces to each PE, and allocate labels from the
   DCB to identify the context label spaces.  Each PE allocates
   labels from its assigned label block independently for its
   segmented S-PMSI, along with the context-identifying labels.

   Option 1 is simplest, but it requires that all the PEs set aside a
   common label block for the DCB that is large enough for all the
   VPNs/BDs/ESes combined.  Option 3 is needed only for segmented
   selective tunnels that are set up dynamically.  Multiple options
   could be used in any combination depending on the deployment
   situation.

Option-1 is simplest and I like it very much (anyone who don't like 
simplification?). For Inter-area EVPN deployment scenarios, it is strong and 
simple enough I think.
But when it is not the suitable case, and Option-2 has to be used, I think 
things are becoming complex: You still need a DCB from 'main/default' 
label-space, though this DCB is very small, which maybe only include ONE label. 
And then the ONE label is used as 'context-label'. While for BIER case, BIER 
header itself can act as a 'BIER-Context' naturally. Am I understanding 
correctly ?
For Option-3, I do understand it as two sub-options, Option-3a if there is 
enough number of Labels in the DCB, and Option-3b if there isn't and the ONE 
'DCB' label is used as context-label. Each one is difficult for me to consider 
the development and deployment. One the other hand, the segmented MVPN can use 
the 'UMH' mechanism to select the right upstream-assigned VpnLabel to download 
to forwarding states.

So my summarized comments:
DCB is similar to VNI very much, but the MPLS labels in the "main/default" 
space is very costly due to the 'per-platform' (RFC5331) allocation.
DCB is similar to SRGB very much, but DCB requires 'absolute' unique value 
other than the 'unique' index in SRGB(at least has such mechanism).
Use of context-label from a DCB can be comparable to the use of the 
'BIER-specific' context in case of BIER.
Use of 'dynamic' allocation with DCB mechanism in segmented MVPN deployment may 
add extra complexity.

I suggest this draft to make more clear what the use cases are, what it really 
want to solve, and what it don't.

Thanks.
Jingrong



From: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net]
Sent: Wednesday, December 12, 2018 10:42 PM
To: Xiejing

Re: [bess] Poll for early allocation request for draft-ietf-bess-mvpn-evpn-aggregation-label

[Xiejingrong]

Hi Jeffrey,

Please see xjr3>> below.

From: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net]
Sent: Thursday, December 13, 2018 10:32 PM
To: Xiejingrong ; stephane.litkow...@orange.com; 
bess@ietf.org
Subject: RE: Poll for early allocation request for 
draft-ietf-bess-mvpn-evpn-aggregation-label

Hi Jingrong,

Please see zzh2> below.

From: BESS mailto:bess-boun...@ietf.org>> On Behalf Of 
Xiejingrong
Sent: Wednesday, December 12, 2018 9:24 PM
To: Jeffrey (Zhaohui) Zhang mailto:zzh...@juniper.net>>; 
stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com>; 
bess@ietf.org<mailto:bess@ietf.org>
Subject: Re: [bess] Poll for early allocation request for 
draft-ietf-bess-mvpn-evpn-aggregation-label


s/inter-area/intra-area/g

From: Xiejingrong
Sent: Thursday, December 13, 2018 10:22 AM
To: 'Jeffrey (Zhaohui) Zhang' mailto:zzh...@juniper.net>>; 
stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com>; 
bess@ietf.org<mailto:bess@ietf.org>
Subject: RE: Poll for early allocation request for 
draft-ietf-bess-mvpn-evpn-aggregation-label

Hi Jeffrey,

Let me take the section 2.2.3 for explaination:

   In summary, labels can be allocated and advertised the following
   ways:

   1.  A central authority allocates per-VPN/BD/ES labels from the DCB.
   PEs advertise the labels with an indication that they are from
   the DCB.

   2.  A central authority allocates per-VPN/BD/ES labels from a few
   common context label spaces, and allocate labels from the DCB to
   identify those context label spaces.  PEs advertise the VPN/BD
   labels along with the context-identifying labels.

   3.  A central authority assigns disjoint label blocks from those a //
   few context label spaces to each PE, and allocate labels from the
   DCB to identify the context label spaces.  Each PE allocates
   labels from its assigned label block independently for its
   segmented S-PMSI, along with the context-identifying labels.

   Option 1 is simplest, but it requires that all the PEs set aside a
   common label block for the DCB that is large enough for all the
   VPNs/BDs/ESes combined.  Option 3 is needed only for segmented
   selective tunnels that are set up dynamically.  Multiple options
   could be used in any combination depending on the deployment
   situation.

Option-1 is simplest and I like it very much (anyone who don't like 
simplification?). For Inter-area EVPN deployment scenarios, it is strong and 
simple enough I think.

Zzh2> So I assume you're not objecting to the early allocation for DCB-flag at 
least?
XJR3>> I don't understand how a DCB-flag in PTA is necessary in opinion-1.  
Does it used to do consistency check ?

But when it is not the suitable case, and Option-2 has to be used, I think 
things are becoming complex: You still need a DCB from 'main/default' 
label-space, though this DCB is very small, which maybe only include ONE label. 
And then the ONE label is used as 'context-label'. While for BIER case, BIER 
header itself can act as a 'BIER-Context' naturally. Am I understanding 
correctly ?

Zzh2> Nowadays with the adoption of SR, allocating SAME SRGBs across routers is 
not difficult and is the preferred way. If you use DCB (could just be the SRGB 
itself) for non-segmented case, what's the concern with allocating a context 
label from the DCB/SRGB? See later comment about BIER-context.
XJR3>> OK for non-segmented case (mainly intra-area, at least intra-AS case).

For Option-3, I do understand it as two sub-options, Option-3a if there is 
enough number of Labels in the DCB, and Option-3b if there isn't and the ONE 
'DCB' label is used as context-label. Each one is difficult for me to consider 
the development and deployment. One the other hand, the segmented MVPN can use 
the 'UMH' mechanism to select the right upstream-assigned VpnLabel to download 
to forwarding states.

Zzh2> There is no 3a. There could be multiple DCB labels for multiple context 
label spaces, either because of scaling requirement (in theory) or for whatever 
reason an operator wants to use multiple.
Zzh2> I don't think selectively installing upstream assigned labels based on 
UMH is good enough (and it introduces more complexity). The sources could be 
everywhere, and in case of EVPN, the forwarding could be (*,g) based, so you'll 
end up with the original problem.
XJR3>> OK. Thanks for the clarification.
XJR3>> For segmented case stated in this opinion, the section 2.2.2.1 stated 
that, it does not address the original scaling issue.

So my summarized comments:
DCB is similar to VNI very much, but the MPLS labels in the "main/default" 
space is very costly due to the 'per-platform' (RFC5331) allocation.

Zzh2> If one can do common SRGB for SR, then one can do DCB for MVPN/EVPN. If 
you're still concerned with that, you can have a separate context label space 
for EVPN/MVPN pur

Re: [bess] Poll for early allocation request for draft-ietf-bess-mvpn-evpn-aggregation-label

[Xiejingrong]

s/inter-area/intra-area/g

From: Xiejingrong
Sent: Thursday, December 13, 2018 10:22 AM
To: 'Jeffrey (Zhaohui) Zhang' ; 
stephane.litkow...@orange.com; bess@ietf.org
Subject: RE: Poll for early allocation request for 
draft-ietf-bess-mvpn-evpn-aggregation-label

Hi Jeffrey,

Let me take the section 2.2.3 for explaination:

   In summary, labels can be allocated and advertised the following
   ways:

   1.  A central authority allocates per-VPN/BD/ES labels from the DCB.
   PEs advertise the labels with an indication that they are from
   the DCB.

   2.  A central authority allocates per-VPN/BD/ES labels from a few
   common context label spaces, and allocate labels from the DCB to
   identify those context label spaces.  PEs advertise the VPN/BD
   labels along with the context-identifying labels.

   3.  A central authority assigns disjoint label blocks from those a //
   few context label spaces to each PE, and allocate labels from the
   DCB to identify the context label spaces.  Each PE allocates
   labels from its assigned label block independently for its
   segmented S-PMSI, along with the context-identifying labels.

   Option 1 is simplest, but it requires that all the PEs set aside a
   common label block for the DCB that is large enough for all the
   VPNs/BDs/ESes combined.  Option 3 is needed only for segmented
   selective tunnels that are set up dynamically.  Multiple options
   could be used in any combination depending on the deployment
   situation.

Option-1 is simplest and I like it very much (anyone who don't like 
simplification?). For Inter-area EVPN deployment scenarios, it is strong and 
simple enough I think.
But when it is not the suitable case, and Option-2 has to be used, I think 
things are becoming complex: You still need a DCB from 'main/default' 
label-space, though this DCB is very small, which maybe only include ONE label. 
And then the ONE label is used as 'context-label'. While for BIER case, BIER 
header itself can act as a 'BIER-Context' naturally. Am I understanding 
correctly ?
For Option-3, I do understand it as two sub-options, Option-3a if there is 
enough number of Labels in the DCB, and Option-3b if there isn't and the ONE 
'DCB' label is used as context-label. Each one is difficult for me to consider 
the development and deployment. One the other hand, the segmented MVPN can use 
the 'UMH' mechanism to select the right upstream-assigned VpnLabel to download 
to forwarding states.

So my summarized comments:
DCB is similar to VNI very much, but the MPLS labels in the "main/default" 
space is very costly due to the 'per-platform' (RFC5331) allocation.
DCB is similar to SRGB very much, but DCB requires 'absolute' unique value 
other than the 'unique' index in SRGB(at least has such mechanism).
Use of context-label from a DCB can be comparable to the use of the 
'BIER-specific' context in case of BIER.
Use of 'dynamic' allocation with DCB mechanism in segmented MVPN deployment may 
add extra complexity.

I suggest this draft to make more clear what the use cases are, what it really 
want to solve, and what it don't.

Thanks.
Jingrong



From: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net]
Sent: Wednesday, December 12, 2018 10:42 PM
To: Xiejingrong mailto:xiejingr...@huawei.com>>; 
stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com>; 
bess@ietf.org<mailto:bess@ietf.org>
Subject: RE: Poll for early allocation request for 
draft-ietf-bess-mvpn-evpn-aggregation-label

Jingrong,

Please see zzh> below.

From: BESS mailto:bess-boun...@ietf.org>> On Behalf Of 
Xiejingrong
Sent: Tuesday, December 11, 2018 8:14 PM
To: stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com>; 
bess@ietf.org<mailto:bess@ietf.org>
Subject: Re: [bess] Poll for early allocation request for 
draft-ietf-bess-mvpn-evpn-aggregation-label

Objection.

Zzh> Please note that this is not a LC for the draft. This is the poll for 
early allocation for the DCB-flag and an extended community type.

I remember I have raised my concerns, but I didn't find the response.

Zzh> Sorry for missing those. Please see below.

Copy the concerns I have listed before:

1.   The problem stated by this draft is valid, and the proposed method is 
useful for some of the listed problem. For example, EVPN BUM who uses MPLS 
identification and dataplane.
Zzh> Do you think the proposed solution is reasonable for the problems? If so, 
we would like to see early allocation is done. The allocation is temporary - it 
would time out after some time if the draft does not become a RFC.

2.   EVPN BUM using vxlan/vni identification may not need a MPLS label to 
identify the vpn/tenant.
Zzh> The draft is about "aggregation label", so vxlan/vni is irrelevant. On the 
other hand, in case of vxlan/vni, the VNI is no different from a DCB label in 
concept (so the solution of using DCB label sho

Re: [bess] Poll for early allocation request for draft-ietf-bess-mvpn-evpn-aggregation-label

[Xiejingrong]

Hi Jeffrey,

Let me take the section 2.2.3 for explaination:

   In summary, labels can be allocated and advertised the following
   ways:

   1.  A central authority allocates per-VPN/BD/ES labels from the DCB.
   PEs advertise the labels with an indication that they are from
   the DCB.

   2.  A central authority allocates per-VPN/BD/ES labels from a few
   common context label spaces, and allocate labels from the DCB to
   identify those context label spaces.  PEs advertise the VPN/BD
   labels along with the context-identifying labels.

   3.  A central authority assigns disjoint label blocks from those a //
   few context label spaces to each PE, and allocate labels from the
   DCB to identify the context label spaces.  Each PE allocates
   labels from its assigned label block independently for its
   segmented S-PMSI, along with the context-identifying labels.

   Option 1 is simplest, but it requires that all the PEs set aside a
   common label block for the DCB that is large enough for all the
   VPNs/BDs/ESes combined.  Option 3 is needed only for segmented
   selective tunnels that are set up dynamically.  Multiple options
   could be used in any combination depending on the deployment
   situation.

Option-1 is simplest and I like it very much (anyone who don't like 
simplification?). For Inter-area EVPN deployment scenarios, it is strong and 
simple enough I think.
But when it is not the suitable case, and Option-2 has to be used, I think 
things are becoming complex: You still need a DCB from 'main/default' 
label-space, though this DCB is very small, which maybe only include ONE label. 
And then the ONE label is used as 'context-label'. While for BIER case, BIER 
header itself can act as a 'BIER-Context' naturally. Am I understanding 
correctly ?
For Option-3, I do understand it as two sub-options, Option-3a if there is 
enough number of Labels in the DCB, and Option-3b if there isn't and the ONE 
'DCB' label is used as context-label. Each one is difficult for me to consider 
the development and deployment. One the other hand, the segmented MVPN can use 
the 'UMH' mechanism to select the right upstream-assigned VpnLabel to download 
to forwarding states.

So my summarized comments:
DCB is similar to VNI very much, but the MPLS labels in the "main/default" 
space is very costly due to the 'per-platform' (RFC5331) allocation.
DCB is similar to SRGB very much, but DCB requires 'absolute' unique value 
other than the 'unique' index in SRGB(at least has such mechanism).
Use of context-label from a DCB can be comparable to the use of the 
'BIER-specific' context in case of BIER.
Use of 'dynamic' allocation with DCB mechanism in segmented MVPN deployment may 
add extra complexity.

I suggest this draft to make more clear what the use cases are, what it really 
want to solve, and what it don't.

Thanks.
Jingrong



From: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net]
Sent: Wednesday, December 12, 2018 10:42 PM
To: Xiejingrong ; stephane.litkow...@orange.com; 
bess@ietf.org
Subject: RE: Poll for early allocation request for 
draft-ietf-bess-mvpn-evpn-aggregation-label

Jingrong,

Please see zzh> below.

From: BESS mailto:bess-boun...@ietf.org>> On Behalf Of 
Xiejingrong
Sent: Tuesday, December 11, 2018 8:14 PM
To: stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com>; 
bess@ietf.org<mailto:bess@ietf.org>
Subject: Re: [bess] Poll for early allocation request for 
draft-ietf-bess-mvpn-evpn-aggregation-label

Objection.

Zzh> Please note that this is not a LC for the draft. This is the poll for 
early allocation for the DCB-flag and an extended community type.

I remember I have raised my concerns, but I didn't find the response.

Zzh> Sorry for missing those. Please see below.

Copy the concerns I have listed before:

1.   The problem stated by this draft is valid, and the proposed method is 
useful for some of the listed problem. For example, EVPN BUM who uses MPLS 
identification and dataplane.
Zzh> Do you think the proposed solution is reasonable for the problems? If so, 
we would like to see early allocation is done. The allocation is temporary - it 
would time out after some time if the draft does not become a RFC.

2.   EVPN BUM using vxlan/vni identification may not need a MPLS label to 
identify the vpn/tenant.
Zzh> The draft is about "aggregation label", so vxlan/vni is irrelevant. On the 
other hand, in case of vxlan/vni, the VNI is no different from a DCB label in 
concept (so the solution of using DCB label should be reasonable).

3.   For MVPN who has a UMH(Upstream Multicast Hop) selection procedure, the 
exist using of upstream-assigned VpnLabel can be optimized to only populate to 
forwarding-state when there are c-multicast flows selecting the specific UMH PE.
Zzh> If that is a better solution, perhaps a separate draft can be written. The 
solution in this draft is

Re: [bess] Poll for early allocation request for draft-ietf-bess-mvpn-evpn-aggregation-label

[Xiejingrong]

Objection.

I remember I have raised my concerns, but I didn't find the response.

Copy the concerns I have listed before:
1.  The problem stated by this draft is valid, and the proposed method is 
useful for some of the listed problem. For example, EVPN BUM who uses MPLS 
identification and dataplane.
2.  EVPN BUM using vxlan/vni identification may not need a MPLS label to 
identify the vpn/tenant.
3.  For MVPN who has a UMH(Upstream Multicast Hop) selection procedure, the 
exist using of upstream-assigned VpnLabel can be optimized to only populate to 
forwarding-state when there are c-multicast flows selecting the specific UMH PE.
4.  For an End-to-End deployment of MVPN who spans multi-ASes as the way 
stated in , the allocation of a 
global-unique label is useful and possible. But operators may need to be very 
careful to allocate the very limited MPLS labels. Because, MPLS labels has been 
divided to SRLB and SRGB, and SRGB may have been again divided by SR-domains 
according to .
5.  For segmented MVPN deployment, the further divide of the MPLS Label is 
also difficult when thinking of the above.
6.  For BIER, is the BIER proto=1 indicating a BIER-specific unique 
VpnLabel ? or a Per-platform (RFC5331) downstream-assigned unique label ?  if 
it is the later one, how about adding a new BIER proto value to indicating a 
BIER-specific unique VpnLabel ?  And then a static Context (BIER) can be 
optional to the dynamic advertising of a Context ?

Jingrong


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Tuesday, December 11, 2018 11:10 PM
To: bess@ietf.org
Subject: [bess] Poll for early allocation request for 
draft-ietf-bess-mvpn-evpn-aggregation-label

Hi WG,

We have received an early allocation request for the 
draft-ietf-bess-mvpn-evpn-aggregation-label.

Please raise your concerns if you object to this request and if you think that 
the document is not mature enough.
Feel also free to support this request.

We will wait until next Monday (12/17) to gather feedbacks.

Thanks,

Stephane



_



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 IPR poll for draft-liu-bess-mvpn-yang-07

[Xiejingrong]

I support the adoption.

Thanks,
Jingrong

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Bocci, Matthew (Nokia - 
GB)
Sent: Monday, December 03, 2018 10:53 PM
To: bess@ietf.org
Cc: draft-liu-bess-mvpn-y...@ietf.org
Subject: [bess] Wg Adoption and IPR poll for draft-liu-bess-mvpn-yang-07

This email begins a two-week poll for adoption of 
draft-liu-bess-mvpn-yang-07.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 Monday 17th December 2018.

Regards,
Matthew


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

Re: [bess] WG adoption poll for draft-zzhang-bess-mvpn-evpn-aggregation-label-01

[Xiejingrong]

+1 support the adoption.

My comments:

1.  The problem stated by this draft is valid, and the proposed method is 
useful for some of the listed problem. For example, EVPN BUM who uses MPLS 
identification and dataplane.

2.  EVPN BUM using vxlan/vni identification may not need a MPLS label to 
identify the vpn/tenant.

3.  For MVPN who has a UMH(Upstream Multicast Hop) selection procedure, the 
exist using of upstream-assigned VpnLabel can be optimized to only populate to 
forwarding-state when there are c-multicast flows selecting the specific UMH PE.

4.  For an End-to-End deployment of MVPN who spans multi-ASes as the way 
stated in , the allocation of a 
global-unique label is useful and possible. But operators may need to be very 
careful to allocate the very limited MPLS labels. Because, MPLS labels has been 
divided to SRLB and SRGB, and SRGB may have been again divided by SR-domains 
according to .

5.  For segmented MVPN deployment, the further divide of the MPLS Label is 
also difficult when thinking of the above.

6.  For BIER, is the BIER proto=1 indicating a BIER-specific unique 
VpnLabel ? or a Per-platform (RFC5331) downstream-assigned unique label ?  if 
it is the later one, how about adding a new BIER proto value to indicating a 
BIER-specific unique VpnLabel ?  And then a static Context (BIER) can be 
optional to the dynamic advertising of a Context ?


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Tuesday, October 30, 2018 4:22 PM
To: bess@ietf.org
Subject: [bess] WG adoption poll for 
draft-zzhang-bess-mvpn-evpn-aggregation-label-01

Hi WG,

This email begins a two-week poll for BESS working group adoption 
draft-zzhang-bess-mvpn-evpn-aggregation-label-01 [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 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.

The poll for working group adoption closes on Tue 13th November.

Regards,
Stéphane and Matthew

[1] 
https://datatracker.ietf.org/doc/draft-zzhang-bess-mvpn-evpn-aggregation-label/





[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] I-D Action: draft-ietf-bess-mvpn-expl-track-12.txt

[Xiejingrong]

BESS WG:

Had the IANA ack'ed the request of adding the value 2 (Name LIR-PF) ?

I have not seen it in 
https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#pmsi-tunnel-attributes

Thanks.
Jingrong

-Original Message-
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org
Sent: Wednesday, October 10, 2018 12:53 AM
To: i-d-annou...@ietf.org
Cc: bess@ietf.org
Subject: [bess] I-D Action: draft-ietf-bess-mvpn-expl-track-12.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the BGP Enabled ServiceS WG of the IETF.

Title   : Explicit Tracking with Wild Card Routes in Multicast 
VPN
Authors : Andrew Dolganow
  Jayant Kotalwar
  Eric C. Rosen
  Zhaohui Zhang
Filename: draft-ietf-bess-mvpn-expl-track-12.txt
Pages   : 18
Date: 2018-10-09

Abstract:
   The MVPN specifications provide procedures to allow a multicast
   ingress node to invoke "explicit tracking" for a multicast flow or
   set of flows, thus learning the egress nodes for that flow or set of
   flows.  However, the specifications are not completely clear about
   how the explicit tracking procedures work in certain scenarios.  This
   document provides the necessary clarifications.  It also specifies a
   new, optimized explicit tracking procedure.  This new procedure
   allows an ingress node, by sending a single message, to request
   explicit tracking of each of a set of flows, where the set of flows
   is specified using a wildcard mechanism.  This document updates RFCs
   6514, 6625, and 7524.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-expl-track/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bess-mvpn-expl-track-12
https://datatracker.ietf.org/doc/html/draft-ietf-bess-mvpn-expl-track-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-mvpn-expl-track-12


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
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] Comments on draft-sajassi-bess-evpn-mvpn-seamless-interop-01

[Xiejingrong]

Hi folks,
I have some comments on draft-sajassi-bess-evpn-mvpn-seamless-interop-01:

(1) For section 9.2.2 where it stated "The MPLS label in the PMSI Tunnel 
Attribute MUST be the Virtual Network Identifier (VNI) associated with the 
customer MVPN.",

I think the VNI need not being included in 'MPLS Label' field of PTA, because 
every IP-VRF has a static configuration of the VNI value.

(2) Some terminologies are lacking, for example CO and SPDC. I think they 
are different things, and authors can make clear about them.

(3) Some references are lacking, for example [EVPN-IRB] in section 5, and 
[EVPN-IRB-MCAST] in section 9.

(4) There are two nodes named 'PE3' repeatedly in Figure 1 and Figure 2..

(5) For section 7.1 where it use 'Intra-subnet/Intra-ES', I think the 
'Intra-subnet' is confusing and conflicting with general concepts as used in 
section 5.

Thanks
Jingrong

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

[bess] [bier] Comments on draft-ietf-bier-mvpn

[Xiejingrong]

Hi, Authors:

I have a question about : whether we can leverage 
LIR-pF in segmented tunnels scenario, to get a better multicast join latency ?

This draft states that Segmented P-tunnels require per-flow vpnlabel, so have 
to use S-PMSI(S,G) AD routes to carry such per-flow vpnLabel.

Obviously, this will result in an increase in the number of routes, and more 
importantly an increase in multicast join latency, comparing to the case of 
Non-Segmented P-tunnels using LIR-pF.

My consideration is , When all segments are type of BIER (greenfield), Is it 
possible to use a Per-vpn VpnLabel, and use LIR-pF for efficiently explicit 
tracking ? like below:

Topo: [SRC--IngressPE--ABR--EgressPE--RCV]
1) Use I-PMSI route with 

Re: [bess] Comments on draft-ietf-bess-mvpn-expl-track-03

[Xiejingrong]

Fully understood, and -06 version is ok to me.
Thanks for Eric's patient explanation.
Thanks for Stephane also.
In MVPN using BIER Segmented Scenario, ABR needs Per-flow's VpnLabels to do 
further forwarding sticking, so that we can not use a SPMSI (*,*, PTA 

[bess] Comments on draft-ietf-bess-mvpn-expl-track-03

[Xiejingrong]

I have a comment on draft-ietf-bess-mvpn-expl-track-03.

The chap 5.3 of this document said:

Furthermore, if the PTA specifies "no tunnel info", the LIR and LIR-pF
flags in the PTA MUST be passed along unchanged.

   This will ensure that an egress ABR/ASBR only sends a Leaf A-D route
   in response to a "match for tracking" if it is on the path to an
   egress PE for the flow(s) identified in the corresponding S-PMSI A-D
   route.

The issue is as follow:
In a [IngressPE--EgressABR--EgressPE] topology, IngressPE send a Wildcard 
S-PMSI(*,*) route with PTA(flag<LIR+LIR-pF>), whose NLRI is donated as  
SPMSI(type<0/1/2>RD,*,*,IngressPE). This SPMSI route will be relayed by 
EgressABR to EgressPE with PTA flag untouched. Then EgressPE will generate ONE 
LeafAD route with NLRI(type<0/1/2>RD,*,*,IngressPE,EgressPE) and RT 
and N(N>=0) LeafAD routes with NLRI(type<16/17/18>RD,S,G,IngressPE,EgressPE) 
and RT. All according to chap 5.2 of this document.

Then according to chap 5.3  of this document:
IngressABR will only send a Leaf A-D route, It should be the ONE of 
LeafAD(type<0/1/2RD,*,*,IngressPE,EgressABR) with RT.
Then how should IngressABR deal with the the N(N>=0) LeafAD routes with 
NLRI(type<16/17/18>RD,S,G,IngressPE,EgressPE) and RT ?
It is not clarified in RFC7524 either. See chap 7.1 of RFC7524, which only 
clarify LeafAD route with type<0/1/2>RD.
Should such LeafAD route with type<16/17/18>RD be accepted and installed by 
EgressABR, and then 'relay' back to IngressPE, and thus enable IngressPE 
explicit tracking inside the ingress "segmentation domain" ?

Thanks.

XieJingrong



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