Manav

I don't agree that IETF can not define new encaps - it certainly can.
It is just that we have not come to agreement that a new encap is needed.

I think we need language that states that for time delivery co-routed paths are 
needed,
but how to accomplish this for P2MP LSPs is for further study.

I agree with the other proposals.

Y(J)S

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of 
Bhatia, Manav (Manav)
Sent: Wednesday, April 27, 2011 02:35
To: [email protected]
Subject: [TICTOC] Updating draft-ietf-tictoc-1588overmpls

Folks,

I am working on updating draft-ietf-tictoc-1588overmpls as per the WG feedback.

As part of this I will change the OSPF and IS-IS capabilities to be per link as 
against per node that its currently defined as.

Will also clarify that FCS retention for the payload Ethernet described in 
[RFC4720] MUST not be used.

Should I remove Sec 5.3 "1588 over pure MPLS mode" as I believe we had 
discussed that IETF cannot define new encapsulations in Prague?

I will also add some verbiage that P2MP LSPs may not work as they only provide 
unidirectional traffic flow and cannot guarantee a symmetrical path back to the 
head nodes. 

Anything else?

Cheers, Manav

--
Manav Bhatia,
Service Router Product Group (SRPG)
Alcatel-Lucent, India
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc

Reply via email to