Subject: Re: WG Last Call: draft-ietf-l2vpn-ipls-09

From: [email-masked]
Date: Sat, 17 Apr 2010 23:15:42 +0800

Hi Himanshu and authors,
After reviewing draft-ietf-l2vpn-ipls-09, I have the following comments:
1. Section 2.0, point 5, bullet c, more precisely, the unicast ARP packets 
received from "multicast" pseudowire may do MAC DA lookup, and forward to 
where CE is located. So the context should add this exception for ARP 
packets.
2. Section 7.1, I am wondering how to setup the unidirectional mp2p 
pseudowire. According to RFC4447, one pseudowire will be UP only when both 
local and remote label mapping message is sent and received. But according 
to the descripition of unidirectional mp2p pseudowire in IPLS, if PEx 
sends a label mapping to PEy for CEx, PEy seems to consider the PW as UP 
when receiving the corresponding label mapping, and PEx would consider the 
PW as UP when sending out the label mapping, without the necessarity of 
allocating local labels for the PW.
What's more, it is also difficult to configure the PWid. If PEx uses 
PWid_1 for CEx1, and PWid_2 for CEx2, according to section 7.1, the PEy 
needs to configure both PWid_1 and PWid_2, which is actually not 
necessary. Do I miss something important here to understand the concept of 
unidirectional mp2p pseudowire? There may be a new type of FEC that is 
required, similar with unidirectional P2MP PW.
3. Section 7.2, why not using LDP capability to advertising IPv6 stack 
capability?
4. Will IPLS consider any spoke connectivity to increase the scalability, 
same as VPLS?

Hope to see your reply, thank you.

Best Regards
Lizhong Jin

------------------------------

Date: Mon, 5 Apr 2010 19:58:01 -0600
From: Shane Amante <[email-masked]>
Subject: WG Last Call: draft-ietf-l2vpn-ipls-09
To: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=us-ascii

Hi Everyone,

This is to begin a (final) WG Last Call on:
http://tools.ietf.org/html/draft-ietf-l2vpn-ipls-09

If you have substantial technical comments or concerns, please share them 
with the list.  If you have editorial comments, please share them directly 
with the authors and co-chairs.

So far, we have the following folks signed up for a thorough review and 
comments:
- Andy Malis
- Nick DelRegno
- Pranjal Dutta
However, we could use more people to conduct a review.  If you have the 
time and/or inclination, please let the chairs know if you'll be 
conducting a review.

The Last Call on this draft will also end on April 23.

Thanks,

Giles & Shane

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: Himanshu Shah <[email-masked]>
Date: Mon, 19 Apr 2010 11:52:29 -0700

Thanks for your comments..
Please see the response in line below.

/himanshu

From: [email-masked] [mailto:[email-masked]]
Sent: Saturday, April 17, 2010 11:16 AM
To: Himanshu Shah; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: WG Last Call: draft-ietf-l2vpn-ipls-09

Hi Himanshu and authors,
After reviewing draft-ietf-l2vpn-ipls-09, I have the following comments:
1. Section 2.0, point 5, bullet c, more precisely, the unicast ARP packets received from "multicast" pseudowire may do MAC DA lookup, and forward to where CE is located. So the context should add this exception for ARP packets
[Himanshu>] I am not sure I fully understand your comment, but I am guessing you are asking to add text to the draft referring the unicast MAC and ARP as the context
to the exception whereby normally all the packets received over "multicast" PW are broadcasted, including this ARP unicast, but as an exception, in this case, one
can optimize the flooding.
.
2. Section 7.1, I am wondering how to setup the unidirectional mp2p pseudowire. According to RFC4447, one pseudowire will be UP only when both local and remote label mapping message is sent and received. But according to the descripition of unidirectional mp2p pseudowire in IPLS, if PEx sends a label mapping to PEy for CEx, PEy seems to consider the PW as UP when receiving the corresponding label mapping, and PEx would consider the PW as UP when sending out the label mapping, without the necessarity of allocating local labels for the PW.
[Himanshu>] There is no one-to-one correspondence with respect to PW directionality. Meaning, if PE1 has two local CE, it will advertise two labels. If PE2 has 4 local CEs it will advertise 4 labels.
Which does not mean that when PE1 receives 4 labels from PE2 that it needs to advertise 4 labels to bring PW 'UP'. So the question, is 'unidirectional' PW a deviation from RFC 4447 which
assumes PW to be bi-directional (this used to be true initially, not sure if still is true) by way of uniting to opposite direction unidirectional PW. The unidirectional PW is not illegal.

What's more, it is also difficult to configure the PWid. If PEx uses PWid_1 for CEx1, and PWid_2 for CEx2, according to section 7.1, the PEy needs to configure both PWid_1 and PWid_2, which is actually not necessary. Do I miss something important here to understand the concept of unidirectional mp2p pseudowire? There may be a new type of FEC that is required, similar with unidirectional P2MP PW.
[Himanshu>] PWid is per IPLS instance and not per CE. I do not see any text in 7.1 which talks about configuring difference PWid for each CE.
For a given IPLS instance a PE has following to signal -

a)    PW id

b)    One MP2P 'multicast'  Ethernet PW

c)     Many (i.e. one per local CE) MP2P 'unicast' IP PW along with CE's MAC address
[Himanshu>] Section 7.1 describes details for send and receive processing of label mapping message

3. Section 7.2, why not using LDP capability to advertising IPv6 stack capability?
[Himanshu>] Because this is specific to PW and IPLS instance

4. Will IPLS consider any spoke connectivity to increase the scalability, same as VPLS?
[Himanshu>] I am not sure I fully understand. IPLS assumes (recommends) that CEs are IP routers that act as edge box.
Meaning most of the customer's IP hosts and  other routers are behind this CE router in customer network and PE does
not see them. This by itself provides good hierarchy & scalability.

Best Regards
Lizhong Jin

Hi Everyone,

If you have substantial technical comments or concerns, please share them with the list.  If you have editorial comments, please share them directly with the authors and co-chairs.

So far, we have the following folks signed up for a thorough review and comments:
- Andy Malis
- Nick DelRegno
- Pranjal Dutta
However, we could use more people to conduct a review.  If you have the time and/or inclination, please let the chairs know if you'll be conducting a review.

Thanks,

Giles & Shane

---

From: [email-masked]
Date: Tue, 20 Apr 2010 09:24:39 +0800

Hi Himanshu,
Thank you for your reply. Please see my comments in line.

BR
Lizhong Jin

Himanshu Shah <[email-masked]> 
2010-04-20 02:52

To
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>, "[email-masked]" <[email-masked]>, 
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>
cc
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>
Subject
RE: WG Last Call: draft-ietf-l2vpn-ipls-09

/himanshu
 
From: [email-masked] [mailto:[email-masked]] 
Sent: Saturday, April 17, 2010 11:16 AM
To: Himanshu Shah; [email-masked]; [email-masked]; 
[email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: WG Last Call: draft-ietf-l2vpn-ipls-09

Hi Himanshu and authors, 
After reviewing draft-ietf-l2vpn-ipls-09, I have the following comments:
1. Section 2.0, point 5, bullet c, more precisely, the unicast ARP packets 
received from "multicast" pseudowire may do MAC DA lookup, and forward to 
where CE is located. So the context should add this exception for ARP 
packets
[Himanshu>] I am not sure I fully understand your comment, but I am 
guessing you are asking to add text to the draft referring the unicast MAC 
and ARP as the context
to the exception whereby normally all the packets received over “
multicast” PW are broadcasted, including this ARP unicast, but as an 
exception, in this case, one
can optimize the flooding.
[Lizhong] Yes, that's exactly what I mean.
. 
2. Section 7.1, I am wondering how to setup the unidirectional mp2p 
pseudowire. According to RFC4447, one pseudowire will be UP only when both 
local and remote label mapping message is sent and received. But according 
to the descripition of unidirectional mp2p pseudowire in IPLS, if PEx 
sends a label mapping to PEy for CEx, PEy seems to consider the PW as UP 
when receiving the corresponding label mapping, and PEx would consider the 
PW as UP when sending out the label mapping, without the necessarity of 
allocating local labels for the PW. 
[Himanshu>] There is no one-to-one correspondence with respect to PW 
directionality. Meaning, if PE1 has two local CE, it will advertise two 
labels. If PE2 has 4 local CEs it will advertise 4 labels. 
Which does not mean that when PE1 receives 4 labels from PE2 that it needs 
to advertise 4 labels to bring PW ‘UP’. So the question, is ‘
unidirectional’ PW a deviation from RFC 4447 which 
assumes PW to be bi-directional (this used to be true initially, not sure 
if still is true) by way of uniting to opposite direction unidirectional 
PW. The unidirectional PW is not illegal.
[Lizhong] From my understanding, unidirectional point-to-point PW is not 
defined in RFC4447. See section 5.3.3 signaling procedures in RFC4447.

What's more, it is also difficult to configure the PWid. If PEx uses 
PWid_1 for CEx1, and PWid_2 for CEx2, according to section 7.1, the PEy 
needs to configure both PWid_1 and PWid_2, which is actually not 
necessary. Do I miss something important here to understand the concept of 
unidirectional mp2p pseudowire? There may be a new type of FEC that is 
required, similar with unidirectional P2MP PW. 
[Himanshu>] PWid is per IPLS instance and not per CE. I do not see any 
text in 7.1 which talks about configuring difference PWid for each CE.
For a given IPLS instance a PE has following to signal –
a)    PW id
b)    One MP2P ‘multicast’  Ethernet PW
c)     Many (i.e. one per local CE) MP2P ‘unicast’ IP PW along with CE’
s MAC address
[Himanshu>] Section 7.1 describes details for send and receive processing 
of label mapping message
[Lizhong] Do you mean PE will advertise all labels for CEs with same PWid? 
Then that means PE will advertise different labels for same FEC(same 
PWid), which will not operate correctly under current framework. The peer 
PE receiving several label mapping messages with same FEC but different 
labels will update the already received label, and only retain the newest 
one. The way to solve this is to define a new type of FEC to specify 
different operation comparing with normal FEC (e.g, type 128 and 129).

3. Section 7.2, why not using LDP capability to advertising IPv6 stack 
capability? 
[Himanshu>] Because this is specific to PW and IPLS instance
[Lizhong] actually, current P2MP PW capability negotiation uses LDP 
capability. I hope we can align this, because both are related with PW 
capability.

4. Will IPLS consider any spoke connectivity to increase the scalability, 
same as VPLS? 
[Himanshu>] I am not sure I fully understand. IPLS assumes (recommends) 
that CEs are IP routers that act as edge box.
Meaning most of the customer’s IP hosts and  other routers are behind 
this CE router in customer network and PE does
not see them. This by itself provides good hierarchy & scalability. 
[Lizhong] Sorry for the unclear statement. The scalability I refer is PW 
scalablity to construct large IPLS network, which is included in RFC4762 
section 10.1.1. 

Best Regards 
Lizhong Jin 

Hi Everyone,

Thanks,

Giles & Shane
 
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is 
solely property of the sender's organization. This mail communication is 
confidential. Recipients named above are obligated to maintain secrecy and 
are not permitted to disclose the contents of this communication to 
others.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the originator of 
the message. Any views expressed in this message are those of the 
individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam 
system.

---

From: Himanshu Shah <[email-masked]>
Date: Mon, 26 Apr 2010 15:00:22 -0700

Hi Lizhong Jin,
Again thanks for the comments, response to your comments in line (marked in green).
/himanshu

On 4/19/10 9:24 PM, "[email-masked]" <[email-masked]> wrote:

Hi Himanshu,

BR
Lizhong Jin

Himanshu Shah <[email-masked]> 2010-04-20 02:52

To

"[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>

cc

"[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>

Subject

/himanshu

Hi Himanshu and authors,

<himanshu> I have following paragraph from the draft. I have added a sentence (in red). See if it addresses your comment.
Personally, I feel it is repeating what is already stated in the draft and does not need more clarification. I do want to clarify
on your comment that flooding optimization is not limited to ARP packets only. It is simply based on MAC DA.

   "When a unicast ARP Ethernet frame is received over the 'multicast'
   PW, PE may optionally do MAC DA lookup in the forwarding table and
   forward it to the AC where the CE is located. If the CE is not
   accessible through any local AC, the frame is dropped. Conversely,
   the PE may simply forward the frame to all the ACs associated with
   that IPLS instance without any lookup in the forwarding table."

   Typically, frames received over the 'multicast' PW are flooded to
    local ACs that are member of the IPLS instance. However, as an optimization,
    PE may lookup MAC DA to limit the flooding based on local database. This
    includes unicast MAC as well as multicast MAC frames.

.
[Lizhong] From my understanding, unidirectional point-to-point PW is not defined in RFC4447. See section 5.3.3 signaling procedures in RFC4447.

<himanshu> RFC4447 is a base document and does not prevent other drafts to utilize and/or extend for specific application (as defined in L2VPN).
Frankly, I would consider unicast PW as a subset of the RFC4447 defined methodologies.

[Lizhong] Do you mean PE will advertise all labels for CEs with same PWid? Then that means PE will advertise different labels for same FEC(same PWid), which will not operate correctly under current framework. The peer PE receiving several label mapping messages with same FEC but different labels will update the already received label, and only retain the newest one. The way to solve this is to define a new type of FEC to specify different operation comparing with normal FEC (e.g, type 128 and 129).

<himanshu> Not true. The draft clearly states that (CE's) MAC address must be advertised in the LM message. The MAC address is augmented and is treated as
part of PW-FEC. May be a sentence needs to be added to avoid the confusion.

3. Section 7.2, why not using LDP capability to advertising IPv6 stack capability?
[Himanshu>] Because this is specific to PW and IPLS instance
[Lizhong] actually, current P2MP PW capability negotiation uses LDP capability. I hope we can align this, because both are related with PW capability.

<himanshu> We (authors) will look into this.

[Lizhong] Sorry for the unclear statement. The scalability I refer is PW scalablity to construct large IPLS network, which is included in RFC4762 section 10.1.1.

<himanshu> My feeling is that current draft is adequate for the scalability that is envisioned for its applicability in the existing networks.
However, if field experience suggest that scalability is an issue, wg can undertake a separate work item to extend the architecture to address
scalability.

Best Regards
Lizhong Jin

Hi Everyone,

Thanks,

Giles & Shane

---

From: [email-masked]
Date: Tue, 27 Apr 2010 09:18:26 +0800

Hi Himanshu,
Thank you for your reply. Please see my new comments with italic format in 
line.

BR
Lizhong Jin

Hi Himanshu and authors, 

<himanshu> I have following paragraph from the draft. I have added a 
sentence (in red). See if it addresses your comment.
Personally, I feel it is repeating what is already stated in the draft and 
does not need more clarification. I do want to clarify
on your comment that flooding optimization is not limited to ARP packets 
only. It is simply based on MAC DA.

   “When a unicast ARP Ethernet frame is received over the 'multicast' 
   PW, PE may optionally do MAC DA lookup in the forwarding table and 
   forward it to the AC where the CE is located. If the CE is not 
   accessible through any local AC, the frame is dropped. Conversely, 
   the PE may simply forward the frame to all the ACs associated with 
   that IPLS instance without any lookup in the forwarding table.”
    
   Typically, frames received over the ‘multicast’ PW are flooded to 
    local ACs that are member of the IPLS instance. However, as an 
optimization,
    PE may lookup MAC DA to limit the flooding based on local database. 
This
    includes unicast MAC as well as multicast MAC frames.
[Lizhong] Now it is fine for me.

. 

<himanshu> RFC4447 is a base document and does not prevent other drafts to 
utilize and/or extend for specific application (as defined in L2VPN).
Frankly, I would consider unicast PW as a subset of the RFC4447 defined 
methodologies.

c)    Many (i.e. one per local CE) MP2P ‘unicast’ IP PW along with CE’s 
MAC address 

<himanshu> Not true. The draft clearly states that (CE’s) MAC address 
must be advertised in the LM message. The MAC address is augmented and is 
treated as
part of PW-FEC. May be a sentence needs to be added to avoid the 
confusion.
[Lizhong] Now I get your meaning. Then the method described in draft is 
implementable, but the FEC definition is not good if MAC address is 
augmented to PW-FEC. I can summarise like that when PE advertise one FEC 
(e.g, type 128 or 129) with MAC address and IP PW type, then PE should 
treat it as an unidirectional PW and allocate a label for combination of 
FEC and MAC address. The concept is a bit different with the traditional 
one (RFC5036) where PE will only allocate label for FEC without 
considering any other value. A clarified sentance may not sufficient 
here......a new type of FEC would be best from my understanding.

[Lizhong] That's good.

<himanshu> My feeling is that current draft is adequate for the 
scalability that is envisioned for its applicability in the existing 
networks.
However, if field experience suggest that scalability is an issue, wg can 
undertake a separate work item to extend the architecture to address
scalability. 
[Lizhong] That's OK.

Best Regards 
Lizhong Jin 

Hi Everyone,

Thanks,

Giles & Shane

---

From: Himanshu Shah <[email-masked]>
Date: Mon, 26 Apr 2010 18:39:14 -0700

Thanks Lizhong for your further comments. Cut & Paste below that is relevent..

<himanshu> Not true. The draft clearly states that (CE's) MAC address must be advertised in the LM message. The MAC address is augmented and is treated as
part of PW-FEC. May be a sentence needs to be added to avoid the confusion.
[Lizhong] Now I get your meaning. Then the method described in draft is implementable, but the FEC definition is not good if MAC address is augmented to PW-FEC. I can summarise like that when PE advertise one FEC (e.g, type 128 or 129) with MAC address and IP PW type, then PE should treat it as an unidirectional PW and allocate a label for combination of FEC and MAC address. The concept is a bit different with the traditional one (RFC5036) where PE will only allocate label for FEC without considering any other value. A clarified sentance may not sufficient here......a new type of FEC would be best from my understanding.

[himanshu] - I don't think new FEC is necessary. I will let other authors and/or WG members to express their opinion.

Regards,
himanshu