I think this is a nice document, with many useful suggestions
and insights. I think it would make a great ION if we still had
IONs, a fine IESG statement, or perhaps an I-D that was reissued
every 5 1/2 months to keep it active. The more I think about
it, the less I like the idea of publishing
My 2 pence:
I did finally manage to read the document and I support its
publication. The only minor comment:
The table in Table 1 has been corrected (reference for NO-SOLICITING)
and extended (ATRN, DELIVERBY, CONPEM, and CONNEG). The registry
should be updated to reflect the
Hi all,
After having sent out my comments I've noticed that the specific example to
illustrate the need to combine GAL and flow label was inaccurate.
A more relevant example would look like following (I do not include a diagram,
but it can be easily provided if necessary)
1. A MS-PW:
*
I think it's okay because as the PW crosses the ECMP-enabled IP/MPLS domain
in the middle segment, you're no longer in an MPLS-TP environment and so the
GAL is not required to be BOS. During that middle segment, the PW flow
label would be placed below the GAL and above the GACh. It gets removed
Pablo,
This is not acceptable. Are you suggesting an LSR to pop a label that is not to
of the stack? I can assure you 99.99% of HW out there can't do this.
Thx
SD
From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of Pablo
Frank
Sent: Tuesday, August 16, 2011 2:18 PM
To:
My mistake. Flow-labels are used end-to-end in a multi-segment pseudowire.
I suppose the flow label can easily be ignored when it crosses the MPLS-TP
segments but that does create the conflict that Sasha is pointing out.
Pablo
On Tue, Aug 16, 2011 at 5:24 PM, Shahram Davari dav...@broadcom.com
Pablo,
Sorry, but I think you're wrong. Only T-PE can insert the flow label (because
only T=PE can be flow-aware). S-PE simply performs swap on PW label.
Regards,
Sasha
From: Pablo Frank [pablois...@gmail.com]
Sent: Wednesday, August 17, 2011 12:17 AM
To:
At 01:38 17-08-2011, John C Klensin wrote:
The problem is that RFCs are forever. RFCs subjected to IETF
Last Call and published in the IETF Stream --especially ones
that advise on IETF processes-- are also official, at least in
the sense of representing some level of community consensus and
