Subject: Re: [TICTOC] Questions about draft-ietf-tictoc-1588overmpls

From: Yaakov Stein <[email-masked]>
Date: Fri, 1 Apr 2011 08:33:54 +0000

Tal

I think the optional offset is the beginning of the  1588 payload
(i.e., below any Ethernet or UDP/IP headers).

Now that I think of it, using this offset we could handle the generic CF as well !

FCS retention refers to RFC4720 - where the Ethernet FCS is retained in an Ethernet PW
(which is not done in the standard RFC 4448).
In any case, any time one goes over an Ethernet link - even if only between LSRs,
the FCS needs to be recomputed before putting an Ethernet frame on an Ethernet link.
This FCS is NOT the FCS of the original 1588oEthernet or 1588oUDP/IPoEthernet frame.

Y(J)S

From: [email-masked] [mailto:[email-masked]] On Behalf Of Tal Mizrahi
Sent: Friday, April 01, 2011 08:06
To: Shahram Davari; [email-masked]
Subject: [TICTOC] Questions about draft-ietf-tictoc-1588overmpls

Hi Shahram,

After a deeper review of your presentation, a couple of questions:
-       The optional OFFSET: the draft should specify the start point of the offset. I assume this would be the beginning of the MPLS stack, since the MPLS layer is not aware of the length of lower layer headers, right?
-       The PPT (and similarly the draft) says "Ethernet FCS must be calculated at every LSR" - this refers to the FCS of the outer Ethernet packet, right? (Since the next line says "FCS retention must not be used"). It is worth to clarify in the draft.

Thanks,
Tal.

---

From: Tal Mizrahi <[email-masked]>
Date: Fri, 1 Apr 2011 20:39:27 +0300

Hi Yaakov, Shahram,

>I think the optional offset is the beginning of the  1588 payload

It makes sense that the offset should be configured to point to the 1588 payload, but my point was that the offset is measured WRT a specific anchor, i.e., offset=0 points to the anchor. This draft must define the anchor very clearly.
As Shahram explained in the TICTOC meeting, the goal of the offset was to save complex processing at the LSR, like detecting the number of labels in the stack, or detecting whether a CW exists or not. Thus, it appears the anchor should be the beginning of the MPLS stack.

Tal.
________________________________
From: Yaakov Stein [mailto:[email-masked]]
Sent: Friday, April 01, 2011 11:34 AM
To: Tal Mizrahi; Shahram Davari; [email-masked]
Subject: RE: Questions about draft-ietf-tictoc-1588overmpls

Tal

Y(J)S

Hi Shahram,

Thanks,
Tal.

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Sat, 2 Apr 2011 12:17:13 +0530

There can be multiple customer vlan tags between the MPLS payload and the PTP packet, and it will thus not help if the offset points to the start of the MPLS payload. Its for this reason that we had decided on pointing the offset to the start of the PTP packet.

Cheers, Manav

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tal Mizrahi
Sent: Friday, April 01, 2011 11.09 PM
To: Yaakov Stein; Shahram Davari; [email-masked]
Subject: Re: [TICTOC] Questions about draft-ietf-tictoc-1588overmpls

Hi Yaakov, Shahram,

Tal.

Tal

Y(J)S

Hi Shahram,

Thanks,
Tal.

---

From: Tal Mizrahi <[email-masked]>
Date: Sat, 2 Apr 2011 11:58:50 +0300

Hi Manav,

I agree, and I believe we are all saying the same thing.
Just to clarify:
The offset (by definition) specifies the number of bytes betwen point A in the packet and point B in the packet.
We all agree that point B = the beginning of the 1588 packet.
The issue I raised was about point A.

Point A - correct me if I am wrong - is the beginning of the MPLS stack.

Regards,
Tal.

________________________________
From: Bhatia, Manav (Manav) [[email-masked]]
Sent: Saturday, April 02, 2011 9:47 AM
To: Tal Mizrahi; Yaakov Stein; Shahram Davari; [email-masked]
Subject: RE: Questions about draft-ietf-tictoc-1588overmpls

Cheers, Manav

Hi Yaakov, Shahram,

Tal.

Tal

FCS retention refers to RFC4720 – where the Ethernet FCS is retained in an Ethernet PW
(which is not done in the standard RFC 4448).
In any case, any time one goes over an Ethernet link – even if only between LSRs,
the FCS needs to be recomputed before putting an Ethernet frame on an Ethernet link.
This FCS is NOT the FCS of the original 1588oEthernet or 1588oUDP/IPoEthernet frame.

Y(J)S

Hi Shahram,

After a deeper review of your presentation, a couple of questions:
-          The optional OFFSET: the draft should specify the start point of the offset. I assume this would be the beginning of the MPLS stack, since the MPLS layer is not aware of the length of lower layer headers, right?
-          The PPT (and similarly the draft) says “Ethernet FCS must be calculated at every LSR” – this refers to the FCS of the outer Ethernet packet, right? (Since the next line says “FCS retention must not be used”). It is worth to clarify in the draft.

Thanks,
Tal.

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Sun, 3 Apr 2011 01:01:42 +0530

Hi Tal,

Shouldnt it be the start of the packet?

Cheers, Manav

________________________________
From: Tal Mizrahi [mailto:[email-masked]]
Sent: Saturday, April 02, 2011 2.29 PM
To: Bhatia, Manav (Manav); Yaakov Stein; Shahram Davari; [email-masked]
Subject: RE: Questions about draft-ietf-tictoc-1588overmpls

Hi Manav,

Regards,
Tal.

Cheers, Manav

Hi Yaakov, Shahram,

Tal.

Tal

Y(J)S

Hi Shahram,

Thanks,
Tal.

---

From: Tal Mizrahi <[email-masked]>
Date: Sat, 2 Apr 2011 23:17:26 +0300

Hi Manav,

> Shouldnt it be the start of the packet?
I believe that would be a problem. Just a reminder, we are talking about the MPLS control plane (RSVP-TE) signaling to each LSR the OFFSET to the start of the PTP header.
I do not think we can assume that the MPLS control plane is aware of the L2 protocol (Ethernet II /  LLC / LLC-SNAP, ...), or the number of VLAN tags. The L2 header length may be different at each LSR, and even at each interface of each LSR.
Thus, it seems the OFFSET should be counted FROM the beginning of the MPLS stack.

Regards,
Tal.
________________________________
From: Bhatia, Manav (Manav) [mailto:[email-masked]]
Sent: Saturday, April 02, 2011 10:32 PM
To: Tal Mizrahi; Yaakov Stein; Shahram Davari; [email-masked]
Subject: RE: Questions about draft-ietf-tictoc-1588overmpls

Hi Tal,

Cheers, Manav

Regards,
Tal.

Cheers, Manav

Tal.

Tal

Y(J)S

Hi Shahram,

Thanks,
Tal.

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Sun, 3 Apr 2011 07:17:39 +0530

Hi Tal,

Yes, i missed this point - I agree that it should be the start of the MPLS payload. Will fix this in the next revision.

Cheers, Manav

Sent: Sunday, April 03, 2011 1.47 AM

Hi Manav,

Regards,
Tal.

Hi Tal,

Cheers, Manav

Regards,
Tal.

Cheers, Manav

Tal.

Tal

Y(J)S

Hi Shahram,

Thanks,
Tal.

---

From: Yaakov Stein <[email-masked]>
Date: Sun, 3 Apr 2011 11:49:52 +0000

Hi all,

Just arrived back in the office, and so I missed a few of these emails.

I fully understand why it is easier for the pointer to point to the MPLS payload -
e.g., the beginning of an Ethernet packet with UDP/IP and inside that 1588.
However, this is not as useful. It then requires full parsing of the Ethernet and IP!

I realize that this may make it easy to reuse existing implementations,
but it will be much harder to explain in an RFC.
The purpose of the offset should be to the field to be corrected,
or to something from which one can immediately determine where this field is.
The suggested method is to point to something from which you need to perform parsing of non-IETF protocols.
Hardly an elegant approach.

Perhaps there should be 2 different OFFSET types.

Y(J)S

From: Bhatia, Manav (Manav) [mailto:[email-masked]]
Sent: Sunday, April 03, 2011 04:48
To: Tal Mizrahi; Yaakov Stein; Shahram Davari; [email-masked]
Subject: RE: Questions about draft-ietf-tictoc-1588overmpls

Hi Tal,

Cheers, Manav

Regards,
Tal.

Hi Tal,

Cheers, Manav

Regards,
Tal.

Cheers, Manav

Tal.

Tal

Y(J)S

Hi Shahram,

Thanks,
Tal.

---

From: Tal Mizrahi <[email-masked]>
Date: Sun, 3 Apr 2011 15:08:16 +0300

Hi Yaakov,

>We all agree that point B = the beginning of the 1588 packet.
Following the thread with Manav, I think we agreed the point A=the beginning of the MPLS header.

I think this does not contradict your mail below. Please confirm.

Thanks.
Tal.
________________________________
From: Yaakov Stein [mailto:[email-masked]]
Sent: Sunday, April 03, 2011 2:50 PM
To: Bhatia, Manav (Manav); Tal Mizrahi; Shahram Davari; [email-masked]
Subject: RE: Questions about draft-ietf-tictoc-1588overmpls

Hi all,

Y(J)S

Hi Tal,

Cheers, Manav

Regards,
Tal.

Hi Tal,

Cheers, Manav

Regards,
Tal.

Cheers, Manav

Tal.

Tal

Y(J)S

Hi Shahram,

Thanks,
Tal.

---

From: Yaakov Stein <[email-masked]>
Date: Sun, 3 Apr 2011 12:39:58 +0000

Tal

The present draft says :
                                                         A new RSVP
   object is defined to signal that this is a PTP LSP.  The OFFSET to
   the start of the PTP message header MAY also be signaled.
   Implementations can trivially locate the correctionField (CF)
   location given this information.

The OFFSET should be the number of bytes from the beginning of the PDU as seen by the LSR doing the TC.
It obviously can not know how the MPLS packet was originally encapsulated,
nor of labels that were popped before getting this far.

For 1588/UDP/IP/MPLS this is AFTER the top MPLS label.
I don't think it should be after the entire stack (after the bottom label), since this would require the LSR to search through
until it found the S-bit indication (a layer violation that it should only do for ECMP).

For 1588/Ethernet/Eth-PW/MPLS, this would mean to me to be after the tunnel label but before the PW label.

It is not clear to me whether what has been said here is consistent with this view.
I interpret "MPLS payload" to mean after the label stack - including after a PW label.
I am not sure what "beginning" of a stack means - is that top or bottom ?
(3031 defines top and bottom labels).

Y(J)S

From: Tal Mizrahi [mailto:[email-masked]]
Sent: Sunday, April 03, 2011 15:08
To: Yaakov Stein; Bhatia, Manav (Manav); Shahram Davari; [email-masked]
Subject: RE: Questions about draft-ietf-tictoc-1588overmpls

Hi Yaakov,

Thanks.
Tal.

Hi all,

Y(J)S

Hi Tal,

Cheers, Manav

Regards,
Tal.

Hi Tal,

Cheers, Manav

Regards,
Tal.

Cheers, Manav

Tal.

Tal

Y(J)S

Hi Shahram,

Thanks,
Tal.

---

From: Tal Mizrahi <[email-masked]>
Date: Sun, 3 Apr 2011 16:46:54 +0300

Yaakov,

I originally suggested:
OFFSET = (pointer to first byte of 1588 header) - (pointer to first byte of top-of-MPLS-stack)

You are suggesting:
OFFSET = (pointer to first byte of 1588 header) - (pointer to first byte AFTER the tunnel label)

Correct me if I am wrong.

Tal.
________________________________
From: Yaakov Stein [mailto:[email-masked]]
Sent: Sunday, April 03, 2011 3:40 PM
To: Tal Mizrahi; Bhatia, Manav (Manav); Shahram Davari; [email-masked]
Subject: RE: Questions about draft-ietf-tictoc-1588overmpls

Tal

The present draft says :
                                                         A new RSVP

Y(J)S

Hi Yaakov,

Thanks.
Tal.

Hi all,

Y(J)S

Hi Tal,

Cheers, Manav

Regards,
Tal.

Hi Tal,

Cheers, Manav

Regards,
Tal.

Cheers, Manav

Tal.

Tal

Y(J)S

Hi Shahram,

Thanks,
Tal.