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

From: [email-masked]
Date: Mon, 10 Nov 2003 11:26:36 -0000

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

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