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
