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

From: Ali Sajassi <[email-masked]>
Date: Mon, 10 Nov 2003 22:45:42 -0800

At 11:26 AM 11/10/2003 +0000, [email-masked] wrote:
>Ali....I agree with what you say here.  But have you noticed that you are 
>effectively contradicting your recent posting to the PWE3 list wrt (in 
>your view) not retaining the FCS in ethernet?  That is, the ethernet FCS 
>*belongs* to the ethernet client and must be independent of whatever the 
>server layer is....which is as you correctly note below, ie we must have 
>layer (in this case OAM) independence.  The fact that one may have to do a 
>linear update of the FCS on a link-connection basis does not alter this 
>fact.  Indeed, from a G.805/809 functional arch perspective, the ethernet 
>FCS belongs to the client->server adaptation process and obviously applies 
>on all client layer ethernet link-connections (as provided by server layer 
>trails).

In case of EVPL, do you consider service multiplexing field as part of the 
client data ? VLAN filed of the EVPL service is analogous to DLCI field of 
FR service.

Yours,
Ali

>regards, Neil
>
> > -----Original Message-----
> > From: Ali Sajassi [mailto:[email-masked]]
> > Sent: 08 November 2003 03:56
> > To: [email-masked]; 'Olen Stokes'; 'Thippanna Hongal';
> > [email-masked]; [email-masked]
> > Cc: [email-masked]
> > Subject: RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt
> >
> >
> >
> > >  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.
> >
> > 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
> >
> >
> > >         --Tom
> > >
> > >
> > >
> > >
> > > >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
> > > >> >>
> > > >> >
> > > >>
> > > >
> >
> >
> >