Re: [mpls] Question on the status of Y.1711 and RFC3429
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [mpls] Question on the status of Y.1711 and RFC3429
Hi Neil,
First, I think you have made some very good observation. In fact, I
agree with you on the point where, if a connection is no longer p2p, OAM
would be tough to deal with.
You have brought up ECMP. As some of us have discussed in private, the
reality could be worse. In case of ECMP, we at least know there may be
multiple routes within a segment of the connection. If we consider
Ethernet Link Aggregation (LAG), the packets may go over different
physical links without the knowledgeable of upper layer OAM protocols.
However, this is not the fault of MPLS. MPLS is the mechanism to forward
packets over the connections defined by routing and underlying physical
topology.
To deal with this kind of complex scenarios, one tool is not enough!
This is where a combination of LSP-ping, BFD and OAM interworking
techniques could help us solving the problem. If we find new problems,
let's put fixes into the defined and deployed mechanisms.
As I have mentioned before, let's put all the problems on the table for
discussion. Simply pushing standard may not be the best way to solve
problems.
Does it make sense?
Regards,
- Ping
neil.2.harrison at bt.com wrote:
> Ping....to be clear here (given I was largely responsible for Y.1711):
>
> - Y.1711 (and before it the requirements given in Y.1710) was
> based on trying to define a generic OAM solution for any correctly
> specified co-ps mode layer network technology....the key principle
> underpinning it was to 'keep things as simple as possible'.
>
> - If one breaks the architectural rules of what defines a
> connection (eg must have single source) then there are no good/simple
> OAM solutions. Or more accurately, one cannot assign/manage resource in
> a co-ps technology that breaks the rules of a connection. BTW - One
> cannot break this rule in the co-cs mode.
>
> - The type of MPLS based on LDP creates merging mp2p constructs
> (so does PHP on a last hop). These are not connections.
>
> - LSP ping took something like 5-6 years and 13 or so
> iterations....simple it is not. The use of ECMP also greatly
> complicates matters.
>
> - The OAM required to detect/handle defects in a properly
> architected co-ps or co-cs mode layer network should be unidirectional
> (and not of a request/response nature) for many reasons.....co-ps/cs
> mode OAM is not like cl-ps mode OAM because connections create
> constraining constructs under normal operation.
>
> So, having defined LDP (and PHP + ECMP) then Y.1711 is no good for this
> type of MPLS....but this is not the fault of Y.1711 of course.
>
> regards, Neil
>
>> -----Original Message-----
>> From: mpls-bounces at ietf.org [mailto:mpls-bounces at ietf.org] On
>> Behalf Of Ping Pan
>> Sent: 03 April 2008 14:48
>> To: Shahram Davari
>> Cc: 'Masayuki Takase'; mpls at ietf.org
>> Subject: Re: [mpls] Question on the status of Y.1711 and RFC3429
>>
>>
>> Have to bite:
>>
>> Y.1711 may be the first to be defined, but LSP-ping was the
>> first to get
>> deployed and used to solve real problems. So the age, the
>> complexity and
>> the brand name sometimes do not matter much.
>>
>> Why do we try this? (Maybe we have already). Let's lay out
>>
>> - the problems that Y.1711 have solved where the existing mechanisms
>> defined in IETF won't be able to address, and
>>
>> - how serious those problems are.
>>
>> Then let's move from there.
>>
>> - Ping
>>
>>
>> Shahram Davari wrote:
>>> Tom,
>>>
>>> Could you please provide your definition of MPLS OAM? I have been
>>> involved in MPLS and OAM for more than 10 years and my
>> understanding
>>> is that Y.1711 is the first MPLS OAM defined in the industry.
>>>
>>> -Shahram
>>>
>>> -----Original Message-----
>>> From: mpls-bounces at ietf.org [mailto:mpls-bounces at ietf.org]
>> On Behalf
>>> Of Thomas Nadeau
>>> Sent: April-02-08 7:33 PM
>>> To: Francesco Fondelli
>>> Cc: mpls at ietf.org; Masayuki Takase
>>> Subject: Re: [mpls] Question on the status of Y.1711 and RFC3429
>>>
>>>
>>> ITU recommendation Y1711 has nothing to do with MPLS
>> OAM. If you
>>> want a
>>> good overview of IETF MPLS OAM take a look at RFC4221.
>>>
>>> --Tom
>>>
>>>
>>>
>>> On Apr 2, 2008, at 11:09 AM, Francesco Fondelli wrote:
>>>> On Wed, Apr 2, 2008 at 3:50 PM, Thomas Nadeau
>>>> <tnadeau at lucidvision.com> wrote:
>>>>> How could you have built MPLS OAM to support label 14? Do
>>>>> you mean
>>>>> you implemented Y1711 using label 14?
>>>>>
>>>>> --Tom
>>>> Back in 2002/2003/2004? there used to be no 'T-' :-)
>>>>
>>>> http://www.itu.int/rec/T-REC-Y.1711/en
>>>>
>>>> "Y.1711: Operation & Maintenance mechanism for MPLS networks"
>>>>
>>>> Clear, isn't it? //I'm sarcastic
>>>>
>>>> Ciao
>>>> FF
>>>>
>>> _______________________________________________
>>> mpls mailing list
>>> mpls at ietf.org
>>> https://www.ietf.org/mailman/listinfo/mpls
>>>
>>> _______________________________________________
>>> mpls mailing list
>>> mpls at ietf.org
>>> https://www.ietf.org/mailman/listinfo/mpls
>>>
>> _______________________________________________
>> mpls mailing list
>> mpls at ietf.org
>> https://www.ietf.org/mailman/listinfo/mpls
>>
>
_______________________________________________
mpls mailing list
mpls at ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.