On 12/5/2011 7:59 AM, Anthony Magee wrote: > Hi Danny, > > I was intentionally vague here to see what feedback arose. > > So in my email, I neglected to mention that the Source Address I was talking about modifying as a result of changing the contents of the packet, is the Layer 2 Source MAC Address. >
Okay, that's a relief! I was concerned about IP addresses. I have no clue what the affect of changing a MAC address would be. > For a device to modify the contents of a packet, or in this case for the higher layer entity to terminate the packet, and create a new packet, in order to preserve normal networking rules, then in theory the packet should use the address of the device that modified the packet. > > If we have a case where 1588 PTP over Ethernet is being transported within a pseudowire and MPLS LSP, and the only addresses modified are the Layer 2 MAC Addresses(of the Layer 2 MAC Address encapsulated within the PW and the Layer 2 MAC address of the Ethernet Transport for the MPLS stack), would this cause any problems for NAT? I don't know if the NAT cares about that but I'm only knowledgeable at the IP address level. Danny > > Regards, > > Anthony > > -----Original Message----- > From: Danny Mayer [mailto:[email protected]] > Sent: 05 December 2011 12:37 > To: Anthony Magee > Cc: Yaakov Stein; [email protected]; Shahram Davari; '[email protected]' > Subject: Re: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt > > On 11/29/2011 1:35 PM, Anthony Magee wrote: >> Hi Yaakov, >> >> The layer violation issue is something which I believe needs further > discussion. >> >> If a higher layer entity is placed inside a device and is used to act > as the Transparent Clock i.e. calculating residence time and modifying the > correction field in the layer with which that higher layer entity is > associated, one could use an identifier such as a label, or a multicast > Destination address in order to address that higher layer entity, allowing it > to make the change without it being a layer violation. Then on the transmit > side, there is nothing specifically incorrect in a device modifying the > Source Address of the packet sent from a Transparent Clock within the scope > of IEEE 1588 and this would be needed in order to indicate that the device > has effectively created a new packet - however, the function of the node is > still that of a Transparent Clock. >> > > There would be all sorts of violations if you change the Source Address. > NAT is bad enough without some other router also diddling with addresses. > Don't do that. > > Danny > _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
