The MPLS WG Archive

[Hiroshi Ohta <ohta.hiroshi@lab.ntt.co.jp>]

Hi Scott,

You indicated your concern on potential future modifications to IETF 
protocols.
Would you clarify what the real problem is?

Now, what ITU-T SG13 is asking is only a code point assignment.  ITU-T Rec.
Y.1711 could be operated without any more modifications to IETF protocols.
In order to operate MPLS OAM functions better, modifications to IETF protocols
may be proposed in the future.  In this case, proposer/mover will submit an 
I-D.
If it is agreed, protocols are modified.  If it is rejected, nothing 
happens.  It is nothing
more than what is going on in the usual IETF activities.  So, I do not 
think this
potential future modification proposals is a problem.

Best regards,

Hiroshi

At 16:44 02/04/12 -0400, you wrote:

>This is the response to http://www.ietf.org/IESG/LIAISON/ITU-SG13-MPLS-OAM.txt
>that was discussed during the MPLS session in Minneapolis that I plan to
>send early next week unless the WG has a problem with that.
>(Thanks to George for the draft that this is based on)
>
>Scott
>
>---------
>
>SOURCE: IETF Sub-IP Area - Scott Bradner, Area co-Director
>TITLE: Response to "Communication on the status of the request on the
>   assignment of a reserved label value for MPLS OAM packet identification"
>
>The MPLS working group discussed SG 13's request for the assignment of a
>reserved label value for MPLS OAM packet identification
>(draft-ohta-mpls-label-value-01.txt) during the MPLS session during the
>recent IETF meeting in Minneapolis.  There was some disagreement during the
>discussion about the long term implications  of the IETF granting this
>request.
>
>During the discussion it was noted that there are a number of references to
>modifications to IETF protocols in Y.1711.  In particular, Section 6.1
>states, "Ideally this should be done automatically  via LSP signaling at
>LSP set-up time (e.g. via a CR-LDP or RSVP  control-plane mechanism), but
>it could also be configured manually.   The mechanism for achieving this
>configuration is outside the scope of this Recommendation."
>
>Since manual configuration is probably not an option for anything beyond a
>very limited deployment the implication is that the ITU will require the
>IETF to change CR-LDP and RSVP before Y.1711 would be seen as a complete
>solution.
>
>Also in section 6.3, Forward Defect Indication, the following text may be
>read as indicating an assumption of future changes in  IETF protocols
>dealing with LSP signaling.
>
>"It is important that the LSP sink point knows (for the duration that the
>LSP is in service) any server->client LSP label mappings that were in
>existence prior to the defect.  Although the exact means for achieving this
>are outside the scope of this Recommendation, some examples of how these
>server-> client layer label mappings could be configured are as follows:
>    o manually, via the NMS say;
>    o automatically on LSP set-up via extensions to LSP signaling ..."
>
>In order to understand the possible consequences of allocating an MPLS
>codepoint in response to the request in  draft-ohta-mpls-label-value-01.txt
>the MPLS working group would like to understand the full scope and extent
>of the modifications that SG13 may be assuming to other IETF protocols,
>including LDP, CR-LDP, RSVP, PIM and BGP.
>
>A further concern is the impact on the MPLS forwarding plane as currently
>defined.  In certain points in a MPLS network, based on an incoming label,
>the label is removed and the packet is forwarded with no further inspection
>of subsequent headers (be it another MPLS label or some other header).
>Y.1711 seems to imply that the above behavior would not satisfy Y.1711.
>Specifically, there are some cases where Y.1711 would expect a network
>element to intercept an OAM packet. This raises issues of backward
>compatibility with existing MPLS systems and ASICs.
>
>The MPLS working group would like to understand if Y.1711 assumes
>functionally that could not be supported by simply changing software in
>existing MPLS implementations.
>
>