Subject: RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt

From: Olen Stokes <[email-masked]>
Date: Tue, 4 Nov 2003 08:03:41 -0800

Please see in line....

> -----Original Message-----
> From: Thippanna Hongal [mailto:[email-masked]]
> Sent: Friday, October 31, 2003 6:08 PM
> To: [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]
> Subject: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt
> 
> 
> hi Stokes,
> 
> Below is the packet format on the wire as we understand from 
> the draft.
> We have a few questins on this.
> 
> Packet for the PING
> 
>    dmac1 (Next hop router)
>    smac1 (Of the originating router)
>    Etype - 8847
>    Transport label -|__________________ Pseudo wire
>    Vc label   ------|
>    dmac2 (of the target mtu/pe to which the ping is targeted)
>    smac2 (of the originating router (PE/MTU))
>    etype (IP 0x800)
>     ...
>     Mac TLV
>       smac3 --  (??)
>       dmac3 --  (customer's mac/spoke's mac to be pinged).
> 
>   a) Is the above representation correct?
> 
Here is an internal debug dump of a VPLS ping about to be sent...

00 01 30 05 84 00  Next Hop Router MAC              
00 01 30 08 92 00  Local (originating) Router MAC   
                                                    
88 47              Ethertype = MPLS                 
cb 00 10 ff        Tunnel Label                     
8c 00 40 ff        VC Label                         
00 00 e1 ff        OAM Label                        
                                                    
00 01 30 05 84 00  Remote Spoke/Core MAC being pinged            
00 01 02 03 04 05  Local Customer MAC               
08 00              Ethertype = IP                   

45                 IPv4              
00                 TOS               
00 6c              Length            
00 80              ID                
00 00              Offset            
ff                 TTL               
11                 protocol = UDP    
cc 31              Header Checksum   
0b 64 64 09        Src IP            
7f 00 00 62        Dst IP            

95 80              UDP Src Port = 38272
0d af              UDP Dst Port = 3503   
00 58              UDP Length            
00 00              UDP Checksum          

00 01              LSP Ping Version Number = 1                   
00 00              Must Be Zero                                  
01                 Message Type = MPLS Echo Request              
05                 Reply Mode = Reply Via a VPLS IPv4 UDP Packet 
00                 Return Code                                   
00                 Return Subcode                                
00 04 00 01        Sender's Handle                               
00 00 00 61        Sequence Number                               
3f a7 5e 0c        Timestamp Sent (seconds)                      
00 04 ba f0        Timestamp Sent (microseconds)                 
00 00 00 00        Timestamp Received (seconds)                  
00 00 00 00        Timestamp Received (microseconds)             

00 01              Type = Target FEC Stack               
00 20              Length                                
00 0a              Sub-Type = Hierarchical L2 Circuit ID 
00 1c              Length                                
00 00 07 d0        VC ID                                 
00 05              Encapsulation Type = Ethernet         
00 00              Must Be Zero                          
00 05              L2 Specific Sub-Type = Ethernet       
00 10              Length                                
00 01 30 05 84 00  Target Ethernet MAC                   
00 00                                                    
00 01 02 03 04 05  Sender Ethernet MAC (local customer MAC)

00 00                                                    

00 03              Type = Pad            
00 08              Length                
02                 Copy Pad TLV to Reply 
44 45 41 44        Pad Data              
42 45 45

>   b) What is the value of the smac3 in the TLV. Is it mandatory ?.
>      Should the reply take the path  using the smac3 for lookup
>      (for reply mode 5)?  Pseudo Wire Connectivity verification ?.

This is the MAC to which the reply should be sent.  It is included to
support implementations where the processing is distributed in case the MAC
header is not passed along with the IP packet.

Here is an internal debug dump of a reply to a similar VPLS ping about to be
sent...

00 01 30 08 92 00  Next Hop Router MAC              
00 01 30 05 84 00  Local (originating) Router MAC                       
                                                    
88 47              Ethertype = MPLS                 
cb 00 10 ff        Tunnel Label                     
8c 00 30 ff        VC Label                         
00 00 e1 ff        OAM Label                        

00 01 02 03 04 05  Remote Spoke/Core/Customer MAC (Sender Ethernet MAC from
request)
00 01 30 05 84 00  Local Spoke/Core/Customer MAC (Target Ethernet MAC from
request)
08 00              Ethertype = IP         

45                 IPv4               
00                 TOS                
00 78              Length             
00 93              ID                 
00 00              Offset             
ff                 TTL                
11                 protocol = UDP     
cc 59              Header Checksum    
0b 64 64 08        Src IP             
7f 00 00 1c        Dst IP             

0d af              UDP Src Port = 3503
95 80              UDP Dst Port = 38272
00 64              UDP Length            
00 00              UDP Checksum          

00 01              LSP Ping Version Number = 1                   
00 00              Must Be Zero                                  
02                 Message Type = MPLS Echo Reply
05                 Reply Mode = Reply Via a VPLS IPv4 UDP Packet 
00                 Return Code                                   
00                 Return Subcode                                
00 05 00 01        Sender's Handle                               
00 00 00 1b        Sequence Number                               
3f a7 62 be        Timestamp Sent (seconds)                      
00 06 8f b0        Timestamp Sent (microseconds)                 
3f a7 56 45        Timestamp Received (seconds)                  
00 04 ba f0        Timestamp Received (microseconds)             

00 01              Type = Target FEC Stack                
00 20              Length                                 
00 0a              Sub-Type = Hierarchical L2 Circuit ID  
00 1c              Length                                 
00 00 07 d0        VC ID                                  
00 05              Encapsulation Type = Ethernet          
00 00              Must Be Zero                           
00 05              L2 Specific Sub-Type = Ethernet        
00 10              Length                                 
00 01 30 05 84 00  Target Ethernet MAC                    
00 00                                                     
00 01 02 03 04 05  Sender Ethernet MAC                    
00 00                                                     

00 04              Type = Error Code
00 08              Length
00 0a              Sub-Type = Hierarchical L2 Circuit ID
00 04              Length
00 01              Error Code = Replying router is the Egress for the MAC
00 00              Must Be Zero

00 03              Type = Pad             
00 08              Length                 
02                 Copy Pad TLV to Reply  
44 45 41 44        Pad Data               
42 45 45                                                           

In this example, when the reply is received at the originating PE, the OAM
label causes the packet to be processed at the PE and not forwarded to the
customer.  

> 
>   c) Is there any relation between smac2 and smac3 ?.
> 

Normally they would be the same.  

>   d) We have assumed that the dmac2 is either the mac of the
>      target MTU/PE. This is because if the customer dmac is
>      used the packet would show up at the customer. If the
>      router alert is used the the packet would not go beyond
>      the PE. So is this assumption correct ?.

You need the OAM label to prevent the packet from reaching customer devices.
Remember that if dmac2 is not known in the network, the packet may be
flooded.  It would then reach PEs other than the one associated with dmac2.
The OAM label allows these switches to prevent the traffic reaching a
customer.

> 
>   e) pre-condition:
>      To do a VPLS ping to verify customer MAC  sitting at
>      the remote end, we have to have a actual customer 
> traffic flowing on
>      the pseudo-wire, or at least some customer traffic has 
> to be there
>      within the 'L2 age out' time period.
>      For VPLS ping to work, this is a pre-condition.
> 
>      Question is 'Is this a valid pre-condition ?', If yes, are users
>      OK with this model of OAM ?.
> 

As stated above, if the MAC is unknown, the packet is to be flooded as would
any normal packet.  Therefore, the intent that this pre-condition should not
be necessary.

> thanks
> hongal

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 4 Nov 2003 11:38:29 -0500

One question and one comment below.

>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of Olen Stokes
>Sent: Tuesday, November 04, 2003 11:04 AM
>To: 'Thippanna Hongal'; Olen Stokes; 
>[email-masked]; [email-masked]
>Subject: RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt
>
>
>
>Please see in line....
>
>
>
>In this example, when the reply is received at the originating 
>PE, the OAM label causes the packet to be processed at the PE and not 
>forwarded to the customer.  

	Could you please explain/elaborate on how the TTL is 
treated in the aforementioned packets? Your packet dump does
not show this. Specifically, what happens to the header + TTL 
as the packet traverses the MPLS network between the VPLS bridges
as described in section 8.2.2 of your draft.

>You need the OAM label to prevent the packet from reaching 

	It should be pointed out that this extra label also adds the 
potential for the OAM packets being forwarded along ECMP paths that 
differ from those of the original data packets.  I think you
are making the assumption that the VC label is the only one
used for load-share computation. This seems like a serious 
deficiency to me as it can result in false results.

	--Tom

---

From: "Vach Kompella" <[email-masked]>
Date: Tue, 4 Nov 2003 09:54:29 -0800

Tom,

> deficiency to me as it can result in false results.

Two points:

First regarding trying to do ECMP:
So, suppose you wanted to do OAM somewhere in the middle of the network.
The LSR looks at the top label.  It understands that.  It looks at the
next label.  It's bottom-of-stack.  It looks at the next nibble - not
4x.  Do you assume it is an Ethernet packet?  Do you have a clue what
kind of PW it is to make any assumptions about the usable fields for
ECMP?

Second, regarding ECMP:
If the MAC learning was correctly executed, at ingress, the PW chosen to
forward will still be the right one, the outgoing interface to the
customer will still the right one, unless for some reason the dest MAC
was learned against the wrong VPLS peer, on the wrong PW.  In that case,
you can correctly report the error.  In other words, at the VPLS level,
the ping/traceroute follows the PWs of the VPLS properly.

-Vach

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 4 Nov 2003 14:33:35 -0500

>From: Vach Kompella [mailto:[email-masked]] 
>Sent: Tuesday, November 04, 2003 12:54 PM
>To: [email-masked]; 'Olen Stokes'; 'Thippanna Hongal'; 

	I am not understanding your point about wanting to
do "OAM in the middle of the network". If you want to
test the PWs that the VPLS is using, you can do that
very easily using the same label stack that the PW
uses (see VCCV and LSP ping). If you want to test
any other labels/tunnels in the core, you use LSP ping.
These all work fine whether or not ECMP is in use, or whether
there is an ENET packet contained in the PW (or whatever).

>was learned against the wrong VPLS peer, on the wrong PW.  In 
>that case, you can correctly report the error.  In other words, at the
VPLS level,
>the ping/traceroute follows the PWs of the VPLS properly.

	Not necessarily. The lesson to be learned from the work
done over the past year or so on LSP ping is that you 
should not count on any specific ECMP behavior within the core; 
just that it might happen and if and when it does, you need to handle
it.  Thus, even if your PE happens to choose the right outgoing label 
at the ingress PE, it is very possible that a core LSR may still choose 
a different path in the core if it hashes on the entire label stack.
This happens of course because another label (for OAM) has been inserted

into the label stack.  

	Also, there was no reply to my TTL/forwarding question.

	--Tom