Subject: response to ITU-T SG13

From: Scott Bradner <[email-masked]>
Date: Fri, 12 Apr 2002 16:44:50 -0400 (EDT)

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.

---

From: Kireeti Kompella <[email-masked]>
Date: Sat, 13 Apr 2002 18:17:25 -0700 (PDT)

On Fri, 12 Apr 2002, Scott  Bradner wrote:

> including LDP, CR-LDP, RSVP, PIM and BGP.

Where did PIM come in?

> compatibility with existing MPLS systems and ASICs.

A deeper question is the implication of different forwarding decisions
for OAM and non-OAM packets.  In particular, if OAM packets are
treated differently, how valuable is feedback from those forwarding
decisions on the forwarding of regular packets?  And isn't the whole
point just that -- to know what "regular forwarding" is doing?

> functionally that could not be supported by simply changing software in
  ^^^^^^^^^^^^ functionality?
> existing MPLS implementations.

Kireeti.

---

From: Hiroshi Ohta <[email-masked]>
Date: Thu, 18 Apr 2002 22:44:21 +0900

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

---

From: Hiroshi Ohta <[email-masked]>
Date: Fri, 19 Apr 2002 13:51:25 +0900

Scott,

In order to operate MPLS OAM, there are several options.  For example, to
activate/deactivate OAM functions some options need modifications to IETF
protocols and others do not.  SG13 cannot give you an definite answer because
it is not determined what option to take.  If one (not necessarily from 
ITU) thinks
modifications to IETF protocols are necessary, one would propose it using 
I-D.
IETF has the choice to take it or not.  It is just the same as how IETF 
operates.

So, what is the problem?

Best regards,

Hiroshi

At 18:59 02/04/18 -0400, Scott  Bradner wrote:
>exactly what I said - I want to know if SG 16 is expecting to need changes
>to IETF protocols - i.e. full disclosure
>
>no more, no less
>
>Scott

---

From: Hiroshi Ohta <[email-masked]>
Date: Mon, 22 Apr 2002 14:22:58 +0900

Hi Scott,

I did not say that I did not want to know what is coming next.  SG13 has 
not decided what
method to take for issues that your draft Liaison back letter brought 
up.  I am not an expert
on politics, but I think the decision on the expansion of the IETF protocol 
should be based
on the technical discussion even if it is politically harder (I do not know 
why though) to
reject the proposal.

Best regards,

Hiroshi

At 07:18 02/04/19 -0400, Scott  Bradner wrote:
>I fail to see why you would not want to know what is coming next
>
>you say that the IETF can decide to accept someting later or not - yes
>that is factually correct but not actually that easy - if we have
>started down a path it gets politically harder to say no the further
>we are down the path
>
>if SG13 does not know they can just say that
>
>Scott
>
>---