R: RE: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>> Backwards compatibility
>> This was the main argument risen to ground MPLS-TP OAM on BFD. It's not a 
better argument than grounding MPLS-TP OAM on 1731 due to its ETH deployment 
plus coherence with SDH, OTN, as defended by ITU-T.
>> For reasons like the above, however, MPLS-TP BFD won't be backwards 
compatible with previous BFD (even considering just CC/CV). They don't even 
share the same codepoint.
>
>The issue is not code point, which is the trivial part. It is reuse of the 
majority of the implementation. Again, pretty basic.
>

I disagree. From a backward compatibility perspecting the codepoint is very 
relevant. An existing implementation does not reckon the new encapsulation: the 
only way to deploy this solution in a backward compatible manner is by 
upgrading all the IP/MPLS nodes that have been deployed up to so far.

I think that the "reuse of the majority of the implementation" is actually the 
issue. Those implementations do not have the capabilities required to be 
deployed in a transport network. 

Developing a non-transport capable standard will not make these boxes 
transport capable but it would just make the standard useless for a transport 
environment.

>----Messaggio originale----
>Da: david.i.allan@ericsson.com
>Data: 8-lug-2011 18.13
>A: "Rui Costa"<RCosta@ptinovacao.pt>, "Stewart Bryant"<stbryant@cisco.com>
>Cc: "erminio.ottone_69@libero.it"<erminio.ottone_69@libero.it>, "mpls@ietf.
org"<mpls@ietf.org>, "ietf@ietf.org"<ietf@ietf.org>, "IETF-Announce"<ietf-
announce@ietf.org>
>Ogg: RE: [mpls] Last Call: &lt;draft-ietf-mpls-tp-cc-cv-rdi-05.txt&gt;	
(Proactive	Connectivity Verification, Continuity Check and Remote Defect	
indication for MPLS	Transport	Profile) to Proposed Standard
>
>Rui:
>
>You wrote:
>
>>Reading something, keeping it on record, without effect in the draft and 
"ignoring comments" have IMHO similar outcomes. As author of the draft you are 
free to do it. These standards have a great impact
>>in our work, so i'm also free to write what i did.
>
>Numerous comments did have effect on the draft and those that didn't were 
either simply not actionable, were rhetorical or not constructive, and a few 
had to be balanced against comments coming from the MPLS & BFD WGs. I would 
translate "ingored" or "without effect" to "did not get one'e way". In the 
standards process it happens.
>
>Meanwhile as an editor of the document, I'll take the liberty of responding 
to some of the points you raise...
>
>>My technical concerns regarding this draft were expressed...
>>...in the (ITU-T -> IETF, Feb/2011) liaison regarding it (LS281, i 
believe);
>>...in operators' meetings' that took place during ITU-T's Feb/2011 plenary 
meeting;
>
>I and the WG don't really have access to private grumblings.
>
>>...in a comparison session that took place during that same ITU-T meeting.
>
>Lots of other opinions were expressed as well, and they did not all agree 
with you.
>
>>Some:
>>CC/CV
>>I don't understand the need for 2 types of packets: a single type allows CC; 
mismatching identifiers in the same CC packets allow CV.
>>Besides adding complexity, we whether always activate both or potentiate 
undetected mismerges.
>
>OK, lets walk through this.
>
>We want CV all the time so that any misconectivity can be detected, but on 
the list it was expressed that the group did not want the overhead of 
processing the source MEP TLV in every packet in order to achieve this. We 
could carry it in every packet and have the receiver simply ignore most of 
them, but then that would make the defect entry criteria compeltely random and 
the exit criteria unreliable as well, not really a good design. Hence they are 
separated using different ACH code points and the receiver is obliged to 
process every source MEP TLV it receives. I hope this is clear.
>
>>(BTW: can't understand how we propose one ACH codepoint to CC, another for 
CV, [counting other drafts, another for frame loss ...] but don't consider 
assigning 1 single ACH protocol identifier codepoint >as requested by ITU-T)
>
>Because that puts you into two protocol ID demultiplexing steps per OAM PDU 
recevied to determine the intended function. Hence COSTS MORE. That is pretty 
basic...
>
>> Uni P2P / P2MP
>> I can't see how BFD will support unidir and hence P2MP other than...
>> ...eliminating the session "state variable" (down, init, up), aiming just 
the state variables we really need, bringing us to something similar to 1731, 
eventually with other bits on the wire or...
>> ...using IP to create the reverse way, which we cannot assume per 
requirements;
>> Will we create a complete different tool for that?
>> (BFD's B="bidirectional")
>
>I would not go so far as to say "similar to 1731", there is actually a lot of 
difference under the hood. As for uni-directional BFD, that is a BFD WG problem 
at the moment.
>
>> Provisioning list
>> This is an MPLS profile/subset (and i heard) achievable through a 
particular configuration. So, i expect each draft-ietf-mpls-TP-* to focus on 
that profile/configuration. However, i keep seeing
>> references f.i. to IP encapsulations unexpected under TP's OAM.
>> I don't thus understand what the aim is: do we expect this in TP, are we 
talking about MPLS in general?... The TP profile is never quite delimited.
>> Does chapter 4 contain ALL the configurable parameters list agreed to 
provide in the comparison session?
>
>It should. As for encapsulations, unless TP is in a complete island not 
connected to anything (which as a network is rather useless) it will be 
expected to interoperate with the rest of the MPLS architecture, and the stated 
intention of tool development was that what resulted was applicable to the 
broader MPLS architecture. Which means backwards compatiblity and procedures 
for interoperation.
>
>> Backwards compatibility
>> This was the main argument risen to ground MPLS-TP OAM on BFD. It's not a 
better argument than grounding MPLS-TP OAM on 1731 due to its ETH deployment 
plus coherence with SDH, OTN, as defended by ITU-T.
>> For reasons like the above, however, MPLS-TP BFD won't be backwards 
compatible with previous BFD (even considering just CC/CV). They don't even 
share the same codepoint.
>
>The issue is not code point, which is the trivial part. It is reuse of the 
majority of the implementation. Again, pretty basic.
>
>>Simplicity
>>Whether we look to PDH, SDH, OTN or ETH, ITU-T's approach to CC is simpler: 
in each flow, a standard defined nr of constant heartbeat signals (with 
standard constant or provisioned period - no
>>auto/negotiated -) means OK. A standard defined number of misses means lost 
Rx connection. An RDI, the only articulation between Rx and Tx flows, 
meaningful in bidirectional applications, allows each
>>pear to identify Tx problems.
>>This OAM simplicity is the key for reliable fail finger pointing, 
performance reports and protection. Also to allow scaling, more implementation 
opportunities/manufacturers, which is valuable for
>>operators.
>
>Well IMO there was not a lot of interest in T-MPLS until the IETF was going 
to re-define it and make it compatible with IP/MPLS. So there was an industry 
wide "design intent" implied here.
>
>> IMHO, between your MPLS-TP view and MPLS/IP, it becomes more and more 
difficult to tell which is which.
>
>That is because MPLS-TP is not a new techology, it is an addition to the 
entire MPLS protocol suite.
>
>Hope this helps
>D
>
>
>
>
>
>
_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


[Index of Archives]     [IETF]     [IETF Discussion]     [Linux Kernel]

  Powered by Linux