Dear Stewart,
I think that at least in case of MPLS PTN any modification of client data
constitutes layer violation.
Regards,
Greg
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
Stewart Bryant
Sent: Sunday, November 27, 2011 2:14 AM
To: Bhatia, Manav (Manav)
Cc: '[email protected]'
Subject: Re: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt
On 27/11/2011 00:42, Bhatia, Manav (Manav) wrote:
> Hi Stewart,
>
> I don't see how this design is better than the one that we have in the
> current TICTOC WG document. Let me address the objections that you have
> raised.
>
> 1. Layer Violation
>
> Both designs do layer violation.
I am not sure it's a layer violation to modify the field immediately after BOS
in a FEC that is defined to carry that field in that way.
> Even yours does, since each LSR has to understand that it's a special
> MPLS packet
That is the definition of this FEC.
> and has to deep inspect and modify a few fields in the shim header.
One field, located immediately after BOS, which is an offset that is known when
we set up the LSP.
> I don't think looking at a layer violation is a valid thing to do because
> transparent clocking by itself is layer violation.
Not exactly. We have a new MPLS tunnel that has the property that it records
the time taken to traverse the tunnel. We have a tunnel endpoint that knows
what is going in and out of the tunnel and can apply the correction directly on
the payload or transmit that information along with the payload in some other
format.
P routers do not need to explore beyond the first field after BOS and are
entirely agnostic WRT what is carried. It is this agnosticism of payload type
that is central to the design of MPLS.
> Even in the current WG draft if one only implements boundary clocks then
> there would be no layer violation.
But the draft looks to be about TC not BC.
>
> 2. Parsing the MPLS payload to determine the kind of packet it is.
>
> In the current WG draft you don't need to parse the packet to determine what
> needs to be done with it.
So why the long discussion earlier in the thread about how to parse the packet?
BTW, the offset mechanism that you propose only provides the start of the PTP
header, you have to backtrack to the IP packet to determine if it is v4 or v6
and then do forward again to fine the UDP c/s. You could signal all this, but I
did not see that text in the draft.
These more complex operations are not really operations that you want do in a P
router.
> When the LSP was set up you knew the exact offset at which you had to do your
> rewrite. The LSR knows exactly what it needs to do when it sees the packet
> with a specific MPLS label.
Not quite. You could I suppose provide the offsets of the UDP c/s as well in
the control protocol but you have not done that.
>
> While I will agree that the approach that you have suggested will also work
> and could also be explored. I don't necessarily see ours not working or it
> breaking the basic tenets of the MPLS.
No one is saying that yours will not work, it's just more expensive in
processing and far less general. So for example, you will not be able to
support the next gen of timing protocols without updating all LSRs. The shim
method only requires updating the PEs.
As to whether this breaks the basic tenets of MPLS, that is a question that
needs to be put to the MPLS WG, and the sooner it goes there the sooner you
will know if you are on solid grounds.
Note that there is a 100% certainly that the draft will need to be Last Called
in MPLS WG, so it would be wise for the chairs to request an initial review
early in the process.
- Stewart
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc
