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

From: Olen Stokes <[email-masked]>
Date: Wed, 5 Nov 2003 06:50:22 -0800

Question copied from below....

> 	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.

I apologize, but Section 8.2.2 is the best way that I know how to describe
the handling of the TTL in the VC FEC label.  Can you give me a specific
scenario that is not covered in the draft?

In case anyone is not aware, the draft describes a method for handling the
TTL in the VC FEC label.  For example, consider a packet from a spoke node
received at a core node.  The TTL in the received VC FEC label is
decremented and the result placed in the TTL of the outgoing VC FEC label.

Comment copied from below....

> 	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.

This is already discussed in Sections 8.1.4 and in Section 11 of the draft.
There has been no attempt to hide this issue.  If you have any suggestions
for wording to make this clearer, I would be happy to take a look.

Cheers,
Olen

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:[email-masked]]
> Sent: Tuesday, November 04, 2003 11:38 AM
> To: 'Olen Stokes'; 'Thippanna Hongal'; 
> [email-masked];
> [email-masked]
> Cc: [email-masked]
> Subject: RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt
> 
> 
> 
> 	One question and one comment below.
> 
> >-----Original Message-----
> >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]
> >Cc: [email-masked]
> >Subject: RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt
> >
> >
> >
> >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.  
> 
> 	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.
> 
> >>   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.
> 
> 	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
> 
> 
> 
> >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: Wed, 5 Nov 2003 10:06:59 -0500

>From: Olen Stokes [mailto:[email-masked]] 
>Sent: Wednesday, November 05, 2003 9:50 AM
>To: [email-masked]'; Olen Stokes; 'Thippanna Hongal'; 
>I apologize, but Section 8.2.2 is the best way that I know how 
>to describe the handling of the TTL in the VC FEC label.  Can you give
me 
>a specific scenario that is not covered in the draft?
>

	The problem with the algorithm described is that it
requires the basic MPLS forwarding/switching functions
as described in the MPLS architecutre and which is widely
deployed in networks today, to be altered.  VPLS is
made up of pseudo-wires which begin and end at VPLS bridge
entities. What you are describing is that when a pseudo-wire
terminates (at the hub in your example), that the TTL
information is passed to another PW carried by a different
LSP.  This seems like a major layering violation to me.

	The other question is how does your mechanism 
work when L2TPv3 is used as one or part of the 
PWs used in the VPLS?

>for wording to make this clearer, I would be happy to take a look.

	I suggest that this mechanism is inappropriate for the 
reasons stated because it potentially violates the MPLS OAM
requirements as stated in draft-ietf-mpls-oam-requirements-02.txt
as well as the requirements stated at the beginning of your draft 
itself. There are other mechanisms available like VCCV which do 
not alter the fundamental forwardinging and do test the actual 
PW's dataplane path. There are other mechanisms being worked
on in the 802.11ad group at the IEEE for testing ENET segment OAM.
I recommend that we use the appropriate tools to test the appropriate 
levels within the network instead of munging things together.

	--Tom

---

From: Ali Sajassi <[email-masked]>
Date: Fri, 07 Nov 2003 19:56:04 -0800

>  There are other mechanisms being worked

Yes, Ethernet service layer OAM must be completely independent from 
transport layer OAM (e.g., an end to end VPLS service can have different 
transport layers - one network segment can be QinQ, another can be MPLS, 
and yet another can be L2TPv3). That is why in all the different standards 
groups such as ITU, MEF, and IEEE, the fundamental requirement is for 
Ethernet service layer OAM to be independent from transport layer 
OAM.  Both ITU and MEF have produced some preliminary drafts that may of 
interest to those who want to explore this further.

-Ali