Manav, See comments in line. Lizhong
"Bhatia, Manav (Manav)" <[email protected]> wrote on 2011-01-27 18:33:17: > Hi Lizhong, > > > not draft-ietf-tictoc-1588overmpls aware. You will note that this draft > > also has some text on the non 1588aware LSRs. These LSRs could be doing > > ECMP and without an entropy label, may cause PTP messages to be load > > distributed across different paths. > [Lizhong] then in section 13, it is said: "This capability MUST then > be taken into account during path computation to prefer nodes that > advertise themselves as 1588-aware, so that the PTP LSPs can be > properly handled." How to understand "prefer nodes"? If there is a > shortest path with some non 1588aware LSRs, and a less optimal path > with all 1588aware LSRs, which path the ingress LER should take? > > [Manav] There is nothing new here and it happens all the time while > computing CSPF. You pick the path which satisfies your contraints. > Now, if you want a path with all 1588aware LSRs then thats precisely > what CSPF will return you. If you want to insist on a shorter path > then you need to add other constraints in addition to this. [Lizhong] OK, I see. Actually my first impression is that it is a bit difficult to define such policy for CSPF, in order to fullfill the timing accuracy. > > > > > > > > > >The head end > > > > when setting up the RSVP path would know this (by inspecting the IS- > > > > IS or OSPF TE info) and could in such cases make use of the Entropy > > > > label to ensure that all PTP packets follow the same path. > > > [Lizhong] How to use entropy label to ensure all PTP packets follow the > > > same path? > > > > Using an entropy label will ensure that all PTP packets in one direction > > follow the same path. > [Lizhong] since control word is required for 1588 over PW > encapsulation, if without entropy label, all PTP packets in one > direction will also follow the same path. > > [Manav] I think we must use a stronger language in Sec 5.2 regarding > using control word. I think i will concur with you here that if CW > is being used then we may not need an entropy label. However, i dont > see a strong reason why we should restrict it. The current draft > says that control word usage is optional and i dont find any issue > with that. Do you? [Lizhong] the current draft says control word SHOULD be used. And yes, stronger language is welcome. > > > > > > If there is entropy label, it is possible that the forward > > > and reverse path would be different. > > > > Since LSPs are unidirectional there is no guarantee that the two paths > > would be symmetrical. So this really is an issue orthogonal to the use > > of entropy labels for carrying PTP traffic. > > > > We should probably add some text in the draft that says that the two > > paths must be symmetrical. > [Lizhong] If there is a boundled interface between two LSRs, the > control plane will only see one logical interface. Then it is still > possible the forward and reverse path be different at the physical > level in ECMP case. > > [Manav] Is the assumption that the two ends of LAG could be > connected to two different systems, something like a multi-chassis > lag? I am not sure if there is much that we can do about this except > add a note against such a form of load distribution in the document. [Lizhong] I mean the LAG between two end-points, not MC-LAG. E.g, one LAG interface with physical link A & B between two end-points, it is possible that the forward path will go through A, and backward path will go through B, then the physical path is not symmetric. If I understand correctly, you just assume the transport delay on link A & B are the same, but this is not always true, especially for the composite link defined in RTGWG ( draft-ietf-rtgwg-cl-requirement). > > Cheers, Manav -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
