Subject: RE: L2vpn digest, Vol 1 #85 - 5 msgs

From: "Tran Thinh" <[email-masked]>
Date: Wed, 5 Nov 2003 21:54:42 +0700

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Wednesday, November 05, 2003 9:51 PM
To: [email-masked]
Subject: L2vpn digest, Vol 1 #85 - 5 msgs

Send L2vpn mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www1.ietf.org/mailman/listinfo/l2vpn
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of L2vpn digest..."

Today's Topics:

   1. RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt (Vach Kompella)
   2. RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt (Thippanna
Hongal)
   3. RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt (Thippanna
Hongal)
   4. RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt (Thomas D.
Nadeau)
   5. RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt (Olen Stokes)

--__--__--

Message: 1
Reply-To: <[email-masked]>
From: "Vach Kompella" <[email-masked]>
To: <[email-masked]>, "'Olen Stokes'" <[email-masked]>,
        "'Thippanna Hongal'" <[email-masked]>,
        <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt
Date: Tue, 4 Nov 2003 09:54:29 -0800
Organization: Alcatel USA

Tom,

> >You need the OAM label to prevent the packet from reaching=20
> >customer devices.
>=20
> 	It should be pointed out that this extra label also adds the=20
> potential for the OAM packets being forwarded along ECMP paths that=20
> 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=20
> deficiency to me as it can result in false results.
>=20
> 	--Tom

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=20

--__--__--

Message: 2
Date: Tue, 04 Nov 2003 11:13:54 -0800
To: Olen Stokes <[email-masked]>,
        Olen Stokes <[email-masked]>,
        [email-masked], [email-masked]
From: Thippanna Hongal <[email-masked]>
Subject: RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt
Cc: [email-masked]

  Thanks for the reply but we have some additional questions.

1) From the draft we understand that the vpls ping can originate either
at 
the mtu or the PE. And terminate at the PE or MTU depending  on whether
the 
customer is connected at the MTU or PE.
   From the reply below

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

  We understand that the OAM label terminates at the PE always. So does
it 
mean that
  Case A) (HVPLS) MTUs being connected to the PE, the PE has to examine
the 
packet (TLVs) and decide to either forward/ flood to the MTUs
   Case B) No MTUS connected but directly connected to customers the PE 
must reply  back directly using the smac address?

2) In case 1A we believe that the PE must add OAM Label in addition to
any 
PW label needed to send to the MTU/ Similarly when the MTU 
replies/requests  a ping it also must add an OAM label  which terminates
at 
the PE.

3) Regarding the QAM label could you point us to the draft where the OAM
label

At 08:03 AM 11/4/2003 -0800, Olen Stokes wrote:

>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

--__--__--

Message: 3
Date: Tue, 04 Nov 2003 11:21:51 -0800
To: [email-masked], Olen Stokes <[email-masked]>,
        [email-masked]
From: Thippanna Hongal <[email-masked]>
Subject: RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt

hi Olen,

Thanks for the reply, we have some more questions.

1) From the draft we understand that the vpls ping can originate either
at 
the MTU or PE.
    And terminate at the PE or MTU depending  on whether the customer is

connected
    at the MTU or PE. From the reply below

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

We understand that the OAM label terminates at the PE always. So does it

mean that

Case A) (HVPLS) MTUs being connected to the PE, the PE has to examine
the 
packet (TLVs) and decide to either forward/ flood to the MTUs
   Case B) No MTUS connected but directly connected to customers the PE 
must reply  back directly using the smac address?

2) In case A we believe that the PE must add OAM Label in addition to
any 
PW label needed to send to the MTU/ Similarly when the MTU 
replies/requests  a ping it also must add an OAM label  which makes this

OAM frame terminate at the PE.

3) Regarding the QAM label could you point us to the draft where the OAM

label is defined for
    VPLS Ping.

Regards
hongal

--__--__--

Message: 4
Reply-To: <[email-masked]>
From: "Thomas D. Nadeau" <[email-masked]>
To: <[email-masked]>, "'Olen Stokes'"
<[email-masked]>,
        "'Thippanna Hongal'" <[email-masked]>,
        <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt
Date: Tue, 4 Nov 2003 14:33:35 -0500
Organization: Cisco Systems, inc.

>-----Original Message-----
>From: Vach Kompella [mailto:[email-masked]] 
>Sent: Tuesday, November 04, 2003 12:54 PM
>To: [email-masked]; 'Olen Stokes'; 'Thippanna Hongal'; 
>[email-masked]; [email-masked]
>Cc: [email-masked]
>Subject: RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt
>
>
>Tom,
>
>> >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
>
>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?

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

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

	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

>-Vach 

--__--__--

Message: 5
From: Olen Stokes <[email-masked]>
To: "[email-masked]'" <[email-masked]>,
        Olen Stokes
	 <[email-masked]>,
        "'Thippanna Hongal'"
	 <[email-masked]>,
        [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt
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
> >> 
> >
> 

--__--__--

_______________________________________________
L2vpn mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/l2vpn

End of L2vpn Digest