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

From: Thippanna Hongal <[email-masked]>
Date: Tue, 04 Nov 2003 11:13:54 -0800

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